4.6.1 release process proposal

[Jannis Pohlmann]

Am Thu, 15 Jan 2009 16:39:14 -0800
schrieb "Brian J. Tarricone" <bjt23 at cornell.edu>:

> 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.
> 
> A little more fleshed out:
> 
> 1.  The release manager sets a date and time.

I'd rather have a group meeting for that at the beginning of a release
cycle, so that everyone can throw in what he'd like to implement in
that cycle and we can decide on a date. It would be great to just have
a fixed-length cycle of course. In that case the only reason to discuss
that might be foreseable holidays or something (but even that shouldn't
really matter because it's not always predictable).

> 2.  Module maintainers are required to build and test their own
> package(s) and submit them to the release manager software (more on
> that later) by the specified time.

Maybe have a soft and a hard date for that so that the release
manager/team can perform the final checks on some components earler
than on others. But I don't feel strongly about this.

> 3.  Packages that are not uploaded by that time lose out: they become
> ineligible to be a part of that release.

I think I'm ok with that as long as the 'important' components maintain
some degree of backwards compatibility. E.g. libxfce4menu is missing
in 4.6.5 but was part of 4.6.3 and all components still work with
the version from that version. 

In a lot of cases that won't be possible (take the deprecation of
ThunarVFS as an example). In theses case the maintainers of affected
components should work together to get their components ready in time.

If not, well, then all components will be missing in the release. I
guess that extensive use of branches (with a proper version control
system) will help a lot in theses cases, where features can be
developed in parallel to the main branch and can be merged into it with
a little amount of time and code changes.

> 4.  After the date and time has passed, the release manager gathers
> everything up, does some final checks, updates the website, and all
> that good stuff.
> 
> As for the release manager software, Jannis wrote a web frontend for
> the goodies project so goodies maintainers can easily make and upload
> releases.  Fortunately it's also well-suited to our situation as well,
> with a few tweaks that Jannis will take care of.  This way maintainers
> just need a https account on svn.xfce.org to submit their release
> tarballs.

I think I'll redo the software but that's not too much of a big deal.
The task is rather simple.

> Now of course #3 is the potentially controversial part.  Flame on.

No flaming from me. Just a thumbs up ;)

Cheers,
Jannis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://mail.xfce.org/pipermail/xfce4-dev/attachments/20090116/cfd88622/attachment.pgp>