Mail Archives: djgpp/1997/10/08/09:37:40
Eli Zaretskii wrote:
> People who care about the quality of their libraries should watch
> patches posted to this news group and visit the DJGPP bug-tracking
> system (http://www.delorie.com/djgpp/bugs/) regularly. If they
> neglect doing this, it's tough on them, but I don't think you can
> reasonably require more than these two services between releases.
How about a list of bugs in the downloaded version? That wouldn't take much
to update, just a list of all 'open' bugs in te current system, updated say
once a month.
Trying to get into the Web site is (as DJ says) slow, and trying to find a
bug in the system is even worse. Having an easily grepped file in the
library release would be a lot faster.
Certainly, this wouldn't help with new bugs found after the person has
downloaded, but as you say they should then be on the lookout for new
ones. The people who have problems are those who are new to DJGPP,
and often to C/C++ programming in general, and they are the ones who
will suspect their own code not the ANSI-defined functions.
> > Can there not be a library release without having to do a complete DJGPP
> > release?
>
> A ``complete DJGPP release'' is nowadays nothing more than new libc.a,
> libm.a and libdbg.a, new headers in include/ directory, and a
> recompile of all the small DJGPP-specific utilities (such as `redir',
> `symify' etc.).
Hmm, by a 'complete' release I would expect to mean the compiler as well,
hence my confusion.
> It is still a lot of work to get all the libc
> patches, install them,
... make sure they don't conflict, and/or resolve the conflicts...
> test them, make a few beta releases, get
> responses from beta-testers and react on them, all of which needs to
> be done before a release is ready. It takes time, especially when
> done by volunteers (DJ Delorie does most of this, btw) on their spare
> time.
Indeed. But isn't this partly because of trying to do all the patches
at once? I would have thought that incremental releases, with a couple
of easily-tested patches in each one, would be better. That's the way I'm
used to releasing code in a multi-user project in my job.
> It would be nice if somebody (you?) would volunteer to maintain a site
> where library patches (say, in the form of small zip files, one each
> for every function patch) and/or an entire patched library could be
> downloaded by people who need to patch their library quickly without
> waiting for a release. (If anybody is interested in such a project, I
> can supply more details about what I think should be kept on such a
> site.)
Could someone send me all of the patches? I don't have facilities to pull
each one off the web site individually into a file, then edit to extract
them, but if you (plural) already have an alpha version then someone must
have already done that. And if, for each new patch, I got an email (with
some standard subject so I could filter it) containing it then I could
do such a system. (The actual format and protocol would need to be worked
out, of course, so that it could be automated).
> But until/unless somebody makes this happen, we are stuck with release
> schedule that depends on the amount of free time DJ and other contributors
> have available.
The first part is not quite correct - the release schedule is /always/
dependant on how much resources are available...
Chris C
- Raw text -