Re: Beyond GCC 3.0

[Stephane Carrez <Stephane dot Carrez at worldnet dot fr>]

Hi Mark and All,

Mark Mitchell a écrit :
> [...]
> I think the single biggest problem in our current release process
> is that we have a total lack of predictability: of effort required,
> delivery date, and quality.

I agree.  Companies that use gcc and do products with it can't rely on
when a new release is coming out.  So, they step back and/or keep some old
version; some others don't want to hear about gcc for that reason too.
This is the biggest grief I'm hearing in this cruel business world...


> In particular, our method is:
> 
>   - Develop for a long time.
> 
>   - Decide we have done enough, and branch for a release.
> 
>   - Try desparately to fix bugs.
> [...]
Excellent resume'!

But as a developer, I like that :-)

> [...]
> I think that we need a new method, one that gives better
> predictability for all:
> 
>   - Do a new release every six months.
> 
>   - Do bug fix releases two and four months after the major
>     releases, as required.

I'm not convinced that a new release every six months is ever possible.
Six months is too short if you want to achieve some development while making
sure you don't introduce too many regressions (or, do a same quality product).
I've never seen an enterprise doing this.  A new release every year is more
realistic to me.

Now, for bug fix release, it's different and a bug fix release every 6 months
is hard to achieve but probably do-able.

Too many releases is not good for developers because you spend your time
trying to fix problems; and only do that.  The lack of releases is not good
so, we should find a compromise.

> 
> I think we can achieve this by making a few changes to the mainline
> development process, in order to maintain greater stability.  In
> particular:
> 
>   - All development of major new features (e.g., a new register
>     allocator, a new C++ parser, a new Makefile scheme) must be
>     done on a branch, or in a local tree -- not on the mainline.
>     That way, partially complete features do not show up on the mainline.
>     (I spent a not insignificant amount of time removing command-line
>     options on the branch for things that people started to implement,
>     but did not finish,resulting in user and developer confusion.)
> 
>     Before merging to the mainline, the merger should confirm
>     non-regression in the testsuites on three or more platforms,
>     using volunteers if they themselves do not have access to
>     three platforms.  Also, all documentation should be in order.
> 
Yes, that's make big sense

>   - Patches that cause regressions, even on the mainline, must
>     be in the process of being fixed within 48 hours, or else can be
>     reverted by anyone with global write privileges, if they think
>     that's best. The idea is that you musn't check stuff in and then
>     leave problems lying around for a week.  This happenned more
>     than once in our 3.0 development cycle.
> 
>     One of the reasons for this is that other developers cannot
>     make progress if things don't build or work, people can't
>     remember which test-cases are known to pass and which aren't,
>     and so forth.
> 
Yes but 48 hours is sometimes a little short; due to time difference you
might discover the problem the day after and have only 1 day to understand & fix,
send something to discover the 3rd day it's still broken (:-


>   - Our development is broken into two-month windows.  Here
>     is how it works, first for the mainline:
> 
I like this idea but with different numbers.

If you remember what happened with 2.95.3, the `Stabilize' window was more
than 2 months.  I think it's normal due to the number of targets/platforms
that gcc supports.  And 2.95.3 was a nice bug-fix release (Thanks Bernd!).

If we want to provide a good quality product, the `Stabilize' should be larger
than 2 months to let people test&fix on various targets and hosts.

I'm also afraid that a 2 months `Stabilize' will increase or give high pressure
to the release manager (which is not good).

What about:

	Months 1,2,3	Free for all
	Months 4,5,6	Hack On
	Months 7,8,9,10	Stabilize

Yes, it's more than 6 months but you give more time to everybody to do his/her
job in a good way.


>     Months 1,2: "Free for All"
>     --------------------------
> 
>     Merges from development branches to the mainline are allowed,
>     assuming testing is successful.  Anything goes during this
>     period -- this is just like our normal mainline development
>     process right now.
> 
>     Months 3,4: "Hack On"
>     ---------------------
> 
>     No merges are allowed from development branches.
> 
>     However, improvements of a less major nature (say, refinements to
>     the pipeline description for a chip, or enhancements to the loop
>     optimizer to make it recognize more GIVs, or to speed up
>     the preprocessor by making it use a hash table instead of a list)
>     are fine.
> 
>     The idea is that we are beginning to reduce the influx of risky
>     changes.
> 
>     Months 5,6: "Stabilize"
>     -----------------------
> 
>     The only patches allowed during this time are bug-fixes.  These
>     need not be for regressions from the previous release, but they
>     must be bug-fixes.  This makes sure that we are paying attention
>     to quality on a regular basis.  When we start writing bug-free
>     code, this period can be eliminated.
> 
>     On the release branch:
> 
>     Months 1,2: "Release"
>     ---------------------
> 
>     Create the branch.
>     Fix regressions from the previous release.
>     Prepare prereleases.
>     Test.
>     Release.
> 
>     Note that this time will immediately follow a "Stabilize" period
>     on the mainline.  Therefore, it is reasonable to expect that we
>     are going to be in decent shape by the time we branch -- we will
>     have just spent two months fixing bugs.
> 
>     Months 2,3: "Dot release 1"
>     ---------------------------
> 
>     Fix critical bugs.
> 
>     Months 3,4: "Dot release 2 (optional)"
>     --------------------------------------
> 
>     Fix critical bugs, if necessary.

Don't make Dot release 2 optionals.  These bug fix releases are really
important to give a good stability to gcc.  You also give confidence to
users that you take care of their problems, and they will not have to
switch to a new release to find other bugs.  Gcc gets its stability in
these bug-fix releases, let's not remove them and have some plan for them.

> 
> Note that particular goals do not play a part in this strategy.
> The goal will always be monotonic improvement: more features, more
> platforms, fewer bugs, faster code.  I think that setting concrete
> release goals (in terms of new features) is a mistake for us because
> we cannot ensure that they get done.  I was a strong proponent of
> release goals, and I think that I was wrong.  Unlike a typical
> corporate development process, we have no way of actually ensuring
> that we meet goals. We cannot open a req to get additional staffing,
> or pull people off of one project to work another.  We have to go
> with what people decide to do.
> 
> The goal we should strive for is that every release should be
> better than the one before.

Thanks for taking the time to setup a new and predictable process

	Stephane

-----------------------------------------------------------------------
         Home                               Office
E-mail: stcarrez@worldnet.fr               Stephane.Carrez@sun.com
WWW:    http://home.worldnet.fr/stcarrez   http://www.sun.com
Mail:   17, rue Foucher Lepelletier        6, avenue Gustave Eiffel
        92130 Issy Les Moulineaux          78182 Saint Quentin en Yvelines
        France