Mail Archives: djgpp-workers/1998/06/25/13:28:23
Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> 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
- Raw text -