Change list from 6.8 to HEAD, and 7.0 plans

[Kevin E Martin]

On Mon, Apr 04, 2005 at 09:25:40PM -0400, Adam Jackson wrote:
> Fair enough.  Here's a strawman, targetted at August 19, which is just over 19 
> weeks out:
> 
> June 10:   Code slush.  Any big changes should start stabilizing.

There are already many significant changes in xorg HEAD.  See the
following wiki page that ajax put together for details:

    http://wiki.x.org/wiki/ChangesSince68

What is the general consensus for how stable and well tested HEAD is?
I'd really like to see everyone start stabilizing much sooner than June
10th.  Perhaps this process should begin today?

> June 24:   Feature freeze.  Patches should be bugfix only and preferably
>            through subsystem maintainers where they exist.  Begin writing
>            release notes and doc updates.

I agree that the feature freeze should coincide with the close of the
initial modular development phase.  The exact timing of this development
phase is still TBD.

> July 8:    RC1.  Code freeze for all but approved patches, fairly open
>            approval stance.
> July 22:   RC2.  Patch approval for crashes, correctness, regressions, build
>            fixes only.  Docs should be basically done.
> August 5:  RC3.  Approval for showstoppers only.
> August 19: 6.9 / 7.0.  6.9 enters immediate maintenance mode, HEAD in xc/ is
>            for 6.9.x releases only.  7.0 modules open for new development.
> 
> That's two weeks for each cycle, which I think is reasonable.  It also allows 
> about two weeks of slip before we hit September, and 10-12 weeks of open 
> commits before we start serious release mode.

I think keeping the testing schedule tight is good since it keeps us
focused; however, the amount of time required for testing depends on how
quickly we get adequate coverage for the platforms we support.  I would
like to see us create another test grid similar to what was done for the
6.8.0 release, but this time, I'd like to see significantly better
coverage.  This will be a major release, and it deserves to be very well
tested on all supported platforms.

If we could start getting tinderbox clients set up for major platforms
and distros now, I think we might be in good shape for a late summer
release.  It would also help us get a feel for how stable HEAD is today.

> The modular tree's time frame is somewhat dependent on the exact schedule we 
> aim for, but I would like to see it at about 90% completion by the code slush 
> point for all the major platforms, where "major" is: Linux, Solaris, at least 
> one BSD, OSX, and Win32.  (Other platforms are welcome and encouraged to 
> shoot for completion by that date too, of course.)

Agreed.

> The development plan for modular is basically the bootstrap order: protocol 
> headers, libs, server, apps.  I would expect these to proceed in rough order 
> for each platform, but that different platforms could be at different stages 
> in the process.  Given that, and the above timeline, I would say the 
> following would be worst-case dates for finishing each step:  (note that 
> platform-specific fixes can go in during the release cycle)

I'm still working on my modularization development schedule writeup, and
I hope to finish it this weekend.  The dependency ordering for the
modules is proto -> lib -> app,xserver.  The apps and various X servers
can proceed in parallel after the proto and lib modules are complete.
Also, the font, doc and util modules can be developed independently by
bootstrapping from the monolithic tree as needed.  I go into detail on
these and other issues in my writeup.

> May 13:  headers
> May 27:  libs
> June 10: server
> June 24: apps
> 
> That's just over five weeks to have all the headers filled in, which sounds 
> quick.  Balancing this is that it's a fairly mechanical process, we have 
> quite a few hands to do it, and that we have a lot of this already done in 
> the existing proof-of-concept.  I'm up for the challenge, I'm just waiting 
> for the arch group to give me the green light ;).

I really hope that the proto module will take significantly less than 5
weeks since it only contains headers and the associated protocol specs.

> Unfortunately since the modular trees will host new development going forward, 
> there's really no way to make a development branch early, where I'd like to 
> do it at about the RC1 mark.  I'm willing to pay that price for what it buys 
> us.

Agreed.  I think this is a small price to pay to get two releases out on
an aggressive but still manageable schedule.

Kevin