Sender:	rich AT phekda DOT freeserve DOT co DOT uk
Message-ID:	<3E7772C8.EF7B8584@phekda.freeserve.co.uk>
Date:	Tue, 18 Mar 2003 19:26:00 +0000
From:	Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
X-Mailer:	Mozilla 4.77 [en] (X11; U; Linux 2.2.23 i586)
X-Accept-Language:	de,fr
MIME-Version:	1.0
To:	djgpp-workers AT delorie DOT com
Subject:	Re: DJGPP 2.04 release? [Was: Re: nmalloc revisited]
References:	<10303181601 DOT AA14391 AT clio DOT rice DOT edu>
Reply-To:	djgpp-workers AT delorie DOT com

Hello.

Charles Sandmann wrote:
[snip]
> > Outstanding patches that should go in before an alpha (IMHO):
> >
> > * fchdir
> > * isnan
> > * strto* & Inf, NaN
> >
> > You could argue that fchdir should go in after, but it's a pretty major
> > change in open/fopen, so lots of testing would be good.
> 
> I have no objections to these, but they seem less critical than other
> things.

Hmmm, I though C99 compliance was a goal of 2.04? In which case isnan, strto*
are important. fchdir less so, since that's POSIXy.

> > Fixes that could go in mid-cycle:
> >
> > * fstat fix (_invent_inode on filename from fd_props)
> > * stat fix (for directories on Win2k/XP)
> 
> What is this?

Apparently stat doesn't return the same inode each time on Win2k/XP.

> > Need to check:
> >
> > * docs have been done for programs missing them;
> > * other items listed on 2.04 page.
> >
> > Push into 2.05:
> >
> > * DXE
> 
> If we push this out, we will need to package it as a separate program
> and REQUIRE it in the near future.  Or release 2.05 as soon as it's
> available, forget the testing.  I think this is a bad idea.
>
> Alternatives would be:
>  1) blow off DXE, replace with DXE3 (not backward compatible) - add 6Kb
>     to each executable startup.
>  2) Check in current DXE3 code, have separate DXEgen and DXE3gen
>     executables,
>     not use DXE3gen yet, make everyone using DXE3gen change syntax sometime
>     in future.

AFAICT the main reason for new DXE is to support NLS without eating up disk
space. Is NLS a killer feature for 2.04?

I guess it comes down to: What do we (or the users) want from DJGPP 2.04? (Has
anyone asked them?) What do we have time to do?

> How about considering making all djdev executables link to a dynamic libc,
> and having libc have it's own version/releases?

Blimey. That sounds like a DJGPP 3.x thing to me.

> > * C99 compliance - restrict, math, complex numbers, etc.
> > * New POSIX compliance
> > * nmalloc (if we do this, Charles says: "someone needs to fix the current
> >   libc free() to early out if there are lots of items in the free list")
> 
> free is still "broken" and I don't think anyone has looked at it.

I've added an item to the status page.

    http://www.phekda.freeserve.co.uk/richdawe/djgpp/2.04/status204.html

> > I'm starting to think that it's better to get 2.04 soon than put yet more
> > features in it. The bug fixes and features in it justify a release soon
> > IMHO.
> > We can always do a "short" release cycle for 2.05 (haha) - say a year to a
> > year and a half.
> 
> If we put 2.04 out too soon, I'm thinking more like a 3-6 month refresh
> would be required.

My concern is that it's going to take another year or so to get it out. We
haven't even got an alpha release to Simtel.NET for testing yet. I expect it
has got a fair bit of testing, based on Andrew's builds on clio.

I'm wondering if there should be some kind of vote. Or maybe DJ could decide?

Having said that I'd be release manager I haven't actually managed a release
yet. Oh well.

Bye, Rich =]

-- 
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]

- Raw text -