Message-Id: Comments: Authenticated sender is From: "Salvador Eduardo Tropea (SET)" Organization: INTI To: Nate Eldredge , djgpp-workers AT delorie DOT com, DJ Delorie , Eli Zaretskii Date: Wed, 24 Jun 1998 09:50:26 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: DJGPP v2.01 malloc wasting 4Kb Precedence: bulk Hi All: Looks like: 1) Nobody have enough time and motivations to put v2.02 in beta. DJ says: >> 3) What's the status of 2.02? The last snapshot is too old! >How old is too old? Eli says: >> 3) What's the status of 2.02? The last snapshot is too old! >We don't always have control on how much free time we can spend on >DJGPP. Maybe if more volunteers would help (hint, hint), it will move >faster. >> isn't that worst than having an updated beta version? >IMHO, v2.02 isn't ready for beta yet. See my other mail. 2) The unofficial v2.01 patched is stable. Eli says: >> Currently there are too much known bugs in v2.01, as an example: my >> editor needs at least 3 patchs for libs to work. >There's the patched libc site for this. If you have a version of >malloc which is tested enough to be used by others, submit the patches >to Nate. >> I know Nate is mainting an unofficial patched version but: Are these patchs >> really tested? >Most of them are mine. Those which are mine were used to build the >binary distributions of all the packages I uploaded for the last year >at least, and I use all those packages every day. So I'd say they are >tested quite well, but only in the environments that I use (which >include plain DOS (versions 5 and 6.2) and Windows 95 4.00.950r7, >approximately 50%-50%. Nate says: >> I know Nate is mainting an unofficial patched version but: Are these patchs >> really tested? isn't that worst than having an updated beta version? >People are requested to test their patches, and have them peer-reviewed >to some extent, before submitting them. > >The distinction between that and the 2.02 tree is, as I see it, that the >patches are intended only to fix bugs, while 2.02 may add features that >could introduce new bugs. [snipped] 3) And we have a versions mess. Nate says: >... It's similar to the difference between the >2.0.x and 2.1.x development paths of Linux, for those who are familiar. > >I personally feel that beta releases would be a good idea. However, the >current 2.02 is considered "alpha" by DJ-- i.e. "it's not necessarily >expected to work". Also, frequently released betas makes a lot of work >for whoever is in charge, and that would be DJ. So as a conclution I proppose: 1) Change the version number of the alpha to v2.10 because: a) It adds new features and not only fixes bugs. b) We need intermediate versions because we can't know when v2.10 will be available. c) We need a way to distinguish between v2.01 and the patched v2.01. I suggest: v2.01+patches => v2.02 beta, v2.02 alpha => v2.10 alpha 2) Make the unofficial library part of the official distribution. I know it sound grammatically stupid but we need it. I think it could be placed in some directory like this: v2/betas/libc202b.zip We can include other file with the patchs called libc202p.zip. I don't think is necesary a whole distribution like the current 2.02 is. It is too much work and doesn't help to anybody. This won't have to represent work from DJ's side. He will need only to move from your incoming to the right directory. I think that's a good intermediate solution. Having the patched version in other place is a real problem for users who wants to compile another package. 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. 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. I know Eli can include the patches in the sources (are you doing it Eli?) but I think that isn't the right way. 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