Re: [RFC] Our release cycles are getting longer
On 1/23/07, Diego Novillo <[EMAIL PROTECTED]> wrote: So, I was doing some archeology on past releases and we seem to be getting into longer release cycles. With 4.2 we have already crossed the 1 year barrier. Heh. Maybe part of the problem here is that the release manager isn't very actively persuing a release. The latest GCC 4.2 status report is from October 17, 2006, according to the web site. That is already more than 100 days ago. For 4.3 we have already added quite a bit of infrastructure that is all good in paper but still needs some amount of TLC. And the entire backend dataflow engine is about to be replaced, too. GCC 4.3 is probably going to be the most experimental release since GCC 4.0... There was some discussion on IRC that I would like to move to the mailing list so that we get a wider discussion. There's been thoughts about skipping 4.2 completely, or going to an extended Stage 3, etc. Has there ever been a discussion about releasing "on demand"? Almost all recent Linux and BSD distributions appear to converge on GCC 4.1 as the system compiler, so maybe there just isn't a "market" for GCC 4.2. I don't see any point in an extended Stage 3. People work on what they care about, and we see time and again that developers just work on branches instead of on bug fixes for the trunk when it is in Stage 3. IMHO the real issue with the GCC release plan, is that there is no way for the RM to make people fix bugs. I know the volunteer blah-blah, but at the end of the day many bugs are caused by the people who work on new projects on a branch when the trunk is in Stage 3. Maybe there should just be some rules about accepting projects for the next release cycle. Like, folks with many bugs assigned to them, or in their area of expertise, are not allowed to merge a branch or big patches into the trunk during Stage 1. Not that I *really* believe that would work... But skipping releases is IMHO not really a better idea. Gr. Steven
Re: [RFC] Our release cycles are getting longer
Wiadomość napisana w dniu 2007-01-23, o godz23:54, przez Diego Novillo: So, I was doing some archeology on past releases and we seem to be getting into longer release cycles. With 4.2 we have already crossed the 1 year barrier. For 4.3 we have already added quite a bit of infrastructure that is all good in paper but still needs some amount of TLC. There was some discussion on IRC that I would like to move to the mailing list so that we get a wider discussion. There's been thoughts about skipping 4.2 completely, or going to an extended Stage 3, etc. Thoughts? Just forget ADA and Java in mainstream. Both of them are seriously impeding casual contributions. The build setup through autoconf/automake/autogen/m4/. has problems in this area as well.
Re: [RFC] Our release cycles are getting longer
On Wed, Jan 24, 2007 at 12:55:29AM +0100, Steven Bosscher wrote: > On 1/23/07, Diego Novillo <[EMAIL PROTECTED]> wrote: > > > >So, I was doing some archeology on past releases and we seem to be > >getting into longer release cycles. With 4.2 we have already crossed > >the 1 year barrier. > > Heh. > > Maybe part of the problem here is that the release manager isn't very > actively persuing a release. The latest GCC 4.2 status report is from > October 17, 2006, according to the web site. That is already more > than 100 days ago. Mark's focusing on 4.1.2 at the moment; I believe he plans to shift focus to 4.2 once that's out. I think that this is appropriate.
Re: [RFC] Our release cycles are getting longer
Marcin Dalecki wrote: Wiadomość napisana w dniu 2007-01-23, o godz23:54, przez Diego Novillo: So, I was doing some archeology on past releases and we seem to be getting into longer release cycles. With 4.2 we have already crossed the 1 year barrier. For 4.3 we have already added quite a bit of infrastructure that is all good in paper but still needs some amount of TLC. There was some discussion on IRC that I would like to move to the mailing list so that we get a wider discussion. There's been thoughts about skipping 4.2 completely, or going to an extended Stage 3, etc. Thoughts? Just forget ADA and Java in mainstream. Both of them are seriously impeding casual contributions. I missed the discussion on IRC, but neither of those front-ends are release blockers. I cannot speak for ADA, but I am not aware that the Java front-end has caused any release delays recently. I am sure you will correct me if I have missed something. David Daney
Re: [RFC] Our release cycles are getting longer
Wiadomość napisana w dniu 2007-01-24, o godz01:48, przez David Daney: I missed the discussion on IRC, but neither of those front-ends are release blockers. I cannot speak for ADA, but I am not aware that the Java front-end has caused any release delays recently. I am sure you will correct me if I have missed something. What's blocking is not the formal process per se but instead the technical side of things. And from a technical point of view both seriously add impedance to the overall package.
Re: [RFC] Our release cycles are getting longer
On Tue, 23 Jan 2007 17:54:10 -0500, Diego Novillo <[EMAIL PROTECTED]> said: > So, I was doing some archeology on past releases and we seem to be > getting into longer release cycles. Interesting. I'm a GCC observer, not a participant, but here are some thoughts: As far as I can tell, it looks to me like there's a vicious cycle going on. Picking an arbitrary starting point: 1) Because lots of bugs are introduced during stage 1 (and stage 2), stage 3 takes a long time. 2) Because stage 3 takes a long time, development branches are long-lived. (After all, development branches are the only way to do work during stage 3.) 3) Because development branches are long-lived, the stage 1 merges involve a lot of code. 4) Because the stage 1 merges involve a lot of code, lots of bugs are introduced during stage 1. (After all, code changes come with bugs, and large code changes come with lots of bugs.) 1) Because lots of bugs are introduced during stage 1, stage 3 takes a long time. Now, the good news is that this cycle can be a virtuous cycle rather than a vicious cycle: if you can lower one of these measurements (length of stage 3, size of branches, size of patches, number of bugs), then the other measurements will start going down. "All" you have to do is find a way to mute one of the links somehow, focus on the measurement at the end of that link, and then things will start getting better. It's not obvious to what the best way is to do that, but here are some ideas. Taking the links one by one: 1: Either fix bugs faster, or release with more bugs. 2: Artificially shorten the lifespan of development branches somehow, so that big branches don't appear during stage 3. 3: Throttle the size of patches: don't let people do gigantic merges, no matter the size of the branch. 4: Don't have buggy code in your branches: improve code quality of development branches somehow. I'm not optimistic about breaking either the link 1 or link 2. The first alternative in link 1 is hard (especially without a strong social contract), and the second alternative in link 1 is, to say the least, distasteful. Link 2 is similarly hard to fix without a strong social contract. So I would focus on either link 3 or link 4. For link 3, you'd change the rules to alternate between stage 1 and stage 3 on a fast basis (no stage 2 would be necessary): do a small merge (of a portion of a branch, if necessary), shake out bugs, and repeat. Concretely, you could have two rules in GCC's development process: * Patches more than a certain size aren't allowed. * No patches are allowed if there are more than X release-blocking bugs outstanding. (For some small value of X; 0 is one possibility.) With this, the trunk is almost always in a releasable state; you can release almost whenever you want to, since you'd basically be at the end of stage 3 every week, or every day, or every hour. Moving to these rules would be painful, but once you start making progress, I bet you'd find that, for example, the pressures leading to long-lived branches will diminish. (Not go away, but diminish.) For 4, you should probably spend some time figuring out why bugs are being introduced into the code in the first place. Is test coverage not good enough? If so, why - do people not write enough tests, is it hard to write good enough tests, something else? Is the review process inadequate? If so, why: are rules insufficiently stringent, are reviewers sloppy, are there not enough reviewers, are patches too hard to review? My guess is that most or all of those are factors, but some are more important than others. My favorite tactic to decrease the number of bugs is to set up a unit test framework for your code base (so you can test changes to individual functions without having to run the whole compiler), and to strongly encourage patches to be accompanied by unit tests. And, of course, you could attack both links 3 and 4 at once. David Carlton [EMAIL PROTECTED]
Re: [RFC] Our release cycles are getting longer
Wiadomość napisana w dniu 2007-01-24, o godz02:30, przez David Carlton: For 4, you should probably spend some time figuring out why bugs are being introduced into the code in the first place. Is test coverage not good enough? It's "too good" to be usable. The time required for a full test suite run can be measured by days not hours. The main reason is plain and simple the use of an inadequate build infrastructure and not the pure size of code compiled for coverage. Those things get completely ridiculous for cross build targets. If so, why - do people not write enough tests, is it hard to write good enough tests, something else? Is the review process inadequate? If so, why: are rules insufficiently stringent, are reviewers sloppy, are there not enough reviewers, are patches too hard to review? My guess is that most or all of those are factors, but some are more important than others. No. The problems are entierly technical in nature. It's not a pure human resources management issue. My favorite tactic to decrease the number of bugs is to set up a unit test framework for your code base (so you can test changes to individual functions without having to run the whole compiler), and to strongly encourage patches to be accompanied by unit tests. That's basically a pipe dream with the auto based build system. It's even not trivial to identify dead code... A trivial by nature change like the top level build of libgcc took actually years to come by.
Re: [RFC] Our release cycles are getting longer
> > > Wiadomo¶æ napisana w dniu 2007-01-24, o godz02:30, przez David Carlton: > > > For 4, you should probably spend some time figuring out why bugs are > > being introduced into the code in the first place. Is test coverage > > not good enough? The test coverage is not good for C++ while it is great for C and most middle-end issues. Most of the regressions being reported are not really in any real code but made up examples by a select few GCC developers. > It's "too good" to be usable. The time required for a full test suite > run can be measured by days not hours. Days, only for slow machines. For our PS3 toolchain (which is really two sperate compilers), it takes 6 hours to run the testsuite, this is doing one target with -fPIC. So I don't see how you can say it takes days. > The main reason is plain and > simple the use of an inadequate build infrastructure and not the pure > size of code compiled for coverage. Those things get completely > ridiculous > for cross build targets. No, not really, it took me a day max to get a spu-elf cross compile building and runing with newlib and all. > No. The problems are entierly technical in nature. It's not a pure human > resources management issue. Actually they are poltical reasons rather than technical. Human resource management is actually the biggest issue because most developers have a day job working on GCC and not supporting the FSF mainline. > > My favorite tactic to decrease the number of > > bugs is to set up a unit test framework for your code base (so you can > > test changes to individual functions without having to run the whole > > compiler), and to strongly encourage patches to be accompanied by unit > > tests. > > That's basically a pipe dream with the auto based build system. Actually the issues here are unrelated at all to auto* and unit test framework. > It's even > not trivial to identify dead code... It is almost hard to identify dead code in any program that has much history as GCC. GCC is on its 20th birthday this year. What code out there has lasted that long and does not have hard places to identify dead code? > A trivial by nature change like the > top level build of libgcc took actually years to come by. Unrelated to any of the above issues. Once the patch was written, there was only small changes to the code to have toplevel libgcc work on weirder targets like Darwin or Netware. Nothing special was needed really. The real reason why toplevel libgcc took years to come by is because nobody cared enough about libgcc to do any kind of clean up. The attitude has changed recently (when I say recent I mean the last 3-4 years) to all of these problems and in fact all major issues with GCC's build and internals are changing for the better. -- Pinski PS auto* is not to blame for GCC's problems, GCC is older than auto*.
Re: [RFC] Our release cycles are getting longer
> > On Tue, 23 Jan 2007 17:54:10 -0500, Diego Novillo <[EMAIL PROTECTED]> said: > > > So, I was doing some archeology on past releases and we seem to be > > getting into longer release cycles. > > Interesting. > > I'm a GCC observer, not a participant, but here are some thoughts: > > As far as I can tell, it looks to me like there's a vicious cycle > going on. Picking an arbitrary starting point: > Let me bring up another point: 0) bugs go unnoticed for a couple of releases and then become part of the release criteria. This is 0) what really causes stage 3 to become long rather than what you mention in 1). Most of the bugs introduced during stage 1 that are caught during stage 3 or earlier are fixed quicker than the ones which were caught after the .2 release was done. > Now, the good news is that this cycle can be a virtuous cycle rather > than a vicious cycle: if you can lower one of these measurements > (length of stage 3, size of branches, size of patches, number of > bugs), then the other measurements will start going down. "All" you > have to do is find a way to mute one of the links somehow, focus on > the measurement at the end of that link, and then things will start > getting better. I don't think this will work because more bugs will just be found, the longer stage 3 is. > It's not obvious to what the best way is to do that, but here are some > ideas. Taking the links one by one: > > 1: Either fix bugs faster, or release with more bugs. > > 2: Artificially shorten the lifespan of development branches somehow, > so that big branches don't appear during stage 3. We already did this for 4.2 which is one reason why 4.2 has almost no new features and why a lot of patches were left out. > 3: Throttle the size of patches: don't let people do gigantic > merges, no matter the size of the branch. This is wrong as the gigantic merges are needed in some cases to be able change the infrastuture of GCC. A good example is recently (and soon) are mem-ssa, GIMPLE_MODIFY_STMT, and dataflow. All really could not be done by simple little patches. Tree-ssa was another example. > 4: Don't have buggy code in your branches: improve code quality of > development branches somehow. Some of the bigger branches actually have requirements for merging. Both the tree-ssa and dataflow branch have a couple of requirements, this will not find all bugs/issues. Remember GCC runs on around 30 processors (not counting variants on each one or even OSs). Running on all targets would take a month plus fixes and then making sure you don't break all of them. > For link 3, you'd change the rules to alternate between stage 1 and > stage 3 on a fast basis (no stage 2 would be necessary): do a small > merge (of a portion of a branch, if necessary), shake out bugs, and > repeat. Concretely, you could have two rules in GCC's development > process: Even though I proposed this before, I don't think it will help unless people are testing GCC with lots of code daily or right after a big merge. > * Patches more than a certain size aren't allowed. This won't work, see above. > * No patches are allowed if there are more than X release-blocking > bugs outstanding. (For some small value of X; 0 is one > possibility.) I don't think this will work out because you are punishing all developers while one developer gets his/her act together. In some cases, they could have just had some bad news about their mother. > With this, the trunk is almost always in a releasable state; you can > release almost whenever you want to, since you'd basically be at the > end of stage 3 every week, or every day, or every hour. Moving to > these rules would be painful, but once you start making progress, I > bet you'd find that, for example, the pressures leading to long-lived > branches will diminish. (Not go away, but diminish.) I don't think so because most of the regressions which are being reported are actually after even the .1 release. > For 4, you should probably spend some time figuring out why bugs are > being introduced into the code in the first place. Is test coverage > not good enough? If so, why - do people not write enough tests, is it > hard to write good enough tests, something else? Is the review > process inadequate? If so, why: are rules insufficiently stringent, > are reviewers sloppy, are there not enough reviewers, are patches too > hard to review? Some cases is because test coverage is not good enough in general, C++. Other cases, you just did not think about a corner case. Even in other cases, you exposed a latent bug in another part of the code which did not think about a corner case. > My guess is that most or all of those are factors, but some are more > important than others. My favorite tactic to decrease the number of > bugs is to set up a unit test framework for your code base (so you can > test changes to individual functions without having to run the whole > compiler), and to st
Re: [RFC] Our release cycles are getting longer
Marcin Dalecki wrote: A trivial by nature change like the top level build of libgcc took actually years to come by. I'm not sure how much that's inherently evidence that it was inappropriately difficult to do, though. For example, the quite trivial change of having "make pdf" support for creating decently usable PDF documentation also took quite a number of years to come by, counting from the first messages I found in the list archives that suggested that it would be a good idea. However, I think I spent less than eight hours total on implementing it, testing it, getting it through the necessary red tape for approval, and committing the final patch. There weren't any technical difficulties in the way at all. - Brooks
Re: [RFC] Our release cycles are getting longer
Wiadomość napisana w dniu 2007-01-24, o godz04:32, przez Andrew Pinski:
It's "too good" to be usable. The time required for a full test suite
run can be measured by days not hours.
Days, only for slow machines. For our PS3 toolchain (which is really
two sperate compilers), it takes 6 hours to run the testsuite, this
is doing one target with -fPIC. So I don't see how you can say it
takes days.
Quantitatively:
gcc/testsuite dalecki$ find ./ -name "*.[ch]" | wc
66446644 213514
ejh216:~/gcc-osx/gcc/testsuite dalecki$ find ./ -name "*.[ch]" -exec
cat {} \; | wc
254741 1072431 6891636
That's just about a quarter million lines of code to process and you
think the infrastructure around it isn't crap on the order of 100?
Well... since
one "can drive a horse dead only once" the whole argument could
actually stop here.
No, not really, it took me a day max to get a spu-elf cross compile
building and runing with newlib and all.
Building and running fine, but testing??? And I guess of course that
it wasn't
a true cross, since the SPUs are actually integrated in to the same
OS image as
the main CPU for that particular target.
My favorite tactic to decrease the number of
bugs is to set up a unit test framework for your code base (so
you can
test changes to individual functions without having to run the whole
compiler), and to strongly encourage patches to be accompanied by
unit
tests.
That's basically a pipe dream with the auto based build system.
Actually the issues here are unrelated at all to auto* and unit
test framework.
So what do the words "full bootstrap/testing" mean, which you hear
when providing
any kind of tinny fix? What about the involvement of those utilities
through
zillions of command line defines and embedded shell scripting for
code generation
on the ACUTAL code which makes up the gcc executables? Coverage? Unit
testing? How?!
Heck even just a full reliable symbol index for an editor isn't easy
to come by...
Or are your just going to permute all possible configure options?
The real reason why toplevel libgcc took years to come
by is because nobody cared enough about libgcc to do any kind of
clean up.
Because there are actually not that many people who love to dvelve
inside the
whole .m4 .guess and so on... Actually It's not that seldom that
people are incapable
to reproduce the currently present build setup.
The attitude has
changed recently (when I say recent I mean the last 3-4 years) to
all of these problems and
in fact all major issues with GCC's build and internals are
changing for the better.
And now please compare this with the triviality of relocating source
files in:
1. The FreeBSD bsdmake structure. (Which is pretty portable BTW.)
2. The solaris source tree.
3. A visual studio project.
4. xcode project.
PS auto* is not to blame for GCC's problems, GCC is older than auto*.
It sure isn't the biggest problem by far. However it's the upfront
one, if you
start to seriously look in to GCC. Remember - I'm the guy who
compiles the whole
of GCC with C++, so it should be clear where I think the real issues
are.
Re: [RFC] Our release cycles are getting longer
Andrew Pinski wrote: My guess is that most or all of those are factors, but some are more important than others. My favorite tactic to decrease the number of bugs is to set up a unit test framework for your code base (so you can test changes to individual functions without having to run the whole compiler), and to strongly encourage patches to be accompanied by unit tests. This does not catch corner cases which is where most of the issues. This gets us back to the original problem, where you can think of inputs that should be valid but no, there are other inputs which are valid. Andrew, you are both correct and incorrect. Certainly, deterministic unit testing is not very useful. However, random unit testing is priceless. I have been doing pseudo-random unit tests for years, believe me it makes your code practically bug free. By employing random tests, you free yourself from most of the burden of "there are other inputs which are valid". Also, the tests are not fragile w.r.t. minor changes that shift corner cases. Deterministic unit-tests are almost useless in long lived projects, random-tests are priceless. Writing a random test is much more difficult, but it is also more interesting. You have to figure out how to automatically check the results, and how to have a reasonable probability for all sorts of potential corner cases. I have been doing this for years, and as a result people rarely find bugs in my code (and I have a complex algorithmic code with complex data structures and transformations). I write code with lots of bugs, but almost all of them are caught by my random unit tests. A simple google search for: random unit test gave me the following papers that look promising: http://www.csd.uwo.ca/faculty/andrews/papers/sourceforge-tr.ps http://netlib.bell-labs.com/who/god/public_psfiles/pldi2005.pdf I am willing to help here, as long as no copyright assignment is involved. (Time constraints, and legal issues I don't want to iron out). I would have written a paper on the subject if it were not that difficult to make it scientific (e.g. how to have a reliable measure of quality of testing). -- Michael Veksler http:///tx.technion.ac.il/~mveksler
Re: [RFC] Our release cycles are getting longer
Wiadomość napisana w dniu 2007-01-24, o godz10:12, przez Michael Veksler: Andrew, you are both correct and incorrect. Certainly, deterministic unit testing is not very useful. However, random unit testing is priceless. I have been doing pseudo-random unit tests for years, believe me it makes your code practically bug free. However the problem with applying this kind of methods to GCC would actually be finding the units inside the spaghetti. Even a curious look at for example how -ffast-math works did give me recently a run from the compiler 'driver' down to the c4x back-end. An trivial attempt at doing something about it resulted in a request for a "full bootstrap without regressions" for a platform: 1. which can't be bootstrapped at all 2. can't by nature run the test-suite 3. isn't in good shape overall. Thus the small bolt against a layering violation will remain simply unplugged. The intention was of course to look at how move stuff, which simply doesn't belong to the scope of a compilation unit a bit more in the direction of the #pragma level. There is after all enough of stuff sitting inside bugzilla, that actually pertains to a request for a #pragma STDC_C99 implementation. That was a code path example. I'm not going to start about the data. The polymorphism by preprocessor macro/GTY fun of some(all?) crucial data types makes me think that the whole MFC stuff looks sleek and elegant... ∎ Marcin Dalecki ∎
Re: [RFC] Our release cycles are getting longer
On 1/24/07, David Carlton <[EMAIL PROTECTED]> wrote: On Tue, 23 Jan 2007 17:54:10 -0500, Diego Novillo <[EMAIL PROTECTED]> said: > So, I was doing some archeology on past releases and we seem to be > getting into longer release cycles. Interesting. I'm a GCC observer, not a participant, but here are some thoughts: As far as I can tell, it looks to me like there's a vicious cycle going on. Picking an arbitrary starting point: 1) Because lots of bugs are introduced during stage 1 (and stage 2), stage 3 takes a long time. 2) Because stage 3 takes a long time, development branches are long-lived. (After all, development branches are the only way to do work during stage 3.) 3) Because development branches are long-lived, the stage 1 merges involve a lot of code. 4) Because the stage 1 merges involve a lot of code, lots of bugs are introduced during stage 1. (After all, code changes come with bugs, and large code changes come with lots of bugs.) 1) Because lots of bugs are introduced during stage 1, stage 3 takes a long time. Now, the good news is that this cycle can be a virtuous cycle rather than a vicious cycle: if you can lower one of these measurements (length of stage 3, size of branches, size of patches, number of bugs), then the other measurements will start going down. "All" you have to do is find a way to mute one of the links somehow, focus on the measurement at the end of that link, and then things will start getting better. Indeed this is a good observation. If you look at how the linux-kernel development changed to face and fix this problem and map this to gcc development we would have like 1. a two-week stage1 for merging 2. six weeks for bugfixing 3. a release 1. ... note that we would not have maintained FSF release branches, but if time is right vendors would pick up a release and keep it maintained (semi-officially). This would allow focusing on "interesting" releases and avoid piling up too much development on branches, at the same time we can enforce more strict quality rules on merges, because missing one merge window is not delaying the merge for one year (as now), but only two month. Note that the above model would basically force all development on non-minor stuff to happen on branches, "working" on the mainline is not possible in this scheme. (This of course fits the distributed development model of the linux kernel more) Of course the two-week and six-week numbers are not fixed, but keeping both numbers low encourages good quality work (and keeping the first number low is a requirement anyway). We'd have a lot of releases of course - but that's only a naming problem. Richard.
Re: [RFC] Our release cycles are getting longer
Marcin Dalecki wrote: Wiadomość napisana w dniu 2007-01-24, o godz10:12, przez Michael Veksler: Andrew, you are both correct and incorrect. Certainly, deterministic unit testing is not very useful. However, random unit testing is priceless. I have been doing pseudo-random unit tests for years, believe me it makes your code practically bug free. However the problem with applying this kind of methods to GCC would actually be finding the units inside the spaghetti. Even a curious look at for example how -ffast-math works did give me recently a run from the compiler 'driver' down to the c4x back-end. An trivial attempt at doing something about it resulted in a request for a "full bootstrap without regressions" for a platform: This issue of legacy spaghetti is well known and understood. From my experience, this can't be fixed in one go. However, it is possible to have a road-map in which: 1. New code is written in a way that allows random unit testing. 2. Old code is gradually changed. 3. For the time being, integrate unit tests in GCC code (with #ifdef or some such). For example, there will be a code to synthesize some random GIMPLE or RTL and pass it to an optimization pass. Then some invariants will be checked on the resulting GIMPLE/RTL. This is quite complex, but IMHO doable. From my experience on my small constraint solver (80,000 LOC) by making stuff more suitable for random unit testing you get: 1. Maintainable+reusable code (with all its benefits). 2. Faster code: Due to simplicity of each unit, it is easier to understand and implement algorithmic enhancements. If it will involve CP ( http://en.wikipedia.org/wiki/Constraint_programming ) or CSP solving then there is a slight chance that I will be able to squeeze some of this into my schedule of 2008, not before. (I refer only to proof of concept, at most a prototype not more). -- Michael Veksler http:///tx.technion.ac.il/~mveksler
Re: [RFC] Our release cycles are getting longer
Wiadomość napisana w dniu 2007-01-24, o godz14:05, przez Michael Veksler: From my experience on my small constraint solver (80,000 LOC) by making stuff more suitable for random unit testing you get: 1. Maintainable+reusable code (with all its benefits). 2. Faster code: Due to simplicity of each unit, it is easier to understand and implement algorithmic enhancements. There is no need to argue that this kind of approach would make some. For 3 particular platforms I think the instrumentation of the code could even be done by using for example the DTrace facilities. My concerns are about how well defined and reproducible such a setup would be in view of the way the build setup goes? It's practically impossible to make any guarantees here. From a general point of view it appears that the GCC contains already itself more then one constrain solver... If it will involve CP ( http://en.wikipedia.org/wiki/ Constraint_programming ) or CSP solving then there is a slight chance that I will be able to squeeze some of this into my schedule of 2008, not before. (I refer only to proof of concept, at most a prototype not more). -- Michael Veksler http:///tx.technion.ac.il/~mveksler ∎ Marcin Dalecki ∎
Re: [RFC] Our release cycles are getting longer
On Jan 23, 2007, at 11:03 PM, Marcin Dalecki wrote: That's just about a quarter million lines of code to process and you think the infrastructure around it isn't crap on the order of 100? Standard answer, trivially, it is as good as you want it to be. If you wanted it to be better, you'd contribute fixes to make it better.
Re: [RFC] Our release cycles are getting longer
Wiadomość napisana w dniu 2007-01-24, o godz19:53, przez Mike Stump:
On Jan 23, 2007, at 11:03 PM, Marcin Dalecki wrote:
That's just about a quarter million lines of code to process and
you think the infrastructure around it isn't crap on the order of
100?
Standard answer, trivially, it is as good as you want it to be. If
you wanted it to be better, you'd contribute fixes to make it better.
This argument fails (trivially) on the assumption that there is an
incremental way ("fixes") to improve it in time not exceeding the
expected remaining life span of a developer.
∎ Marcin Dalecki ∎
Re: [RFC] Our release cycles are getting longer
On Jan 24, 2007, at 11:08 AM, Marcin Dalecki wrote:
This argument fails (trivially) on the assumption that there is an
incremental way ("fixes") to improve it in time not exceeding the
expected remaining life span of a developer.
I welcome your existence proof for just one piece that can't be fixed
incrementally.
Re: [RFC] Our release cycles are getting longer
> "Marcin" == Marcin Dalecki <[EMAIL PROTECTED]> writes: Marcin> Just forget ADA and Java in mainstream. Both of them are seriously Marcin> impeding casual contributions. We tried this once for libgcj. We had gcj in the tree (small amount of code, couldn't really bother anybody) but not libgcj. My recollection is that GCC changes broke libgcj quite frequently. So at least form a gcj maintenance point of view, this would be a big loss. Perhaps there's some way to split the difference. There are already classes of patches which do not require a java build. Marcin> The build setup through autoconf/automake/autogen/m4/. has Marcin> problems in this area as well. Auto* frustrates even me from time to time. The reason I don't do anything about it, though, is that it would be a *lot* of work, and, most likely, very boring work at that. And, in the end, it is hard to imagine that the payoff would be very big (well, removing libtool would have a nice payoff. But that looks hard). I assume that reasons like this apply to all the other developers. Tom
Re: [RFC] Our release cycles are getting longer
On Wed, 24 Jan 2007 03:02:19 +0100, Marcin Dalecki <[EMAIL PROTECTED]> said: > Wiadomość napisana w dniu 2007-01-24, o godz02:30, przez David Carlton: >> For 4, you should probably spend some time figuring out why bugs are >> being introduced into the code in the first place. Is test coverage >> not good enough? > It's "too good" to be usable. The time required for a full test > suite run can be measured by days not hours. That's largely because individual tests in the test suite are too long, which in turn is because the tests are testing code at a per-binary granularity: you have to run all of gcc, or all of one of the programs invoked by gcc, to do a single test. (Is that true? Please correct me if I'm wrong.) Well-written unit tests take milliseconds to execute: it's quite possible to run hundreds of unit tests in a second, ten thousand unit tests in a single minute. (I will give examples below.) Of course, you need many unit tests to get the coverage that a single end-to-end test gives you; then again, unit tests let you test code with much more precision than end-to-end tests. I'm not going to argue against having a good end-to-end test suite around, but it would be quite doable, over the course of a couple of years, to move to a model where a commit required about 10 minutes of testing (including all the unit tests and a few smoke end-to-end tests), and you had separate, automated runs of nightly end-to-end tests that caught problems that slipped through the unit tests. (And, of course, whenever the nightly tests detected problems, you'd update the unit tests accordingly.) >> If so, why - do people not write enough tests, is it >> hard to write good enough tests, something else? Is the review >> process inadequate? If so, why: are rules insufficiently stringent, >> are reviewers sloppy, are there not enough reviewers, are patches too >> hard to review? >> >> My guess is that most or all of those are factors, but some are more >> important than others. > No. The problems are entirely technical in nature. It's not a pure > human resources management issue. I don't think it's a pure human resources issue, but I don't think it's a purely technical issue, either, if for no other reason than that people are involved. >> My favorite tactic to decrease the number of >> bugs is to set up a unit test framework for your code base (so you can >> test changes to individual functions without having to run the whole >> compiler), and to strongly encourage patches to be accompanied by unit >> tests. > That's basically a pipe dream with the auto based build system. Why? What's so difficult about building one more (or a few more) unit test binaries along with the binaries you're building now? David Carlton [EMAIL PROTECTED] Here are numbers to back up my unit test timing claim; these are all run on a computer that cost lest than a thousand dollars a year ago. A C++ example, which is probably closest to your situation: panini$ time ./unittesttest . Tests finished with 69 passes and 0 failures. real0m0.013s user0m0.004s sys 0m0.004s A Java example: panini$ time java org.bactrian.dbcdb.AllTests . . . . . Time: 0.597 OK (173 tests) real0m1.109s user0m1.064s sys 0m0.024s And a Ruby example: panini$ time ruby -e "require 'dbcdb/test/all'" Loaded suite -e Started ... Finished in 0.039504 seconds. 63 tests, 110 assertions, 0 failures, 0 errors real0m0.150s user0m0.128s sys 0m0.016s No matter the language, you get between hundreds and thousands of tests a second; that C++ example works out to over 5000 tests a second.
Re: [RFC] Our release cycles are getting longer
On Tue, 23 Jan 2007 23:16:47 -0500 (EST), Andrew Pinski <[EMAIL PROTECTED]> said: > Let me bring up another point: > 0) bugs go unnoticed for a couple of releases and then become part of > the release criteria. Yeah, that's a good point. So maybe there's another feedback loop to consider: long release cycle => large-scale external testing only happens rarely (because lots of it only happens only after the branch has been cut) => lots of bugs are found all at once => long stage 3 => long release cycle I think it would be interesting to think of ways to spread out the discovery of bugs. >> 3: Throttle the size of patches: don't let people do gigantic >> merges, no matter the size of the branch. > This is wrong as the gigantic merges are needed in some cases to be > able change the infrastuture of GCC. A good example is recently > (and soon) are mem-ssa, GIMPLE_MODIFY_STMT, and dataflow. All > really could not be done by simple little patches. Tree-ssa was > another example. All I can say is that I have a pretty good amount of experience making large changes incrementally, and I'm not the only person who does. But I don't know nearly enough about the changes you mention to be able to say anything specific. (I don't read gcc-patches, just gcc.) >> * No patches are allowed if there are more than X release-blocking >> bugs outstanding. (For some small value of X; 0 is one >> possibility.) > I don't think this will work out because you are punishing all > developers while one developer gets his/her act together. Two responses: * For better or for worse, you're all in this together. * If you have fast bug-detection mechanisms (e.g. a build farm that runs all your tests on all your targets every night, or even multiple times a day), you can quickly revert offending patches. But, as you mentioned above, one of the problems is that bugs are being discovered some time after they are being introduced. Personally, the way I would deal with that is to spend some time doing root cause analysis of the bugs, and try to figure out ways in which they could have been detected faster. In other words, don't just fix the bug: go back to the patch that introduced the bug, think about how you could have made it easier for the submitter to have written test coverage that would have detected the bug, think about how you could have made it easier for the reviewer to have detected the bug. >> For 4, you should probably spend some time figuring out why bugs are >> being introduced into the code in the first place. > Some cases is because test coverage is not good enough in general, C++. > Other cases, you just did not think about a corner case. Even in other > cases, you exposed a latent bug in another part of the code which did > not think about a corner case. Personally, I find unit tests very helpful at reminding me to focus on corner cases, enabling me to test corner cases relatively easy, and helping other people not inadvertently break my corner cases. David Carlton [EMAIL PROTECTED]
Re: [RFC] Our release cycles are getting longer
On Wed, 24 Jan 2007 11:12:24 +0200, Michael Veksler <[EMAIL PROTECTED]> said: > Deterministic unit-tests are almost useless in long lived projects, I think you might be using the term "unit test" differently from me? Nothing is more valuable for a long-lived project than having unit tests covering every line of code, every branch, every boundary condition. I don't remember the reason for all of my own coding decisions six months ago, let alone somebody else's coding decisions years ago, but if pervasive unit tests are in place, it doesn't matter nearly as much: they will give a helpful reminder if I've inadvertently broken something. In some cases, adding randomness can improve the quality of the test suite, but deterministic tests are hugely valuable as well. David Carlton [EMAIL PROTECTED]
Re: [RFC] Our release cycles are getting longer
Wiadomość napisana w dniu 2007-01-24, o godz19:53, przez Mike Stump: On Jan 23, 2007, at 11:03 PM, Marcin Dalecki wrote: That's just about a quarter million lines of code to process and you think the infrastructure around it isn't crap on the order of 100? Standard answer, trivially, it is as good as you want it to be. If you wanted it to be better, you'd contribute fixes to make it better. Well... Let's get out of the somehow futile abstract discussion level: One thing that would certainly help as a foundation for possible further improvement in performance in this area would be to have xgcc contain all the front ends directly linked into it. Actually the name libgcc is already taken, but a "compiler as a library" would be usefull in first place. It could be a starting point to help avoiding quite a lot of overhead needed to iterate over command line options for example. ∎ Marcin Dalecki ∎
Re: [RFC] Our release cycles are getting longer
> > On Wed, 24 Jan 2007 03:02:19 +0100, Marcin Dalecki <[EMAIL PROTECTED]> said: > > That's largely because individual tests in the test suite are too > long, which in turn is because the tests are testing code at a > per-binary granularity: you have to run all of gcc, or all of one > of the programs invoked by gcc, to do a single test. (Is that true? > Please correct me if I'm wrong.) No, they are almost all 1 or 2 functions long, nothing more than 20 lines. The larger testcases are really testing the library parts rather than GCC itself. We have more than 40,000 testcases in just the C testsuite. 15,000 in the Fortran testsuite. 14,000 in the C++ testsuite. 1,000 in the objective-C testsuite. You really cannot do unit testing for parsing cases, sorry to say that. So we are testing many different parts of the compiler at once. > I'm not going to argue against having a good end-to-end test suite > around, but it would be quite doable, over the course of a couple of > years, to move to a model where a commit required about 10 minutes of > testing (including all the unit tests and a few smoke end-to-end > tests), and you had separate, automated runs of nightly end-to-end > tests that caught problems that slipped through the unit tests. (And, > of course, whenever the nightly tests detected problems, you'd update > the unit tests accordingly.) I doubt that because unit testing still will not catch parser/semantic issues where at least a thrid of the regressions are being filed. > I don't think it's a pure human resources issue, but I don't think > it's a purely technical issue, either, if for no other reason than > that people are involved. I think it is a polticial issue rather than either a human reasource issue and technical issue. Remember most of us have day jobs not directly working on the FSF GCC. > Here are numbers to back up my unit test timing claim; these are all > run on a computer that cost lest than a thousand dollars a year ago. > > A C++ example, which is probably closest to your situation: That is just for a simple C++ code. Our unit testing will be over something like a million times larger than most unit testing which case unit testing falls down. Right now we do black box testing which is actually a good way to test the whole thing. Unit testing still does not test the interactions between each part, only the units. So you still don't know if one corner case you can't think of right until you run into it. This is what most of the GCC testsuite is full of, corner testcases. -- PInski
Re: [RFC] Our release cycles are getting longer
On Jan 24, 2007, at 1:12 PM, Marcin Dalecki wrote: One thing that would certainly help as a foundation for possible further improvement in performance in this area would be to have xgcc contain all the front ends directly linked into it. That does seem debatable. It could be a starting point to help avoiding quite a lot of overhead needed to iterate over command line options for example. Odd. You think that time is being spent iterating over the command line options? Do you have any data points to back this up? I suspect we're spending less than 0.01% of the compilation time in duplicative argument processing. After a quick check, yup, 0ms out of 1158 ms are spent in option processing. 11 ms in xgcc, 1 ms in all of xgcc, and 10 ms in system calls. So, I think due to measurement error, I can say that no more than 0.17% of the time is spent in duplicative option processing.
Re: [RFC] Our release cycles are getting longer
On Wed, 24 Jan 2007 17:26:32 -0500 (EST), Andrew Pinski <[EMAIL PROTECTED]> said: >> That's largely because individual tests in the test suite are too >> long, which in turn is because the tests are testing code at a >> per-binary granularity: you have to run all of gcc, or all of one >> of the programs invoked by gcc, to do a single test. (Is that true? >> Please correct me if I'm wrong.) > No, they are almost all 1 or 2 functions long, nothing more than 20 > lines. Sorry, I should have been clearer: by "long" I meant long in test execution time, not in textual representation of the test. (Though having the latter be short is important, too!) There's a big different between tests that take, say, .1 to 1 second each and tests that take, say, .001 to .01 second each, especially if you have tens of thousands of test cases. > You really cannot do unit testing for parsing cases, sorry to say > that. I agree that, when testing parsing, it's frequently desirable to run through the entire parser: so this is more complicated than, say, testing a simple class interface. But I bet you can get a big speedup even here. Am I correct in thinking that you run gcc on each input test case, even if all you really want is the parser? Or at least a significant chunk of gcc? In that case, you should be able to speed this up significantly by just calling the parser itself and directly checking the resulting parse tree (or just checking what you care about, e.g. that no errors are emitted). No codegen necessary, no writing any output files, and you can probably do tricks to significantly reduce the time spent reading input files as well. I don't, offhand, see any barrier to testing the parsing of a 20 line chunk of test source code in just a few milliseconds. >> A C++ example, which is probably closest to your situation: > That is just for a simple C++ code. Our unit testing will be over > something like a million times larger than most unit testing which > case unit testing falls down. Sure, that example is testing a library that's only a couple thousand lines long. And the test coverage isn't quite as good as it should be; pretty close, though. Even so, I would be impressed if GCC is really a million times larger than that. :-) I have hands-on experience with unit testing C++ code bases of about a half-million lines of code. (Which started off as legacy code, and I'm sure it was in worse shape than GCC's.) Unit testing works there, and I see any obvious boundary in sight. David Carlton [EMAIL PROTECTED]
Re: [RFC] Our release cycles are getting longer
Wiadomość napisana w dniu 2007-01-24, o godz23:26, przez Andrew Pinski: On Wed, 24 Jan 2007 03:02:19 +0100, Marcin Dalecki <[EMAIL PROTECTED]> said: That's largely because individual tests in the test suite are too long, which in turn is because the tests are testing code at a per-binary granularity: you have to run all of gcc, or all of one of the programs invoked by gcc, to do a single test. (Is that true? Please correct me if I'm wrong.) No, they are almost all 1 or 2 functions long, nothing more than 20 lines. The larger testcases are really testing the library parts rather than GCC itself. Hugh? I guess this wasn't intentional. But please don't make sentences by abbreviation change attribution. It makes me look more GCC "innocent" then actually true ... ∎ Marcin Dalecki ∎
Re: [RFC] Our release cycles are getting longer
Wiadomość napisana w dniu 2007-01-24, o godz23:52, przez Mike Stump: On Jan 24, 2007, at 1:12 PM, Marcin Dalecki wrote: One thing that would certainly help as a foundation for possible further improvement in performance in this area would be to have xgcc contain all the front ends directly linked into it. That does seem debatable. It could be a starting point to help avoiding quite a lot of overhead needed to iterate over command line options for example. Odd. You think that time is being spent iterating over the command line options? No I think plenty of time goes to dejagnu churning and iterative restarts of new gcc process instances as well as other system calls. That's at least what a casual look at a top and the sluggishness of the disk system I'm using suggests. The option churning I did have in mind was like gcc -O0 test.c, gcc -01 test.c, gcc -O2 test.c runs in sequence, which are quite common. Do you have any data points to back this up? I suspect we're spending less than 0.01% of the compilation time in duplicative argument processing. After a quick check, yup, 0ms out of 1158 ms are spent in option processing. 11 ms in xgcc, 1 ms in all of xgcc, and 10 ms in system calls. So, I think due to measurement error, I can say that no more than 0.17% of the time is spent in duplicative option processing. ∎ Marcin Dalecki ∎
Re: [RFC] Our release cycles are getting longer
Marcin Dalecki wrote: Wiadomość napisana w dniu 2007-01-24, o godz23:52, przez Mike Stump: On Jan 24, 2007, at 1:12 PM, Marcin Dalecki wrote: It could be a starting point to help avoiding quite a lot of overhead needed to iterate over command line options for example. Odd. You think that time is being spent iterating over the command line options? No I think plenty of time goes to dejagnu churning and iterative restarts of new gcc process instances as well as other system calls. That's at least what a casual look at a top and the sluggishness of the disk system I'm using suggests. The option churning I did have in mind was like gcc -O0 test.c, gcc -01 test.c, gcc -O2 test.c runs in sequence, which are quite common. This is certainly true on Cygwin, where a "make check-fortran" takes on the order of a dozen hours, rather than three under Linux on the same computer within a VMWare session. That's just circumstantial evidence for what's going on on Linux, but it seems pretty strong circumstantial evidence to me. (Also, when I'm running a GCC test run, even under Linux, my drives get hot. I think that's probably relevant data too.) - Brooks
Re: [RFC] Our release cycles are getting longer
Diego Novillo wrote: > So, I was doing some archeology on past releases and we seem to be > getting into longer release cycles. With 4.2 we have already crossed > the 1 year barrier. I think there are several factors here. First, I haven't had as much time to put in as RM lately as in past, so I haven't been nagging people as much. I also haven't as much time to put in as a developer. For some previous releases, I was the bug-fixer of last resort, fixing many of the critical bugs -- or at least proposing broken patches that goaded others into fixing things. :-) Holidays are over, CodeSourcery's annual meeting is behind us, and I'm almost caught up on the mailing lists. So, I expect do more goading -- but probably not much more coding. Second, I think there are conflicting desires. In reading this thread, some people want/suggest more frequent releases. But, I've also had a number of people tell me that the 4.2 release cycle was too quick in its early stages, and that we didn't allow enough time to get features in -- even though doing so would likely have left us even more bugs to fix. RMS has recently suggested that any wrong code bug (whether a regression or not) that applies to relatively common code is a severe embarrassment in a release. Some people want to put more features onto release branches, while others think we're too lax about changes. If there's one thing I've learned from years of being RM, it's that I can't please everyone. :-) In any case, I've intentionally been letting 4.3 stage 1 drag out, because it looks like there's a lot of important functionality coming in, and I didn't want to leave those bits stranded until 4.4. Some folks have suggested that we ought to try to line up FSF releases to help the Linux distributors. Certainly, in practice, the distributors are naturally most focused at the points that make sense in their own release cycles. However, I think it would be odd for the FSF to try to specifically align with (say) Red Hat and Novell releases (which may not themselves always be well-synchronized) at the possible expense of (say) MontaVista and Wind River. And, there are certainly a large number of non-Linux users -- even on free operating systems. In practice, I think that the creation of release branches has been reasonably useful. It may be true that some of the big server Linux distributors aren't planning on picking up 4.2, but I know of other major users who will be using it. Even without much TLC, the currently 4.2 release branch represents a reasonably stable point, with some key improvements over 4.1 (e.g., OpenMP). Similarly, without much TLC, the current 4.1 branch is pretty solid, and substantially better than 4.1.1. So, the existence of the branch, and the regression-only discipline thereon, has produced a useful point for consumers, even though there's not yet a 4.1.2. I don't think that some of the ideas (like saying that you have to fix N bugs for every patch you contribute) are very practical. What we're seeing is telling us something about "the market" for GCC; there's more pressure for features, optimization, and ports than bug fixes. If there were enough people unhappy about bugs, there would be more people contributing bug fixes. It may be that not too many people pick up 4.2.0. But, if 4.3 isn't looking very stable, there will be a point when people decide that 4.2.0 is looking very attractive. The worst outcome of trying to do a 4.2.0 release is that we'll fix some things that are also bugs in 4.3; most 4.2 bugs are also in 4.3. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: [RFC] Our release cycles are getting longer
[sorry for breaking the thread; stupid gmail doesn't want to add custom References headers] It may be that not too many people pick up 4.2.0. But, if 4.3 isn't looking very stable, there will be a point when people decide that 4.2.0 is looking very attractive. The worst outcome of trying to do a 4.2.0 release is that we'll fix some things that are also bugs in 4.3; most 4.2 bugs are also in 4.3. From the Fortran point of view, and however limited it might be, skipping the 4.2.0 release would be very unfortunate. We've been working hard on it, and especially in recent time, many bug fixes have been deemed to risky to backport to the 4.1 branch. 4.3 is still a long way down the road, and the 4.2 branch has interesting features even from the non-Fortran point of view. About the other points of the discussion, maybe getting more exposure for the mainline branch (4.3.0) could get us more feedback? People are more involved in fixing bugs when they come just after their patch commit than when the report comes one month after. (and I can thing of examples in our bugzilla that confort this view :) Now, how to get greater exposure? We (some of the gfortran maintainers) have been making available regular binaries of the compiler for common archs; most of the bug reports are made from people using these binaries, so I suppose it's a way that works for us. There are a few people that help with gfortran development, not by patching, but by testing/filing detailed bug reports/writing testcases/etc. (They even tend to get involved in gfortran patching at some point :) Can it work for GCC as a whole? Maybe not for all types of bugs and users (the Fortran users mostly have mainstream archs), but we could nonetheless use more feedback and maybe have more people testing their apps with the latest mainline state. Sorry for being so long, but maybe the gfortran experience can help here, FX
Re: [RFC] Our release cycles are getting longer
On Thu, Jan 25, 2007 at 11:18:34AM +0100, François-Xavier Coudert wrote: > [sorry for breaking the thread; stupid gmail doesn't want to add > custom References headers] > > >It may be that not too many people pick up 4.2.0. But, if 4.3 isn't > >looking very stable, there will be a point when people decide that 4.2.0 > >is looking very attractive. The worst outcome of trying to do a 4.2.0 > >release is that we'll fix some things that are also bugs in 4.3; most > >4.2 bugs are also in 4.3. > > >From the Fortran point of view, and however limited it might be, > skipping the 4.2.0 release would be very unfortunate. We've been > working hard on it, and especially in recent time, many bug fixes have > been deemed to risky to backport to the 4.1 branch. 4.3 is still a > long way down the road, and the 4.2 branch has interesting features > even from the non-Fortran point of view. > Gcc 4.2 has a serious FP performace issue: http://gcc.gnu.org/ml/gcc/2007-01/msg00408.html on both ia32 and x86-64. If there will be a 4.2.0 release, I hope it will be addressed. H.J.
Re: [RFC] Our release cycles are getting longer
H. J. Lu wrote: Gcc 4.2 has a serious FP performace issue: http://gcc.gnu.org/ml/gcc/2007-01/msg00408.html on both ia32 and x86-64. If there will be a 4.2.0 release, I hope it will be addressed. As always, the best way to ensure that it is addressed if it is important to you is to address it yourself, or pay someone to do so :-)
Re: [RFC] Our release cycles are getting longer
On Thu, Jan 25, 2007 at 09:57:45AM -0500, Robert Dewar wrote: > H. J. Lu wrote: > > >Gcc 4.2 has a serious FP performace issue: > > > >http://gcc.gnu.org/ml/gcc/2007-01/msg00408.html > > > >on both ia32 and x86-64. If there will be a 4.2.0 release, I hope it > >will be addressed. > > As always, the best way to ensure that it is addressed if it is > important to you is to address it yourself, or pay someone to do so :-) The fix is in mainline. The question is if it should be backported to 4.2. H.J.
Re: [RFC] Our release cycles are getting longer
On 1/25/07, H. J. Lu <[EMAIL PROTECTED]> wrote: > >Gcc 4.2 has a serious FP performace issue: > > > >http://gcc.gnu.org/ml/gcc/2007-01/msg00408.html > > > >on both ia32 and x86-64. If there will be a 4.2.0 release, I hope it > >will be addressed. > > As always, the best way to ensure that it is addressed if it is > important to you is to address it yourself, or pay someone to do so :-) The fix is in mainline. The question is if it should be backported to 4.2. ISTR Dan already made it clear more than once that the answer to that question is a loud NO. Gr. Steven
Re: [RFC] Our release cycles are getting longer
On 1/25/07, Steven Bosscher <[EMAIL PROTECTED]> wrote: On 1/25/07, H. J. Lu <[EMAIL PROTECTED]> wrote: > > >Gcc 4.2 has a serious FP performace issue: > > > > > >http://gcc.gnu.org/ml/gcc/2007-01/msg00408.html > > > > > >on both ia32 and x86-64. If there will be a 4.2.0 release, I hope it > > >will be addressed. > > > > As always, the best way to ensure that it is addressed if it is > > important to you is to address it yourself, or pay someone to do so :-) > > The fix is in mainline. The question is if it should be backported to > 4.2. ISTR Dan already made it clear more than once that the answer to that question is a loud NO. I thought it was more like "if you really want it I can do it". And I think without it 4.2 sucks. Richard.
Re: [RFC] Our release cycles are getting longer
Mark Mitchell wrote on 01/25/07 00:09: First, I haven't had as much time to put in as RM lately as in past, so I haven't been nagging people as much. > Sure, but this is a trend that started with 3.1 and it's gotten progressively worse. Granted, we are now dealing with a much bigger project and perhaps the amount of engineering cycles has not kept up: Release Size (KLOC) 1.21 1988 58 1.38 1990 87 2.0 1992229 2.8.1 1998416 EGCS 1998603 2.95 1999715 3.0 2001 1,007 3.1 2002 1,336 4.0 2005 1,813 4.1 2006 2,109 4.2 2007 2,379 some people want/suggest more frequent releases. But, I've also had a number of people tell me that the 4.2 release cycle was too quick in its early stages, and that we didn't allow enough time to get features in -- even though doing so would likely have left us even more bugs to fix. > That's also true. The duration of our stage1 cycles has gone down quite a bit since 3.3. The data I have for the 3.x releases is a bit incomplete and we had a strange 3.2 release which I didn't include because we suddenly jumped from branching 3.1 to releasing 3.2 (that was the C++ ABI thing, IIRC). Anyway, here's the data I got from our release schedule. These are the durations of each stage since 3.1 Release Stage 1 Stage 2 Stage 3 Release 3.1 2002 0 65 69 212 3.3 2003 169 1 61 271 3.4 2004 262 103 93 289 4.0 2005 172 64 170 288 4.1 2006 59 74 133 309 4.2 2007 61 59 216 393 There is some correlation between the length of Stage1 to Stage3. It's as if longer Stage1s lead to shorter Stage3s. Perhaps we could consider lengthening the early stages, which by all accounts are the more "fun", and shorten the pain during stage 3. Long-lived branches are painful to maintain. If we allow them more time to get in mainline, it may help spread the stabilization work during stage1 (a lot more exposure). Another thing we could try again is going into mini-freeze cycles spanning 2-3 weeks. We've done that in the past when mainline was in a pathetic state and I think it was helpful. Some folks have suggested that we ought to try to line up FSF releases to help the Linux distributors. > I don't think that's in our best interest. We can't really help what distros do. The fact is, however, that when distros pick up a specific release, that release tends to be pretty solid (e.g. 4.1). I don't think that some of the ideas (like saying that you have to fix N bugs for every patch you contribute) are very practical. What we're seeing is telling us something about "the market" for GCC; there's more pressure for features, optimization, and ports than bug fixes. If there were enough people unhappy about bugs, there would be more people contributing bug fixes. Agreed. We are now in a featuritis phase. We still have many marketing bullet points that folks want filled in. I believe this will continue for at least a couple more releases. We are also being pulled from many directions at once, our user base is very diverse. Making the infrastructure more palatable for external folks to get involved in development and attract more engineering cycles is probably one of our best long term bets.
Re: [RFC] Our release cycles are getting longer
On Tue, 23 Jan 2007, Diego Novillo wrote: There was some discussion on IRC that I would like to move to the mailing list so that we get a wider discussion. There's been thoughts about skipping 4.2 completely, or going to an extended Stage 3, etc. Thoughts? I believe that going forward we should not branch for a release unless we have a very clear plan, that is "We need to address these four bugs and potential true blockers/evil regressions that are found before we release", with a time horizon of maybe two weeks. Either the release is nearly in shape, then we can branch, or it is not, in which case we will have a starving release branch for too long and most focus on Stage 1. (At least this is the impression that I got; YMMV.) Gerald
