Re:

Re:

[Bryce McKinlay]

Tom Tromey wrote:

>I'm checking this in on the trunk.  If I remember I'll put it on the
>4.0 branch once it reopens (there are a fair number of patches pending
>for it ... I hope it reopens soon).
>  
>

Mark,

The extended freeze of the 4.0 branch is making things difficult for 
libgcj because we have a large backlog of runtime patches which we are 
unable to apply at this time. The longer the freeze continues, the more 
difficult it becomes for us to keep track of what needs applying and 
increases the chances that something will be forgotten, resulting in 
problems and wasted time further down the line.

Could we get an exemption from the freeze rules for low-risk, runtime 
only libgcj fixes as determined by the libgcj maintainers? 
Alternatively, could we rethink our release policy to ensure that the 
duration of freezes is minimized in the future? I do think that a hard 
freeze in the days leading up to a release is useful and important, but 
keeping it in place for weeks just because a couple of bugs remain 
unfixed doesn't seem helpful.

Thanks

Bryce

Re:

[Mark Mitchell]

Bryce McKinlay wrote:

> 
> Mark,

> Could we get an exemption from the freeze rules for low-risk, runtime 
> only libgcj fixes as determined by the libgcj maintainers? 

I don't think we want to do that.

First, we're close to a release.  We've been waiting on one fix since 
Friday, and Jeff Law has promised to fix it today.

Second, the whole point of freezes is to ensure stability.  We're going 
to RC3 on this release because we've found bad problems in RC1 and RC2. 
  If a change were to be checked in, for whatever reason, happens to 
break something, then we need an RC4, and everybody loses.

> Alternatively, could we rethink our release policy to ensure that the 
> duration of freezes is minimized in the future? I do think that a hard 
> freeze in the days leading up to a release is useful and important, but 
> keeping it in place for weeks just because a couple of bugs remain 
> unfixed doesn't seem helpful.

Obviously, I'd like to have a shorter freeze period.  This is the 
longest pre-release freeze I can remember since I've been running 
releases.  That reflects the fact that a lot of critical problems were 
uncovered in 4.0.0, including some during the 4.0.1 release process.

The way to get a shorter freeze period is to have fewer bugs and to fix 
them more quickly.  I think that this release is somewhat exceptional in 
that after we released 4.0.0, a lot of people started using a lot of new 
technology, and, unsurprisingly, there are more bugs in 4.0.0 than in 
the average release.

Please hang in there.

Thanks,

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: Re:

[Jeffrey A Law]

On Wed, 2005-06-29 at 13:39 -0700, Mark Mitchell wrote:
> First, we're close to a release.  We've been waiting on one fix since 
> Friday, and Jeff Law has promised to fix it today.
The fix is written, I'm just waiting on test results.  Someone mucked
up the hpux11 target description (*) which caused libstdc++ to fail to
build and I had to re-bootstrap after working around that bit of 
lameness.

I'd be surprised if I had results tonight.  More likely early tomorrow
assuming the machines keep running (I killed one in Raleigh yesterday
to go along with the one in my basement...)


Jeff

(*)  The hpux11 target description assumes that the linker shipped with
hpux11 supports +init as an option.  Well, that may work OK for some
versions of hpux11, but it certainly doesn't work for hpux11.00 with
the 990903 version of the linker.  Grrr.

Re:

[Geoffrey Keating]

Mark Mitchell <mark@codesourcery.com> writes:

> Bryce McKinlay wrote:
> 
> > Mark,
> 
> > Could we get an exemption from the freeze rules for low-risk,
> > runtime only libgcj fixes as determined by the libgcj maintainers?
> 
> I don't think we want to do that.
> 
> First, we're close to a release.  We've been waiting on one fix since
> Friday, and Jeff Law has promised to fix it today.
> 
> Second, the whole point of freezes is to ensure stability.  We're
> going to RC3 on this release because we've found bad problems in RC1
> and RC2. If a change were to be checked in, for whatever reason,
> happens to break something, then we need an RC4, and everybody loses.

This kind of conflict is solved in version control systems by the use
of branches...

Re: Re:

[Joe Buck]

On Wed, Jun 29, 2005 at 03:53:18PM -0600, Jeffrey A Law wrote:
> (*)  The hpux11 target description assumes that the linker shipped with
> hpux11 supports +init as an option.  Well, that may work OK for some
> versions of hpux11, but it certainly doesn't work for hpux11.00 with
> the 990903 version of the linker.  Grrr.

I have an hpux11.0 box available, and could run tests of your patch
if you like.

Re:

[Aalokrai Porwal]

Hi Guys,

I don't any feedback but I am having problem sending to gcc@gcc.gnu.org. Is 
there a trick to send email? I signed up for the mailing list today. Any 
suggestion would be helpful.

Best regards,
~Aalok

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: Re: hpux regression vs 4.0.1

[Jeffrey A Law]

On Wed, 2005-06-29 at 16:17 -0700, Joe Buck wrote:
> On Wed, Jun 29, 2005 at 03:53:18PM -0600, Jeffrey A Law wrote:
> > (*)  The hpux11 target description assumes that the linker shipped with
> > hpux11 supports +init as an option.  Well, that may work OK for some
> > versions of hpux11, but it certainly doesn't work for hpux11.00 with
> > the 990903 version of the linker.  Grrr.
> 
> I have an hpux11.0 box available, and could run tests of your patch
> if you like.
I doubt it would have (or will make) much of a difference at this
point.  I don't think anyone could have predicted the muck-up with
the arguments passed to ld and the re-bootstrap that had to run
after working around it.

As long as I don't kill this 3rd machine I think we'll be OK.

jeff

Re: Re: hpux regression vs 4.0.1

[John David Anglin]

> > I have an hpux11.0 box available, and could run tests of your patch
> > if you like.
> I doubt it would have (or will make) much of a difference at this
> point.  I don't think anyone could have predicted the muck-up with
> the arguments passed to ld and the re-bootstrap that had to run
> after working around it.

HP bug fixed in one of their many linker updates.  The linker
requirements are documented but I can appreciate one just expects
things to work in an emergency...

> As long as I don't kill this 3rd machine I think we'll be OK.

If you have problems, please send the patch for testing.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)