* Re: [not found] <m3d5q5b0pw.fsf@localhost.localdomain> @ 2005-06-29 18:48 ` Bryce McKinlay 2005-06-29 20:40 ` Re: Mark Mitchell 0 siblings, 1 reply; 8+ messages in thread From: Bryce McKinlay @ 2005-06-29 18:48 UTC (permalink / raw) To: tromey; +Cc: Java Patch List, gcc, Mark Mitchell 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: 2005-06-29 18:48 ` Bryce McKinlay @ 2005-06-29 20:40 ` Mark Mitchell 2005-06-29 21:54 ` Re: Jeffrey A Law 2005-06-29 21:57 ` Geoffrey Keating 0 siblings, 2 replies; 8+ messages in thread From: Mark Mitchell @ 2005-06-29 20:40 UTC (permalink / raw) To: Bryce McKinlay; +Cc: tromey, Java Patch List, gcc 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Re: 2005-06-29 20:40 ` Re: Mark Mitchell @ 2005-06-29 21:54 ` Jeffrey A Law 2005-06-29 23:17 ` Re: Joe Buck 2005-06-29 21:57 ` Geoffrey Keating 1 sibling, 1 reply; 8+ messages in thread From: Jeffrey A Law @ 2005-06-29 21:54 UTC (permalink / raw) To: Mark Mitchell; +Cc: Bryce McKinlay, tromey, Java Patch List, gcc 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Re: 2005-06-29 21:54 ` Re: Jeffrey A Law @ 2005-06-29 23:17 ` Joe Buck 2005-06-29 23:45 ` Re: hpux regression vs 4.0.1 Jeffrey A Law 0 siblings, 1 reply; 8+ messages in thread From: Joe Buck @ 2005-06-29 23:17 UTC (permalink / raw) To: Jeffrey A Law; +Cc: Mark Mitchell, Bryce McKinlay, tromey, Java Patch List, gcc 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Re: hpux regression vs 4.0.1 2005-06-29 23:17 ` Re: Joe Buck @ 2005-06-29 23:45 ` Jeffrey A Law 0 siblings, 0 replies; 8+ messages in thread From: Jeffrey A Law @ 2005-06-29 23:45 UTC (permalink / raw) To: Joe Buck; +Cc: Mark Mitchell, Bryce McKinlay, tromey, Java Patch List, gcc 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: 2005-06-29 20:40 ` Re: Mark Mitchell 2005-06-29 21:54 ` Re: Jeffrey A Law @ 2005-06-29 21:57 ` Geoffrey Keating 2005-06-29 23:43 ` Re: Aalokrai Porwal 1 sibling, 1 reply; 8+ messages in thread From: Geoffrey Keating @ 2005-06-29 21:57 UTC (permalink / raw) To: Mark Mitchell; +Cc: tromey, Java Patch List, gcc 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... ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: 2005-06-29 21:57 ` Geoffrey Keating @ 2005-06-29 23:43 ` Aalokrai Porwal 0 siblings, 0 replies; 8+ messages in thread From: Aalokrai Porwal @ 2005-06-29 23:43 UTC (permalink / raw) To: geoffk, mark; +Cc: tromey, java-patches, gcc 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/ ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Re: hpux regression vs 4.0.1 @ 2005-06-30 0:34 John David Anglin 0 siblings, 0 replies; 8+ messages in thread From: John David Anglin @ 2005-06-30 0:34 UTC (permalink / raw) To: gcc; +Cc: law, joe.buck, mark > > 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) ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2005-06-30 0:34 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <m3d5q5b0pw.fsf@localhost.localdomain> 2005-06-29 18:48 ` Bryce McKinlay 2005-06-29 20:40 ` Re: Mark Mitchell 2005-06-29 21:54 ` Re: Jeffrey A Law 2005-06-29 23:17 ` Re: Joe Buck 2005-06-29 23:45 ` Re: hpux regression vs 4.0.1 Jeffrey A Law 2005-06-29 21:57 ` Geoffrey Keating 2005-06-29 23:43 ` Re: Aalokrai Porwal 2005-06-30 0:34 Re: hpux regression vs 4.0.1 John David Anglin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).