4.6.1 release process proposal

[Biju Chacko]

Brian J. Tarricone wrote:
> Hi guys,
> 
> I have a bit of an experiment in mind for our first post-4.6 point
> release.  Stephan has been doing a fabulous job as release manager, but,
> as is the case with all of us, he doesn't always have enough time to put
> in to keep releases churning out as timely as we'd hope.  Plus, building
> and testing all the tarballs takes a huge amount of time, and is
> incredibly tedious.  It's not uncommon for it to be a multi-day process,
> which, frankly, kinda sucks.
> 
> So, I'd like to grab a page from how GNOME (and undoubtedly others) do
> it.  The idea is basically:
> 
> Building and submitting the release tarball is the responsibility of the
> module maintainer.

I'm wary of doing a release with components built on multiple 
environments -- it requires a fair amount of care and discipline to get 
right.

I'd suggest a CI (Continuous Integration) System running a Release 
Pipeline. Basically, on every check-in the entire project is rebuilt in 
a number of steps:

1. Compile everything.

1a. Normally we'd run a test suite here but we don't actually have one.

2. Build release artifacts (tarballs, rpms, debs, etc)

3. Automated verification of artifacts (perhaps comparison against a 
Manifest) -- this is just a sanity test against a major failure.

4. Manual download and testing of the artifacts by module maintainers.

5. Release Manager verifies that all modules have been signed-off and 
executes an automated Release to:

	- Download Site
	- RPM Repo
	- APT Repo

Benefits:

- All grunt work is automated and Release managers and maintainers only 
do stuff which needs their attention.

- We would use a canonical environment for all builds. We wouldn't get 
caught by a maintainer using a newer GTK+, say, than what we've targeted 
for a particular release.

- During a development phase we get quick feedback on whether modules 
are broken or not.

- We'd be able to release nightly builds to make it easier for people to 
test trunk.

Basically, this is the same as Brian's idea except with the boring bits 
taken out. ;-)

I've got a fair amount of experience in this area so I could help set 
this up.

Full Disclosure: I work for a company, ThoughtWorks, that makes open 
source and proprietary tools for Continuous Integeration: CruiseControl, 
CruiseControl.net, CruiseControl.rb and Cruise.

-- b