Re: GCC 4.3 release schedule
Dennis Clarke wrote: Is "correctness" a feature ? Yes, but not one that gets merged in during stage 1 :) I would like to see a nice clean GCC 4.2.x before GCC 4.3.zero even gets thought of. Why would one simply branch towards the next release when the previous one still needs some work? To appease sales people and developers making noises for features? Planning for 4.3.0 has no effect at all on the 4.2.x schedule. People work on 4.2.x or not depending on their own priorities. I've fixed a few bugs in 4.2 since the 4.2.2 release, and I fully expect there will be at least a 4.2.3 before 4.3.0 goes out. Distributors are interested in a timely 4.3.0 because they'll be using whatever compiler they settle on for a long time and would like it to be up to date. Sometimes some of the new features are important to support the needs of other parts of the system. Jason
Re: GCC 4.3 release schedule
> I'd rather take the make the dot-zero release approach while branching > and count on interested people fixing bugs on the branch after the > dot-zero release. This way if nobody is interested on a particular > release series then we can declare the dot-zero release final - > otherwise we'd do more releases from the branch anyway. Quite honestly, I think a version of this basic idea is an improvement over the current vague procedures, and certainly worth trying. I would be open to experimentation in the gcc release procedure, especially after the trials of the 4.2.x series. Aligning Stage 1 freedoms immeidately after the confinements of Stage 3 branch/dot-zero-release seems to be the most natural way to motivate work on Stage 3 fixing/polishing. Our current procedure works against this natural flow. So, the way I see it, something like this: - now till < 100 bugs: Stage 3. Weekly bug counts sent to gcc list. - < 100 bugs: mainline freeze, branch, lockdown for two weeks. All hands on board for release. All checkins must have bz#. End two week lockdown with 4.3.0 release candidate 1. - 4.3.0.rc1 release, mainline Stage 1. + 2 weeks, 4.3.0.rc2. - 4.3.0.rc2 + 2 weeks, 4.3.0 final. (or mainline Stage 1 here?) Temporary pain for long-term gain. Anyway. I'm surprised this suggestion did not get more comments. This is much more transparent than current procedures, and has a chance of focusing the gcc community on releases, not on the wide-open gates of Stage 1. -benjamin
Re: GCC 4.3 release schedule
Benjamin Kosnik wrote: I'd rather take the make the dot-zero release approach while branching and count on interested people fixing bugs on the branch after the dot-zero release. This way if nobody is interested on a particular release series then we can declare the dot-zero release final - otherwise we'd do more releases from the branch anyway. Quite honestly, I think a version of this basic idea is an improvement over the current vague procedures, and certainly worth trying. I would be open to experimentation in the gcc release procedure, especially after the trials of the 4.2.x series. Aligning Stage 1 freedoms immeidately after the confinements of Stage 3 branch/dot-zero-release seems to be the most natural way to motivate work on Stage 3 fixing/polishing. Our current procedure works against this natural flow. So, the way I see it, something like this: - now till < 100 bugs: Stage 3. Weekly bug counts sent to gcc list. - < 100 bugs: mainline freeze, branch, lockdown for two weeks. All hands on board for release. All checkins must have bz#. End two week lockdown with 4.3.0 release candidate 1. - 4.3.0.rc1 release, mainline Stage 1. + 2 weeks, 4.3.0.rc2. - 4.3.0.rc2 + 2 weeks, 4.3.0 final. (or mainline Stage 1 here?) Temporary pain for long-term gain. Anyway. I'm surprised this suggestion did not get more comments. This is much more transparent than current procedures, and has a chance of focusing the gcc community on releases, not on the wide-open gates of Stage 1. -benjamin The only problem, is that anyone doing stage 1 work is already doing so in a branch, and history (at least as I remember it :-) is that if little johnny doesn't have a pressing need for the current release, he will simply keep plugging along on his branch until stage 1 happens, whether its 2 weeks away or 3 months. But yes, Id still be in favour of trying this or anything else which might help. Cut a release branch, and simply refuse to open stage 1 until we release. Something has to help. Often there is a race for merging branches when stage 1 opens (the earlier you merge, the easier it is). Maybe we can have a short stage 0.9 for merging of branches/work to mainline for those that contributed to getting the release out. Maybe that would help too, but then you'd have to define "contribution" :-). Ultimately, we need to get people interested in actually getting a release out. I don't know of an easier way do that than aligning your desire to have a release with someone else wanting to use it. That at least motivates them, and locking into stage 3 until its released may encourage others to assist. Andrew
Re: GCC 4.3 release schedule
> The only problem, is that anyone doing stage 1 work is already doing > so in a branch, and history (at least as I remember it :-) is that > if little johnny doesn't have a pressing need for the current > release, he will simply keep plugging along on his branch until stage > 1 happens, whether its 2 weeks away or 3 months. Ahhh... but you show the way to induce participation here: > But yes, Id still be in favour of trying this or anything else which > might help. Cut a release branch, and simply refuse to open stage 1 > until we release. Something has to help. Often there is a race for > merging branches when stage 1 opens (the earlier you merge, the > easier it is). Maybe we can have a short stage 0.9 for merging of > branches/work to mainline for those that contributed to getting the > release out. Maybe that would help too, but then you'd have to define > "contribution" :-). This 0.9 stage idea is golden. Why don't we just straight out rank bugs closed to merge priority? Most bugs fixed means first merge in stage one, period. Second higest # of bugs fixed means second merge, etc etc. That really aligns things correctly! -benjamin
Re: GCC 4.3 release schedule
On 10/29/07, Benjamin Kosnik <[EMAIL PROTECTED]> wrote: > > > The only problem, is that anyone doing stage 1 work is already doing > > so in a branch, and history (at least as I remember it :-) is that > > if little johnny doesn't have a pressing need for the current > > release, he will simply keep plugging along on his branch until stage > > 1 happens, whether its 2 weeks away or 3 months. > > Ahhh... but you show the way to induce participation here: > > > But yes, Id still be in favour of trying this or anything else which > > might help. Cut a release branch, and simply refuse to open stage 1 > > until we release. Something has to help. Often there is a race for > > merging branches when stage 1 opens (the earlier you merge, the > > easier it is). Maybe we can have a short stage 0.9 for merging of > > branches/work to mainline for those that contributed to getting the > > release out. Maybe that would help too, but then you'd have to define > > "contribution" :-). > > This 0.9 stage idea is golden. > > Why don't we just straight out rank bugs closed to merge priority? Most > bugs fixed means first merge in stage one, period. Second higest # of > bugs fixed means second merge, etc etc. > > That really aligns things correctly! I'd rather rate along highest # of bugs still open in subsystem merged by contributor. Those get to merge last, as they didn't show incentive to maintain their merged code (and yes, this happens). Richard.
Re: GCC 4.3 release schedule
Andrew MacLeod wrote: But yes, Id still be in favour of trying this or anything else which might help. Cut a release branch, and simply refuse to open stage 1 until we release. I think I prefer Richard's suggestion of not branching until we're ready to make the .0 release. The effect should be the same except that people don't have to deal with checking patches in on the branch vs. the trunk until after 4.3.0 goes out. Jason
Re: GCC 4.3 release schedule
Jason Merrill wrote: Andrew MacLeod wrote: But yes, Id still be in favour of trying this or anything else which might help. Cut a release branch, and simply refuse to open stage 1 until we release. I think I prefer Richard's suggestion of not branching until we're ready to make the .0 release. The effect should be the same except that people don't have to deal with checking patches in on the branch vs. the trunk until after 4.3.0 goes out. Sure, I think it boils down to the same thing from a conceptual point of view, but perhaps the nitty gritty details are easier if you keep it as mainline so we dont have to check everything into 2 branches. Bottom line is you freeze development until its time to release. Andrew
Re: GCC 4.3 release schedule
On 10/29/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote: > Jason Merrill wrote: > > Andrew MacLeod wrote: > >> But yes, Id still be in favour of trying this or anything else which > >> might help. Cut a release branch, and simply refuse to open stage 1 > >> until we release. > > > > I think I prefer Richard's suggestion of not branching until we're > > ready to make the .0 release. The effect should be the same except > > that people don't have to deal with checking patches in on the branch > > vs. the trunk until after 4.3.0 goes out. > > Sure, I think it boils down to the same thing from a conceptual point of > view, but perhaps the nitty gritty details are easier if you keep it as > mainline so we dont have to check everything into 2 branches. Bottom > line is you freeze development until its time to release. Well... this is the point of having stage3 ;) Of course work goes on on branches. One point of essentially freezing mainline until the release is to not pessimize people fixing bugs for the release instead of doing work on the already-open-after-branching stage1. This theoretically would allow shortening stage1 drastically (to lets say 2 weeks of branch merging and another 4 weeks of general "patches") to get back to a 6 month release cycle (I personally think the each-stage-is-2-month is not realistic). Richard.
Re: GCC 4.3 release schedule
On 10/29/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote: > Richard Guenther wrote: > >> Sure, I think it boils down to the same thing from a conceptual point of > >> view, but perhaps the nitty gritty details are easier if you keep it as > >> mainline so we dont have to check everything into 2 branches. Bottom > >> line is you freeze development until its time to release. > >> > > > > Well... this is the point of having stage3 ;) Of course work goes on on > > branches. One point of essentially freezing mainline until the release > > is to not pessimize people fixing bugs for the release instead of doing > > work on the already-open-after-branching stage1. This theoretically > > > > but people do continue working on branches parallel to stage 3, and we > are looking for a way to focus people onto stage 3 in order to get it > out in a timely fashion. simply locking it down doesn't do that, either > in a branch or on mainline, we've seen it in the past. I've been guilty > of it. I have had other big ticket items I'm working on, and if the > release isn't something that fits into plans anywhere, it doesn't matter > when it gets released, so the other work is more important. And lets > face it, bug fixing isn't exciting and motivating work to most people. > We need a reason to get interested enough to focus on getting the > release out. That's true. We need to ensure we end stage3 with a release (even if it will be of worse quality than usual, just because nobody was really interested in it). Just opening stage1 and _not_ releasing doesn't make this particular situation better. > > would allow shortening stage1 drastically (to lets say 2 weeks of > > branch merging and another 4 weeks of general "patches") to get back > > to a 6 month release cycle (I personally think the each-stage-is-2-month > > is not realistic). > > > > > I don't think we need a 6 month release cycle myself, but maybe thats > just me. Are people actually looking for new compilers that > frequently? I wouldn't think that would be the norm. thats barely time > for the compiler to properly stabilize. I think it would be even harder > to get focus on stage 3 that frequently. I still think we need to try to > have a look at the schedules of the various groups that USE the > compiler, and set our release schedules to something that is going to be > useful to multiple groups, thus generating the most interest in a release. *sigh* - also true. I thought with a shorter release cycle it would be easier to tell people "no, your feature is not ready for this stage1, just wait N month until next stage1" with N being reasonable (that is, less than half a year). For 4.3 we had a nearly 8 month stage1(!) and doing release planning in advance (the scheduled project list) before any code exists doesn't help this. We simply shouldn't promise to merge anything for a specific release. We should merge things when they are ready and when trunk is in the right stage. But I guess the GCC development model just doesn't work like this :( Richard.
Re: GCC 4.3 release schedule
Richard Guenther wrote: Sure, I think it boils down to the same thing from a conceptual point of view, but perhaps the nitty gritty details are easier if you keep it as mainline so we dont have to check everything into 2 branches. Bottom line is you freeze development until its time to release. Well... this is the point of having stage3 ;) Of course work goes on on branches. One point of essentially freezing mainline until the release is to not pessimize people fixing bugs for the release instead of doing work on the already-open-after-branching stage1. This theoretically but people do continue working on branches parallel to stage 3, and we are looking for a way to focus people onto stage 3 in order to get it out in a timely fashion. simply locking it down doesn't do that, either in a branch or on mainline, we've seen it in the past. I've been guilty of it. I have had other big ticket items I'm working on, and if the release isn't something that fits into plans anywhere, it doesn't matter when it gets released, so the other work is more important. And lets face it, bug fixing isn't exciting and motivating work to most people. We need a reason to get interested enough to focus on getting the release out. would allow shortening stage1 drastically (to lets say 2 weeks of branch merging and another 4 weeks of general "patches") to get back to a 6 month release cycle (I personally think the each-stage-is-2-month is not realistic). I don't think we need a 6 month release cycle myself, but maybe thats just me. Are people actually looking for new compilers that frequently? I wouldn't think that would be the norm. thats barely time for the compiler to properly stabilize. I think it would be even harder to get focus on stage 3 that frequently. I still think we need to try to have a look at the schedules of the various groups that USE the compiler, and set our release schedules to something that is going to be useful to multiple groups, thus generating the most interest in a release. Andrew
RE: GCC 4.3 release schedule
> -Original Message- > From: Andrew MacLeod [mailto:[EMAIL PROTECTED] > Sent: Monday, October 29, 2007 12:48 PM > To: Richard Guenther > Cc: Jason Merrill; Benjamin Kosnik; gcc@gcc.gnu.org; > [EMAIL PROTECTED] > Subject: Re: GCC 4.3 release schedule > I don't think we need a 6 month release cycle myself, but maybe thats > just me. Are people actually looking for new compilers that > frequently? It depends on the community using it. For the AVR, 3-6 months is the norm because of the need to have support for new AVR devices (variants). We're currently working adding 19 new devices for the next release cycle. Eric Weddington
Re: GCC 4.3 release schedule
On 10/29/07, Benjamin Kosnik <[EMAIL PROTECTED]> wrote: > > > I think I prefer Richard's suggestion of not branching until we're > > ready to make the .0 release. The effect should be the same except > > that people don't have to deal with checking patches in on the branch > > vs. the trunk until after 4.3.0 goes out. > > This would certainly make things easier. And easier is fine by me... > > Jason, any thoughts on how to translate "ready to make a .0 release" > into "made a .0 release," in terms of a firm schedule, with dates? I'm > assuming that the < 100 bugzilla count is an adequate milestone for the > release branch to be cut. > > Or do you think < 100 implies branch implies 4.3.0 release, as > originally described by Richard is the way to go? > > I'm willing to try this. It's just that I would like some advance notice > before a release, just to check over things. (Say, a week. Maybe two. It > doesn't have to be a long time. And it should definitely not stretch > to 1 or 7 months...) Sure. I'd expect the usual release candidate or two separated by one or two weeks. I'd also expect the mainline to be frozen after rc1. I guess branching can happen at the point there is either rc2 or the 4.3.0 release. > Just curious. I think we all agree on the general goal of a rapid and > timely release once the branch is cut. It's the specific details that > I'm curious to learn... We'll all learn as this would be the first time we do it this way ;) Richard.
Re: GCC 4.3 release schedule
I've a fast idea. To release now it as gcc-4.3.0 if the building of distribution's base doesn't crashes. To start the branch for gcc-4.4-ss. Many linux's people start to test gcc-4.3.0 from their distributions and to report their bugs. Tomorrow, we will have a rocked gcc-4.3.15 quickly possible. J.C. Pizarro
Re: GCC 4.3 release schedule
> I think I prefer Richard's suggestion of not branching until we're > ready to make the .0 release. The effect should be the same except > that people don't have to deal with checking patches in on the branch > vs. the trunk until after 4.3.0 goes out. This would certainly make things easier. And easier is fine by me... Jason, any thoughts on how to translate "ready to make a .0 release" into "made a .0 release," in terms of a firm schedule, with dates? I'm assuming that the < 100 bugzilla count is an adequate milestone for the release branch to be cut. Or do you think < 100 implies branch implies 4.3.0 release, as originally described by Richard is the way to go? I'm willing to try this. It's just that I would like some advance notice before a release, just to check over things. (Say, a week. Maybe two. It doesn't have to be a long time. And it should definitely not stretch to 1 or 7 months...) Just curious. I think we all agree on the general goal of a rapid and timely release once the branch is cut. It's the specific details that I'm curious to learn... -benjamin
Re: GCC 4.3 release schedule
Richard Guenther wrote: > Sure. I'd expect the usual release candidate or two separated by > one or two weeks. I'd also expect the mainline to be frozen after rc1. > I guess branching can happen at the point there is either rc2 or > the 4.3.0 release. I'm following this discussion closely, of course. To tell the truth, I'm pleased that consensus seems to be developing around delaying Stage 1 until we have a release out the door. My only concern with that in the past has been that people might not be willing to do it. Not creating a branch will somewhat increase pressure to focus on the release -- but that will only work if enough people are actually motivated to work on the release anyhow. It seems like there's enough momentum in this cycle to make that work. I'll keep listening, in case there's more feedback, but it seems like a good plan to me. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.3 release schedule
Benjamin Kosnik wrote: Jason, any thoughts on how to translate "ready to make a .0 release" into "made a .0 release," in terms of a firm schedule, with dates? I'm assuming that the < 100 bugzilla count is an adequate milestone for the release branch to be cut. Or do you think < 100 implies branch implies 4.3.0 release, as originally described by Richard is the way to go? No. Previously we've branched at <100 regressions, but waited for the numbers to get better than that before making the release. I'm suggesting that the release criteria stay about the same as before, just that we delay the branch until the release is ready rather than have branch criteria and then release criteria. I'm willing to try this. It's just that I would like some advance notice before a release, just to check over things. I would expect Mark's status mails to cover that. Jason
Re: GCC 4.3 release schedule
Jason Merrill wrote: > No. Previously we've branched at <100 regressions, but waited for the > numbers to get better than that before making the release. I'm > suggesting that the release criteria stay about the same as before, just > that we delay the branch until the release is ready rather than have > branch criteria and then release criteria. Yes, that's what I'm imagining too, under this plan. All we'd be doing differently is delaying Stage 1 until after the release, instead of parallelizing Stage 1 with the final release preparation. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.3 release schedule
Richard Guenther writes: > On 10/26/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote: > > > Note that we are building what-becomes-openSUSE 11.0 with current trunk > > > in parallel to 4.2 at the moment, switching to 4.3 is in the next weeks > > > (unless I get pushed back again ;)). > > > > > > > > It would be excellent to have both openSUSE and fedora pounding on 4.3 > > at the same time. > > Yes. I think Ubuntu is on track for 4.3 as well, most likely Debian, too. Ubuntu did plan the 2008 April release (8.04) with a compiler taken from the 4.2 branch; the main repository is already fixed to build with 4.3 and build tests are run regularily, so a change to 4.3 could be considered. About 5% of the packages needed a change to build with 4.3 (most of them added C++ headers). Debian's next release will be around fall 2008 (or later, when its ready), considering 4.3 as the system compiler, hopefully for all 10+ architectures. Both distributions do not rebuild the archive by default when changing the compiler version, so the new compiler is only used for new package uploads. For previous releases APIs of runtime libraries were changed up to close the release date. This makes it somewhat difficult to already use a prerelease version of the compiler in the distribution (or all packages uploaded between the compiler upload and the upload of a fixed comiler need to be rebuilt, which might be difficult for the slower Debian architectures). Would the GCC developers consider an ABI/API freeze somehwat between beginning of stage3 and the release? Matthias
Re: GCC 4.3 release schedule
On Mon, 29 Oct 2007, Jason Merrill wrote: > I think I prefer Richard's suggestion of not branching until we're ready to > make the .0 release. The effect should be the same except that people don't > have to deal with checking patches in on the branch vs. the trunk until after > 4.3.0 goes out. I like this approach. Gerald
Re: GCC 4.3 release schedule
Gerald Pfeifer wrote: On Mon, 29 Oct 2007, Jason Merrill wrote: I think I prefer Richard's suggestion of not branching until we're ready to make the .0 release. The effect should be the same except that people don't have to deal with checking patches in on the branch vs. the trunk until after 4.3.0 goes out. I like this approach. So have we come to some sort of consensus here? We leave mainline as stage 3 until we release? or at least have a somewhat final release candidate? Once we hit the target of 100 open PRs,( or whenever we would have originally cut a stage 3 release branch), we firm up stage 3 so that *really* only bugfixes go in. Then we work toward a release candidate, etc etc.? We can play it by ear, but do you want to wait to open stage 1 until we actually release 4.3, or do it after RC2 or something like that where there isn't much else going to happen to it? Either works for me, but I don't see that opening stage 1 before we actually release buys us much. Andrew
Re: GCC 4.3 release schedule
> >> I think I prefer Richard's suggestion of not branching until we're > >> ready to make the .0 release. The effect should be the same > >> except that people don't have to deal with checking patches in on > >> the branch vs. the trunk until after 4.3.0 goes out. > >> > > > > I like this approach. Me too. I'm also very pleased that the RM and SC are open and willing to consider changes of this nature to GCC release procedure. Thanks. > So have we come to some sort of consensus here? We leave mainline as > stage 3 until we release? or at least have a somewhat final release > candidate? The summary of this thread is that opening stage 1 before we release hurts us. So, we're trying to figure out another way. I think there is consensus that this is a good idea. Well, maybe not consensus, but all the posted commentary seems in favor. I assume if people objected, they'd say something... > Once we hit the target of 100 open PRs,( or whenever we would have > originally cut a stage 3 release branch), we firm up stage 3 so that > *really* only bugfixes go in. Then we work toward a release > candidate, etc etc.? I guess. This is the part that is less certain to me. There is less consensus here, in that Richard and I are advocating a strict time-based release schedule once the < 100 PR bit is flipped, with staggered RCs. (Richard, I hope this generalized summary is accurate.) Jason and Mark seem to be less impressed with this specific part. > We can play it by ear, but do you want to wait to open stage 1 until > we actually release 4.3, or do it after RC2 or something like that > where there isn't much else going to happen to it? Either works for > me, but I don't see that opening stage 1 before we actually release > buys us much. So, I'd guess Stage 1 opens after 4.3.0 is released, or at least tagged in SVN. -benjamin
Re: GCC 4.3 release schedule
On 10/26/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote: > > Now that GCC is in stage 4.3, I think we'd all be in agreement that it > would be nice to keep this stage short and get a release out. Let me suggest something which is going sound a little crazy. Create a beta that is released now and then release one once (or twice) a month until we release 4.3. This is seperate from a release candidate and the snapshot. The beta is get attention from some folks that would not have used the snapshot before. It might get say some Fortran developers or some interesting C++ developers using it. We can write a little thing up on why we are doing the beta, C++0x support, more fortran support and vectorizer turned on by default at -O3. -- Pinski
Re: GCC 4.3 release schedule
Andrew Pinski wrote: On 10/26/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote: Now that GCC is in stage 4.3, I think we'd all be in agreement that it would be nice to keep this stage short and get a release out. Let me suggest something which is going sound a little crazy. Create a beta that is released now and then release one once (or twice) a month until we release 4.3. This is seperate from a release candidate and the snapshot. The beta is get attention from some folks that would not have used the snapshot before. It might get say some Fortran developers or some interesting C++ developers using it. We can write a little thing up on why we are doing the beta, C++0x support, more fortran support and vectorizer turned on by default at -O3. Im not sure what that buys us. All the critical users are involved in creating the RC's. If we want others to use it, let them use the first RC and call it beta 1 instead/as well. I think most casual users will do the same thing I do for a linux distro, simply wait for the release so you are less likely to have to deal with instabilities. Andrew
Re: GCC 4.3 release schedule
On Thu, Nov 01, 2007 at 09:50:00AM -0700, Andrew Pinski wrote: > Create a beta that is released now and then release one once (or > twice) a month until we release 4.3. This is seperate from a release > candidate and the snapshot. The beta is get attention from some folks > that would not have used the snapshot before. It might get say some > Fortran developers or some interesting C++ developers using it. We > can write a little thing up on why we are doing the beta, C++0x > support, more fortran support and vectorizer turned on by default at > -O3. I would like this. It's common for snapshots to fail to build (at least on my machines), which is definitely a discouragement from trying them too often, and by the time the RCs hit it's way too late to do much about any problems but file a bug and hope it gets fixed in the next release. -Jack
Re: GCC 4.3 release schedule
On Thu, Nov 01, 2007 at 01:55:04PM -0400, Jack Lloyd wrote: > I would like this. It's common for snapshots to fail to build (at > least on my machines), which is definitely a discouragement from > trying them too often, and by the time the RCs hit it's way too late > to do much about any problems but file a bug and hope it gets fixed in > the next release. Perhaps we should make a prerelease now and call it a Technology Preview then... :-) -- Daniel Jacobowitz CodeSourcery
Re: GCC 4.3 release schedule
On 11/1/07, Benjamin Kosnik <[EMAIL PROTECTED]> wrote: > > Once we hit the target of 100 open PRs,( or whenever we would have > > originally cut a stage 3 release branch), we firm up stage 3 so that > > *really* only bugfixes go in. Then we work toward a release > > candidate, etc etc.? > > I guess. This is the part that is less certain to me. There is less > consensus here, in that Richard and I are advocating a strict > time-based release schedule once the < 100 PR bit is flipped, with > staggered RCs. (Richard, I hope this generalized summary is accurate.) No, I was suggesting a more "when we think it's ready" approach (so, leave it basically unspecified). Of course we have the usual indicators of the number of regressions against previous releases and the number of P1 bugs. I don't think there should be any automatism at the point we reach <100 regressions. Rather for example once that happens, going over the remaining regressions and deciding which ones we want to fix before the release and doing so. Of course at some point a RC is warranted, as only that might be tested by some more obscure targets. > Jason and Mark seem to be less impressed with this specific part. I'd agree with them. Richard.
Re: GCC 4.3 release schedule
On 11/1/07, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote: > On Thu, Nov 01, 2007 at 01:55:04PM -0400, Jack Lloyd wrote: > > I would like this. It's common for snapshots to fail to build (at > > least on my machines), which is definitely a discouragement from > > trying them too often, and by the time the RCs hit it's way too late > > to do much about any problems but file a bug and hope it gets fixed in > > the next release. > > Perhaps we should make a prerelease now and call it a Technology > Preview then... :-) Well, there are installable gcc 4.3 builds for openSUSE available, and I know of at least Debian packages in experimental. I wouldn't be surprised if Fedora also has gcc 4.3 packages ready. So Technology Previews are out there ;) Richard.
Re: GCC 4.3 release schedule
Jack Lloyd wrote: On Thu, Nov 01, 2007 at 09:50:00AM -0700, Andrew Pinski wrote: Create a beta that is released now and then release one once (or twice) a month until we release 4.3. This is seperate from a release candidate and the snapshot. The beta is get attention from some folks that would not have used the snapshot before. It might get say some Fortran developers or some interesting C++ developers using it. We can write a little thing up on why we are doing the beta, C++0x support, more fortran support and vectorizer turned on by default at -O3. I would like this. It's common for snapshots to fail to build (at least on my machines), which is definitely a discouragement from trying them too often, and by the time the RCs hit it's way too late to do much about any problems but file a bug and hope it gets fixed in the next release. I'd suggest we are close to a beta state right now, so if it fails to build there ought to be a high priority PR opened. Andrew
Re: GCC 4.3 release schedule
On Thu, 1 Nov 2007, Richard Guenther wrote: > Well, there are installable gcc 4.3 builds for openSUSE available, > and I know of at least Debian packages in experimental. I wouldn't > be surprised if Fedora also has gcc 4.3 packages ready. FreeBSD also has packages (and of course the source ports) available. ;-) Gerald
Re: GCC 4.3 release schedule
On 11/1/07, Gerald Pfeifer <[EMAIL PROTECTED]> wrote: > On Mon, 29 Oct 2007, Jason Merrill wrote: > > I think I prefer Richard's suggestion of not branching until we're ready to > > make the .0 release. The effect should be the same except that people don't > > have to deal with checking patches in on the branch vs. the trunk until > > after > > 4.3.0 goes out. > > I like this approach. Likewise. Diego.
Re: GCC 4.3 release schedule
On 10/26/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote: > > Now that GCC is in stage 4.3, I think we'd all be in agreement that it > would be nice to keep this stage short and get a release out. > > We are interested in using 4.3 as the system compiler in Fedora 9, and > as such, we'd like to nail down some time lines and requirements with > release management and the steering committee. Of course it doesn't work like this ;) > The timelines involved are something like this: (clearly anything > earlier would be great :-) > > Nov 14th - we'd like to start building F9 with a 4.3 compiler. Ideally > we'd have a branch cut no later than that and starting to stabilize > without much new code going in. I oppose to cut a branch without immediately releasing 4.3.0. This just doesn't work - just look at the history. I also think that Nov 14th is _very_ optimistic (I personally was thinking about a (early) Q1 release). Note that we are building what-becomes-openSUSE 11.0 with current trunk in parallel to 4.2 at the moment, switching to 4.3 is in the next weeks (unless I get pushed back again ;)). > Dec 14th - viability decision on using 4.3 as the F9 compiler. There is > a window here as late as Jan 14th, but the opinions will start forming > in Dec. There shouldn't be any ABI changes from this point on. > Feb 29th - Optimistic target date for a 4.3 release. can slip as much > as a month, but clearly the earlier the release happens the better. If we branch too early I bet we will not make even the Feb 29th date. How does targeting a release around Feb 1st sound (that is, without branching before, a RC1 on Feb 1st, the release including branching a week or two later)? It looks like that would work for your constraints. > I don't recall seeing any other timeline requirements, does this seem > like a reasonable target schedule? Once a decision is made to use 4.3 by > mid-jan, it becomes very difficult to back out if something happens to > the release date, so it becomes quite important that the final criteria > is well understood by then and appears reachable. If something > unforeseen happens late in the cycle to delay the release, its also > important that we can get some sort of steering committee agreement on > what to do so we don't have some sort of evil gcc offspring as happened > once before. Once again - GCC development and release planning doesn't work this way. But instead you (and me and others) are supposed to make the release "happen" by fixing bugs and fulfilling the release criteria. A "date" wasn't a release criteria in the past and I don't think it should become one (in fact, the only time a release "date" would be a welcome criteria is if the release is a throw-away and releasing would allow us to work on next stage1 again). > Thats something I don't expect to happen, but will have to > visit as risk management before the final decision is made. My hope is > that it'll be in good enough shape by mid january that slippage by that > much is unlikely and isn't an issue. > > Does this seem like a reasonable schedule? Can we set the criteria for > what a final release would look like? We're committed to applying > engineering resource to help make it happen. Again, if you commit enough engineering resource to make it happen, then I'm sure we'll make your timeline. If not, well - shit happens?. At least I wouldn't like to see us to be locked in into some agreement around release dates. After all this doesn't work for glibc (ok, _that_ probably works for RedHat) or the kernel either. Just my $1000M dollars. Again - please don't branch without releasing. (repeat 1000 times). Thanks, Richard.
Re: GCC 4.3 release schedule
Richard Guenther wrote: On 10/26/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote: Now that GCC is in stage 4.3, I think we'd all be in agreement that it would be nice to keep this stage short and get a release out. We are interested in using 4.3 as the system compiler in Fedora 9, and as such, we'd like to nail down some time lines and requirements with release management and the steering committee. Of course it doesn't work like this ;) we can at least make projected dates known so we have something firmer than "at some point in the future" :-) The timelines involved are something like this: (clearly anything earlier would be great :-) Nov 14th - we'd like to start building F9 with a 4.3 compiler. Ideally we'd have a branch cut no later than that and starting to stabilize without much new code going in. I oppose to cut a branch without immediately releasing 4.3.0. This just doesn't work - just look at the history. I also think that Nov 14th is _very_ optimistic (I personally was thinking about a (early) Q1 release). I got the impression from marks latest note that he was planing to cut a 4.3 branch when we got down to 100 P1s. We're still in Stage 3 for GCC 4.3. As before, I think a reasonable target for creating the release branch is less than 100 open regressions. This was where I was going with the nov 14th date as a latest target. So you are saying we shouldn't branch at this point? I'd like to see some stabilization... Ie, not hunks of new functionality. Early Q1 for 4.3.0 works for us for a release. I had no idea any one else cared when 4.3 goes out. Note that we are building what-becomes-openSUSE 11.0 with current trunk in parallel to 4.2 at the moment, switching to 4.3 is in the next weeks (unless I get pushed back again ;)). It would be excellent to have both openSUSE and fedora pounding on 4.3 at the same time. Dec 14th - viability decision on using 4.3 as the F9 compiler. There is a window here as late as Jan 14th, but the opinions will start forming in Dec. There shouldn't be any ABI changes from this point on. Feb 29th - Optimistic target date for a 4.3 release. can slip as much as a month, but clearly the earlier the release happens the better. If we branch too early I bet we will not make even the Feb 29th date. How does targeting a release around Feb 1st sound (that is, without branching before, a RC1 on Feb 1st, the release including branching a week or two later)? It looks like that would work for your constraints. having a RC by the beginning of february seems reasonable to me :-) mid january would be even better. I don't recall seeing any other timeline requirements, does this seem like a reasonable target schedule? Once a decision is made to use 4.3 by mid-jan, it becomes very difficult to back out if something happens to the release date, so it becomes quite important that the final criteria is well understood by then and appears reachable. If something unforeseen happens late in the cycle to delay the release, its also important that we can get some sort of steering committee agreement on what to do so we don't have some sort of evil gcc offspring as happened once before. Once again - GCC development and release planning doesn't work this way. But instead you (and me and others) are supposed to make the release "happen" by fixing bugs and fulfilling the release criteria. A "date" wasn't a release criteria in the past and I don't think it should become one (in fact, the only time a release "date" would be a welcome criteria is if the release is a throw-away and releasing would allow us to work on next stage1 again). I understand, but without some sort of date guideline, you cant plan on using as yet unreleased compiler. It buggers up the release cycle. I don't propose the date as a hard release criteria, but as a target that we'd like to work towards. So what I'd like to see is what the final release requirements are, and then along they way we can monitor the current status and if we are falling behind, can try to apply more resource to it to get back on track. Thats something I don't expect to happen, but will have to visit as risk management before the final decision is made. My hope is that it'll be in good enough shape by mid january that slippage by that much is unlikely and isn't an issue. Does this seem like a reasonable schedule? Can we set the criteria for what a final release would look like? We're committed to applying engineering resource to help make it happen. Again, if you commit enough engineering resource to make it happen, then I'm sure we'll make your timeline. If not, well - shit happens?. At least I wouldn't like to see us to be locked in into some agreement around release dates. After all this doesn't work for glibc (ok, _that_ probably works for RedHat) or the kernel either. Right. so I'm not looking to lock into Feb 29th as a rock hard rele
Re: GCC 4.3 release schedule
On 10/26/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote: > Richard Guenther wrote: > > On 10/26/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote: > >> > >> Nov 14th - we'd like to start building F9 with a 4.3 compiler. Ideally > >> we'd have a branch cut no later than that and starting to stabilize > >> without much new code going in. > >> > > > > I oppose to cut a branch without immediately releasing 4.3.0. This just > > doesn't work - just look at the history. I also think that Nov 14th is > > _very_ > > optimistic (I personally was thinking about a (early) Q1 release). > > > > > > I got the impression from marks latest note that he was planing to cut a > 4.3 branch when we got down to 100 P1s. > > >We're still in Stage 3 for GCC 4.3. As before, I think a reasonable > >target for creating the release branch is less than 100 open > >regressions. > > > This was where I was going with the nov 14th date as a latest target. > So you are saying we shouldn't branch at this point? Yes. While I saw Marks status report I also saw us running away from completing the 4.2.0 release into stage1 after the branch was cut. If we think 4.3.0 is ready at the point we reach 100 open regressions then we should release it. There is no point in branching but not releasing. If we don't think 4.3.0 is ready at that point, then the 100 open regressions is the wrong metric. (I'd rather use zero P1 bugs as metric) Given that both Novell and RedHat want to use 4.3 for their next community release I think working towards the release and branching and releasing at the same point will work out. > I'd like to see some stabilization... Ie, not hunks of new functionality. I agree. There seem to be still some "late features" going in while I'd rather would like people to spend their time on fixing bugs ... (but it doesn't work that way ;)). But technically stage3 is bugfixes and documentation only - we just need to enforce this more strictly. > Early Q1 for 4.3.0 works for us for a release. I had no idea any one > else cared when 4.3 goes out. Well, I'm pretty sure that we make the Q1 deadline, so I didn't bother too much to try to put it in stone ;) > > Note that we are building what-becomes-openSUSE 11.0 with current trunk > > in parallel to 4.2 at the moment, switching to 4.3 is in the next weeks > > (unless I get pushed back again ;)). > > > > > It would be excellent to have both openSUSE and fedora pounding on 4.3 > at the same time. Yes. I think Ubuntu is on track for 4.3 as well, most likely Debian, too. > >> Dec 14th - viability decision on using 4.3 as the F9 compiler. There is > >> a window here as late as Jan 14th, but the opinions will start forming > >> in Dec. There shouldn't be any ABI changes from this point on. > >> Feb 29th - Optimistic target date for a 4.3 release. can slip as much > >> as a month, but clearly the earlier the release happens the better. > >> > > > > If we branch too early I bet we will not make even the Feb 29th date. > > > > How does targeting a release around Feb 1st sound (that is, without > > branching before, a RC1 on Feb 1st, the release including branching > > a week or two later)? It looks like that would work for your constraints. > > > > > having a RC by the beginning of february seems reasonable to me :-) mid > january would be even better. Yeah - though I expect the usual holidays lack-of-interest. > >> I don't recall seeing any other timeline requirements, does this seem > >> like a reasonable target schedule? Once a decision is made to use 4.3 by > >> mid-jan, it becomes very difficult to back out if something happens to > >> the release date, so it becomes quite important that the final criteria > >> is well understood by then and appears reachable. If something > >> unforeseen happens late in the cycle to delay the release, its also > >> important that we can get some sort of steering committee agreement on > >> what to do so we don't have some sort of evil gcc offspring as happened > >> once before. > >> > > > > Once again - GCC development and release planning doesn't work this way. > > But instead you (and me and others) are supposed to make the release > > "happen" > > by fixing bugs and fulfilling the release criteria. A "date" wasn't a > > release criteria > > in the past and I don't think it should become one (in fact, the only > > time a release > > "date" would be a welcome criteria is if the release is a throw-away > > and releasing > > would allow us to work on next stage1 again). > > > > > I understand, but without some sort of date guideline, you cant plan on > using as yet unreleased compiler. It buggers up the release cycle. I > don't propose the date as a hard release criteria, but as a target that > we'd like to work towards. So what I'd like to see is what the final > release requirements are, and then along they way we can monitor the > current status and if we are falling behind, can try to apply more > resource to it to get back on track. >
Re: GCC 4.3 release schedule
> On 10/26/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote: >> Richard Guenther wrote: >> > On 10/26/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote: >> >> > > ... when we think it's ready. It doesn't help anyone to declare victory > and release 4.3.0 when it still miscompiles the kernel (not that I know > if it does). Warm fuzzyness for PMs put aside. At the risk of annoying you Red Hat Linux guys ( and Linux people in general ) you may be surprised to hear that there are problems for UNIX(tm) users out there. Now I have tried and failed to get a successful bootstrap build of GCC 4.2.2 on Solaris 8 ( Sparc or x86 ) and on Solaris 10. When I look at the Build status page I see no one has posted a result there for GCC 4.2.2 : Please see : http://gcc.gnu.org/gcc-4.2/buildstat.html I was able to get a decent build with GCC 4.2.1 however : And see : http://gcc.gnu.org/ml/gcc-testresults/2007-08/msg00318.html Exact same machine with exact same environment can not build GCC 4.2.2. Now then, you seem to be discussing GCC 4.3 when GCC 4.2.x still does not build correctly on a highly standards compliant UNIX platform. Am I reading this correctly ? If not .. then please educate me if you can. I would like to at least see GCC 4.2.2 bootstrap out of the box before flailing forwards to GCC 4.3.x. - Dennis Clarke
Re: GCC 4.3 release schedule
Andrew MacLeod wrote: > we can at least make projected dates known so we have something firmer > than "at some point in the future" :-) The canonical rule of project management is: "Features, Schedule, Cost: Pick At Most 2." :-) In other words, you can decide what features you want and when you want them by -- but be prepared to pay for a vast team. Or, you can decide what you want to pay, and when you want it -- but be prepared to get whatever features are done by then with the team you paid for. In the case of GCC, it's worse than that since we're not all interested in the same things, or being in any way centrally directed. As RM, I try to take into account what I know about when distributors will be applying effort, but I must absolutely avoid in any way tilting the FSF release process towards the needs of one distributor, possibly at the expense of another. I don't think it's appropriate for us to set a schedule tailored to any one distributor's needs -- and there are a lot more distributors than just Red Hat and SuSE, so I'd say that even if you were on the same schedule. But, I certainly do think it's helpful for a contributor to tell us when resources might be available and I appreciate you sharing that information. If you're interested in driving the release to a particular date, the best thing you can do is to go clear out the P1s in bugzilla and then bash out a few P2s. (I've noticed Red Hat folks doing some of that already, thanks!) I'd imagine that the dates you want to hit would be achievable if you, Jakub, Jason, etc. all work on issues. I've found schedules for GCC to be very hard to predict. As I said in my status report, our practice has been to cut the release branch when we reach 100 regressions, and release 2-4 months after that point, depending on quality on the branch. To be honest, I'd rather wait longer to make the branch -- but there tends to be intense pressure in the developer community to make a branch so we can get on to the next round of major features. In any case, after we make the branch, it's in regression-only mode, so stability tends to be quite good, though dot-zero releases are, after all, dot-zero releases. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.3 release schedule
On 10/26/07, Dennis Clarke <[EMAIL PROTECTED]> wrote: > > > On 10/26/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote: > >> Richard Guenther wrote: > >> > On 10/26/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote: > >> >> > > > > > ... when we think it's ready. It doesn't help anyone to declare victory > > and release 4.3.0 when it still miscompiles the kernel (not that I know > > if it does). Warm fuzzyness for PMs put aside. > > At the risk of annoying you Red Hat Linux guys ( and Linux people in general > ) you may be surprised to hear that there are problems for UNIX(tm) users > out there. Now I have tried and failed to get a successful bootstrap build > of GCC 4.2.2 on Solaris 8 ( Sparc or x86 ) and on Solaris 10. When I look at > the Build status page I see no one has posted a result there for GCC 4.2.2 : > > Please see : http://gcc.gnu.org/gcc-4.2/buildstat.html > > I was able to get a decent build with GCC 4.2.1 however : > > And see : http://gcc.gnu.org/ml/gcc-testresults/2007-08/msg00318.html > > Exact same machine with exact same environment can not build GCC 4.2.2. > > Now then, you seem to be discussing GCC 4.3 when GCC 4.2.x still does not > build correctly on a highly standards compliant UNIX platform. Am I reading > this correctly ? Yes. This is because the interest in 4.2.x is much lower than in 4.3.0 right now. > If not .. then please educate me if you can. I would like > to at least see GCC 4.2.2 bootstrap out of the box before flailing forwards > to GCC 4.3.x. Patches welcome. Certainly there are targets that are less maintained (and tested) than the *-linux targets. But without infinite resources we cannot do anything about this. Thus, in the case of Solaris - talk to Sun. Richard.
Re: GCC 4.3 release schedule
> Mark Mitchell wrote: >> As I said in >> my status report, our practice has been to cut the release branch when >> we reach 100 regressions, and release 2-4 months after that point, >> depending on quality on the branch. To be honest, I'd rather wait >> longer to make the branch -- but there tends to be intense pressure in >> the developer community to make a branch so we can get on to the next >> round of major features. > Is "correctness" a feature ? I would like to see a nice clean GCC 4.2.x before GCC 4.3.zero even gets thought of. Why would one simply branch towards the next release when the previous one still needs some work? To appease sales people and developers making noises for features? > I don't want to start a flame-fest, but perhaps we could reconsider the > release-branching criteria. I will read intently. Dennis Clarke
Re: GCC 4.3 release schedule
Mark Mitchell wrote: As I said in my status report, our practice has been to cut the release branch when we reach 100 regressions, and release 2-4 months after that point, depending on quality on the branch. To be honest, I'd rather wait longer to make the branch -- but there tends to be intense pressure in the developer community to make a branch so we can get on to the next round of major features. I don't want to start a flame-fest, but perhaps we could reconsider the release-branching criteria. As Richard indicated, some (including me) might prefer delaying the branch until we are much closer to the release. It doesn't seem ideal to re-live the 4.2 schedule ad infinitum. As for what the actual date for release should be, I have no preference. David Daney
Re: GCC 4.3 release schedule
On 10/26/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: > > I've found schedules for GCC to be very hard to predict. As I said in > my status report, our practice has been to cut the release branch when > we reach 100 regressions, and release 2-4 months after that point, > depending on quality on the branch. To be honest, I'd rather wait > longer to make the branch -- but there tends to be intense pressure in > the developer community to make a branch so we can get on to the next > round of major features. In any case, after we make the branch, it's in > regression-only mode, so stability tends to be quite good, though > dot-zero releases are, after all, dot-zero releases. To jump in on the last fact - dot-zero releases are dot-zero releases - it makes sense to expose the branch to wider testing by, at branching time, exposing a dot-zero release to the public ;) And I seriously dispute that branching and waiting has ever made the branch of better quality just because we branched and waited. Instead the opposite is true - developer ressources are dragged away to work on their stage1 projects (that is true for myself). I'd rather take the make the dot-zero release approach while branching and count on interested people fixing bugs on the branch after the dot-zero release. This way if nobody is interested on a particular release series then we can declare the dot-zero release final - otherwise we'd do more releases from the branch anyway. Which still leaves us with the problem of setting criteria for releasing a dot-zero. Being it 100 regressions or zero P1 bugs or whatever. Early testing certainly helps here (sofar we are doing build-testing only, but I expect to put the built binaries in "production" soon), but there are still serious problems with 4.3 at the moment, like sorting out the libstdc++ API mess. Thanks, Richard.
Re: GCC 4.3 release schedule
> On 10/26/07, Dennis Clarke <[EMAIL PROTECTED]> wrote: >>On 10/26/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote: >> >> Richard Guenther wrote: >> >> > On 10/26/07, Andrew MacLeod <[EMAIL PROTECTED]> wrote: >> >> >> >> >> > >> > ... when we think it's ready. It doesn't help anyone to declare victory >> > and release 4.3.0 when it still miscompiles the kernel (not that I know >> > if it does). Warm fuzzyness for PMs put aside. >> >> At the risk of annoying you Red Hat Linux guys ( and Linux people in >> general >> ) you may be surprised to hear that there are problems for UNIX(tm) users >> out there. Now I have tried and failed to get a successful bootstrap >> build >> of GCC 4.2.2 on Solaris 8 ( Sparc or x86 ) and on Solaris 10. When I look >> at >> the Build status page I see no one has posted a result there for GCC 4.2.2 >> : >> >> Please see : http://gcc.gnu.org/gcc-4.2/buildstat.html >> >> I was able to get a decent build with GCC 4.2.1 however : >> >> And see : http://gcc.gnu.org/ml/gcc-testresults/2007-08/msg00318.html >> >> Exact same machine with exact same environment can not build GCC 4.2.2. >> >> Now then, you seem to be discussing GCC 4.3 when GCC 4.2.x still does not >> build correctly on a highly standards compliant UNIX platform. Am I >> reading this correctly ? > > Yes. This is because the interest in 4.2.x is much lower than in 4.3.0 > right now. Everyone wants next years car models in the late fall. I understand that only too well. I'm a tad more interested in quality results however as opposed to a shiney new sports car where the brakes don't work. I hate car analogies .. but they often work. Sorry. >> If not .. then please educate me if you can. I would like >> to at least see GCC 4.2.2 bootstrap out of the box before flailing >> forwards >> to GCC 4.3.x. > > Patches welcome. Certainly there are targets that are less maintained > (and tested) than the *-linux targets. But without infinite resources > we cannot do anything about this. I can relate. I really can. > Thus, in the case of Solaris - talk to Sun. I think that the rage inside Sun is Studio 12 and Studio 11 compilers which are, within reason, vastly superior to GCC. Then again we do not have the source code ( yet ) but we do have the sources to OpenSolaris. One would think that after some two years of the OpenSolaris project we would be able to build the OS with GCC and some people have tried : http://www.opensolaris.org/os/project/gccfss-on/ I have not tried that myself. If one uses the free Studio 12 compiler tools from Sun then you can build the whole OS ( big chunks at least ) quite neatly. I have done that so many times it is just silly : http://www.blastwave.org/articles/BLS-0050/index.html The Indiana project being headed up by Ian Murdock ( the ian in Debian ) will make big changes in the Solaris landscape and really we need to stop thinking about Sun corporate and start looking to the extended OpenSolaris community. Guys like me ( and Blastwave people in general ) are not on the Sun payroll. Conversely Red Hat has paid people in the GCC maillists. I have my own reasons to pour efforts into GCC and one of them is simply that *everything* in the OS should be open sourced and *everything* that a person uses to build it should be open sourced. I think that is the key concept behind the FSF and the Linux community in general. It is also why I pour my heart and guts into Blastwave.org to ensure that people have access to open source software in a classically/traditionally closed off proprietary operating system. I think that project Indiana will blow the doors off those old concepts. In any case .. I have my reasons to want a nice clean GCC 4.2.2 for Solaris/OpenSolaris users and my open sourcey intentions are all within reason. Patches are always welcome indeed. Dennis Clarke
Re: GCC 4.3 release schedule
>> When I look at the Build status page I see no one has posted a result >> there for GCC 4.2.2 : >> >> Please see : http://gcc.gnu.org/gcc-4.2/buildstat.html > > Here are a couple of posts by Kaveh: > http://gcc.gnu.org/ml/gcc-testresults/2007-10/msg00388.html > http://gcc.gnu.org/ml/gcc-testresults/2007-10/msg00390.html > > They are more noisy than usual because of -fpic/-fPIC testing. > Oooh .. thank you very much! I can handle the noise no problem and I am happy to see these results. Why isn't the main page for build reports updated ? It *looks* like no one ( me too ) is getting clean builds. Dennis
Re: GCC 4.3 release schedule
> Why isn't the main page for build reports updated ? Will do. > It *looks* like no one ( me too ) is getting clean builds. The GCC 4.2.x compiler is in pretty good shape on SPARC/Solaris, modulo the libgomp problems on Solaris 10 with the Sun tools. You need to use the GNU tools if you care about OpenMP on Solaris 10. -- Eric Botcazou
Re: GCC 4.3 release schedule
>> Why isn't the main page for build reports updated ? > > Will do. > >> It *looks* like no one ( me too ) is getting clean builds. > > The GCC 4.2.x compiler is in pretty good shape on SPARC/Solaris, modulo the > libgomp problems on Solaris 10 with the Sun tools. You need to use the GNU > tools if you care about OpenMP on Solaris 10. I think the problem is that I am using Sun ONE Studio 8 on Solaris 8 to build. My assumption here is that once GCC runs well on Solaris 8 Sparc v7 then it will run on any furture release of either Solaris or Sparc CPU hardware. At least that is what the ABI says and it works. The issue that I ran into was related to the stage 2 GCC compiler binary getting CFLAGS options that were intended for the Studio 8 cc compiler. For some obscure reason ( to me ) I am able to get a bootstrap of GCC 4.21. on the same machine with that same environment vars in place but not with GCC 4.2.2. I'll start digging .. again. Dennis
Re: GCC 4.3 release schedule
* Richard Guenther <[EMAIL PROTECTED]> [2007-10-26 17:51]: > Yes. I think Ubuntu is on track for 4.3 as well, most likely Debian, too. I've been testing 4.3 on a number of architectures Debian supports and filings bugs. There are still many that haven't been resolved yet. Of course, gcc 4.3 also introduces build failures in about 550 packages (mostly due to the C++ header inclusion clean-up) and these need to be fixed too. However, Debian's next release is further away than SUSE's and Fedora's so there should be enough time to fix these issues. -- Martin Michlmayr http://www.cyrius.com/
Re: GCC 4.3 release schedule
> When I look at the Build status page I see no one has posted a result > there for GCC 4.2.2 : > > Please see : http://gcc.gnu.org/gcc-4.2/buildstat.html Here are a couple of posts by Kaveh: http://gcc.gnu.org/ml/gcc-testresults/2007-10/msg00388.html http://gcc.gnu.org/ml/gcc-testresults/2007-10/msg00390.html They are more noisy than usual because of -fpic/-fPIC testing. -- Eric Botcazou
Re: GCC 4.3 release schedule
On Fri, Oct 26, 2007 at 08:20:02PM +0200, Martin Michlmayr wrote: > * Richard Guenther <[EMAIL PROTECTED]> [2007-10-26 17:51]: > > Yes. I think Ubuntu is on track for 4.3 as well, most likely Debian, too. > > I've been testing 4.3 on a number of architectures Debian supports and > filings bugs. There are still many that haven't been resolved yet. > Of course, gcc 4.3 also introduces build failures in about 550 > packages (mostly due to the C++ header inclusion clean-up) and these > need to be fixed too. However, Debian's next release is further away > than SUSE's and Fedora's so there should be enough time to fix these > issues. You might want to hold off on investing the work in fixing those 550 packages, because I think it's premature to consider the header "cleanup" final. Can you estimate how many of the broken packages use or ?
Re: GCC 4.3 release schedule
* Joe Buck <[EMAIL PROTECTED]> [2007-10-26 11:44]: > You might want to hold off on investing the work in fixing those 550 > packages, because I think it's premature to consider the header > "cleanup" final. > > Can you estimate how many of the broken packages use > or ? Sorry I wasn't being clear. This is without the recent removal of some backward-compability headers. The errors I'm talking about are due to the fix for PR28080 and similar and those changes will be in 4.3. -- Martin Michlmayr http://www.cyrius.com/
Re: GCC 4.3 release schedule
On Fri, 2007-10-26 at 19:54 +0200, Eric Botcazou wrote: > > When I look at the Build status page I see no one has posted a result > > there for GCC 4.2.2 : > > > > Please see : http://gcc.gnu.org/gcc-4.2/buildstat.html > > Here are a couple of posts by Kaveh: > http://gcc.gnu.org/ml/gcc-testresults/2007-10/msg00388.html > http://gcc.gnu.org/ml/gcc-testresults/2007-10/msg00390.html > > They are more noisy than usual because of -fpic/-fPIC testing. I added more entries to gcc-4.2/buildstat.html. Bootstrap and test results for 4.2.2: i686-pc-linux-gnu (Slackware 12.0, kernel 2.6.22, glibc 2.5) Test results for 4.2.2: hppa2.0w-hp-hpux11.11 hppa64-hp-hpux11.11 hppa-unknown-linux-gnu i386-unknown-freebsd5.5 i686-pc-linux-gnu (2) ia64-unknown-linux-gnu s390-ibm-linux-gnu s390x-ibm-linux-gnu sparc-sun-solaris2.8 sparc64-unknown-linux-gnu x86_64-unknown-linux-gnu (2) Sorry for the delay. Janis
Re: GCC 4.3 release schedule
> I added more entries to gcc-4.2/buildstat.html. > > Bootstrap and test results for 4.2.2: > > i686-pc-linux-gnu (Slackware 12.0, kernel 2.6.22, glibc 2.5) > > Test results for 4.2.2: > > hppa2.0w-hp-hpux11.11 > hppa64-hp-hpux11.11 > hppa-unknown-linux-gnu > i386-unknown-freebsd5.5 > i686-pc-linux-gnu (2) > ia64-unknown-linux-gnu > s390-ibm-linux-gnu > s390x-ibm-linux-gnu > sparc-sun-solaris2.8 > sparc64-unknown-linux-gnu > x86_64-unknown-linux-gnu (2) Thanks! -- Eric Botcazou
Re: GCC 4.3 release schedule
Mark Mitchell wrote: Andrew MacLeod wrote: we can at least make projected dates known so we have something firmer than "at some point in the future" :-) As RM, I try to take into account what I know about when distributors will be applying effort, but I must absolutely avoid in any way tilting the FSF release process towards the needs of one distributor, possibly at the expense of another. I don't think it's appropriate for us to set a schedule tailored to any one distributor's needs -- and there are a lot more distributors than just Red Hat and SuSE, so I'd say that even if you were on the same schedule. But, I certainly do think it's helpful for a contributor to tell us when resources might be available and I appreciate you sharing that information. I'm not suggesting we tailor the schedule to a specific distributor, but I do think when we have useful information that a client of GCC will be choosing a release by $date, it might be worth considering how that fits into the current or future release schedules. Fortunately we seem to have an alignment of the planets at the moment, so it doesn't appear it will be much of an issue for this release. we got lucky. 12 months ago, it might have actually been planned instead of luck had fedora and suse said our plans are to be looking for a compiler in early Q3/2007 and then again in Q1/2008. And if other distributions provided approximate dates, we'd see where "ooo, look, 5 distributions will be looking for a compiler in Q1/2008. perhaps we should try to arrange our schedule to have a release available then. That means stage 1 goes to june, stage 2 goes to mid september, and that should result in a release in late Q4/early Q1 which all those distributions will be interested in". I think we'd see a lot of resource pumped into getting that release out. If the schedule had shown not more than 1 distribution was looking for a release until June of next year, perhaps we decide to delay things further to allow more development. One of the reasons we sometimes languish in stage 3 is because a release is not interesting to enough parties. They end up spending their resource working on a future release which will be of interest to them, and stage 3 drags on. I think our best bet at making stage 3 practical and short is to have enough interest in getting the release out. And the reality of the situation is that you probably need a couple of distributions interested in it. It looks like thats the case with this release, and I am hopeful that we are going to have a reasonable stage 3 and get a release out in a timely fashion. In the future, we can probably accomplish the same thing if we try to align a release date with interested parties. If you're interested in driving the release to a particular date, the best thing you can do is to go clear out the P1s in bugzilla and then bash out a few P2s. (I've noticed Red Hat folks doing some of that already, thanks!) I'd imagine that the dates you want to hit would be achievable if you, Jakub, Jason, etc. all work on issues. We do intend to do that, but its easier to get the resource assignments if we can say "gcc 4.3 is currently planned to be released on Feb 8th, but we need 25% of 3 developers for 3 months to help make sure". It boils down to the same thing to you and me, but not to the other projects and people involved. If we can set a trend like this, and we meet a couple of release dates accurately, we might be able to regularly get resource assigned to releases. I've found schedules for GCC to be very hard to predict. As I said in my status report, our practice has been to cut the release branch when we reach 100 regressions, and release 2-4 months after that point, depending on quality on the branch. To be honest, I'd rather wait longer to make the branch -- but there tends to be intense pressure in the developer community to make a branch so we can get on to the next round of major features. In any case, after we make the branch, it's in regression-only mode, so stability tends to be quite good, though dot-zero releases are, after all, dot-zero releases. Yeah, I'm not so concerned about whether we cut a release branch early or not. Cutting a branch, or saying mainline is regression only, or whatever mechanism boils down to the same thing. The key is to get people working on it because the release is needed. If the release is needed, its likely to be needed by a certain date. In the past our dates have been set fairly arbitrarily by ourselves right? If our date coincides with dates that others actually need the compiler by, I bet we see a lot less slippage. I just suggest we try it, it really not that big a change in my view, and I think it may solve come of our problem in getting focus on releases. I have no doubt that if we set a date in early february, we'll probably make it. And I'd like to see if we can reprodu
Re: GCC 4.3 release schedule
On Fri, Oct 26, 2007 at 10:28:35PM +0200, Martin Michlmayr wrote: > * Joe Buck <[EMAIL PROTECTED]> [2007-10-26 11:44]: > > You might want to hold off on investing the work in fixing those 550 > > packages, because I think it's premature to consider the header > > "cleanup" final. > > > > Can you estimate how many of the broken packages use > > or ? > > Sorry I wasn't being clear. This is without the recent removal of > some backward-compability headers. The errors I'm talking about are > due to the fix for PR28080 and similar and those changes will be in > 4.3. OK. Can you estimate how many packages use or ?
Re: GCC 4.3 release schedule
* Joe Buck <[EMAIL PROTECTED]> [2007-10-26 14:53]: > Can you estimate how many packages use or ? Not easily because I backed out those changes. -- Martin Michlmayr http://www.cyrius.com/
