Message-Id: Comments: Authenticated sender is From: "Salvador Eduardo Tropea (SET)" Organization: INTI To: Eli Zaretskii , Nate Eldredge , djgpp-workers AT delorie DOT com, DJ Delorie Date: Thu, 25 Jun 1998 14:31:05 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: DJGPP v2.01 malloc wasting 4Kb References: In-reply-to: Precedence: bulk Eli Zaretskii wrote: > On Wed, 24 Jun 1998, Salvador Eduardo Tropea (SET) wrote: > > > Looks like: > > > > 1) Nobody have enough time and motivations to put v2.02 in beta. > > I think we all invest in v2.02 as much time and motivation as we possibly > can. I know I do. But is not enough. I understand you and I know you do more than what I can ask from a person. But lamentably that's not enough. Don't get me wrong, I'm not telling: "Nobody invest time and nobody have motivations" I say: "not enough ...". > If you can help make it happen faster, please do. Currently I don't have time for it, sorry. > Accusing us in insufficient motivation is one thing that won't help. That's why I'm asking to move the version number and let space for things that needs less effort. > > 1) Change the version number of the alpha to v2.10 because: > > Changing a version number doesn't change the contents. It's just > semantics. Yes I know, but suppose we call it in the reverse: djgpp v2.02 alpha and djgpp v2.10 beta .... that's a very confusing thing! or not? the next version with samller number?! > > a) It adds new features and not only fixes bugs. > > So did v2.01 after v2.0. Isn't the point. > > b) We need intermediate versions because we can't know when v2.10 will be > > available. > > DJ thinks intermediate versions make maintenance harder. He is the > maintainer, so he gets to decide on that. The patched libc was created to > fill the need in the meanwhile. Exactly, I think you wrote it without reading the rest and after reding you left it. No? > > c) We need a way to distinguish between v2.01 and the patched v2.01. > > We already have that: the patched libc is available from a different > place, so there's no problem to distinguish between them. It's not that > we need to make sure everybody uses exactly the same libc. Most of those > who download the patched version know what they are doing, and the rest > uses the stock version. I don't see where's the problem. It generates problems put the patches in all the sources and ask the user to patch the libc is a very bad thing. > > That's very important, specially if Eli is linking the binaries (and Eli > > is the porter of most of v2gnu directory) with this library! The user must > > know it! If the user doesn't know it and tries to recompile the gnu tool > > from sources he will get a buggy release. > > In those cases where patched functions are *required* to build the > binary, this is explained in the README. In some extreme cases, I even > put the patched sources of library functions into the source > distribution, so people could patch their libraries before rebuilding. Very annoying and time consuming! > I also don't think this is a big deal, since most of the people don't > rebuild from sources. If they would, I'd rather stop distributing > binaries, as that's a lot of work. > > > I think the patched library must be in the distribution because: > > Suppose a magazine puts djgpp on CD and distributes it. Then suppose a user > > buys the magazine and he don't have access to iNet. Then situation is very > > bad: he have the sources of the tools but no way to creat a bug-free binary. > > Nothing prevents that magazine from putting the patched libc on the CD. > That's what I did for the FSF CD-ROM that should be release RSN. I did it in my CD too, and so what? It doesn't help to make the things easier for people using other CDs or distributions. > For all > practical purposes, the patched libc *is* the intermediate version. For this reason I want it a little bit more clear and official. > If > the only problem is to make it available from SimTel, I don't have > anything against it. DJ? Yes, that's what I want. I simply want it to be: 1) More clear. 2) Easier for users. and without charging it over DJ. > Also, please note that some important patches in v2.02 are for the tools > (like djtar and redir). I don't think these are less important than > libc. Your suggestion ignores those bug-fixes. Yes, that's why I think it must be v2.10 and be a whole distribution. And the patched just a v2.02 and only some binaries, libc.a for sure, perhaps another thing, not sure. > > I know Eli can include the patches in the sources (are you doing it Eli?) > > but I think that isn't the right way. > > The only right way I know is to contribute to the effort of debugging and > putting v2.02 out the door as fast as we can. This means taking part of > the job of improving the library upon yourself, if you feel that v2.02 is > moving too slowly. But I'm not asking to rush v2.02! I just want to change the number and let space for an unofficial beta, but available from the main distribution. You missunderstood my intention, I can't ask for a finished v2.02 because I'm not even working on it. I want something easier for the user. So if, for example, I distribute the sources of my editor I can simply say: "needed: libc v2.xx" and the user can get it from the main distribution. I think it isn't too much work. SET ------------------------------------ 0 -------------------------------- Visit my home page: http://set-soft.home.ml.org/ or http://www.geocities.com/SiliconValley/Vista/6552/ Salvador Eduardo Tropea (SET). (Electronics Engineer) Alternative e-mail: set-soft AT usa DOT net set AT computer DOT org ICQ: 2951574 Address: Curapaligue 2124, Caseros, 3 de Febrero Buenos Aires, (1678), ARGENTINA TE: +(541) 759 0013