www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1998/06/24/08:48:30

Message-Id: <m0yoout-000S3tC@inti.gov.ar>
Comments: Authenticated sender is <salvador AT natacha DOT inti DOT gov DOT ar>
From: "Salvador Eduardo Tropea (SET)" <salvador AT inti DOT gov DOT ar>
Organization: INTI
To: Nate Eldredge <nate AT cartsys DOT com>, djgpp-workers AT delorie DOT com,
DJ Delorie <dj AT delorie DOT com>, Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Date: Wed, 24 Jun 1998 09:50:26 +0000
MIME-Version: 1.0
Subject: Re: DJGPP v2.01 malloc wasting 4Kb

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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019