IcedTea release process

[Gary Benson]

Hi all,

Given the recent friction about the current IcedTea release process
(such as it is) I'd like to start a discussion about what to do for
the future.  We don't have to resolve anything now, but we can at
least we start to figure out what the issues are in time to discuss
it "properly" with beer at FOSDEM.

So, firstly, are formal releases beneficial?  Who uses them?

 - Lillian and Matthias, do you exclusively use the release tarballs,
   or do you sometimes (or most times) use ones you cut yourself.
   Would it be easier for you guys to just cut your own tarballs
   and call them icedtea6-c29bbfa41f2b.tar.gz or whatever?

 - Are there other distro maintainers out there?  What about you?

 - How about end users?  Do we particularly have any, or do most
   people just use built packages?  Can we get web server statistics
   to see if people are downloading the tarballs?

My personal opinion is that formal releases are a good idea (even
if if nobody uses them) because if nothing else they give us a semi-
regular excuse to blog all over the place about how great we are :)
Also, IcedTea is far bigger now than it was this time last year.
It's the default Java implementation on Fedora, and I guess Ubuntu
and Debian too, which maps out to a lot of unhappy people if we break
something.  The fact that a single TCK failure puts you right back
to the beginning means some kind of pre-release freeze is probably
a good idea even if it's only for a couple of days.

If we are to have a formal release process, what would it look like?
I don't have much experience with this, but maybe something like the
following:

 - Someone wants a release, for whatever reason.  They mail the
   list and request one.  There is a short period during which:
     - Anyone with objections may raise them.
     - Anyone with uncommitted changes that they wish to include
       in the release should mail the list so that their inclusion
       may be discussed.
   We should probably have a bit of boilerplate text to stress that
   the release request is not a cue for hurried commits of large or
   destabilizing changes.

 - Once there's a general consensus for a release (or at least
   no serious objections) someone (the original requester?) mails
   the list with a timetable for the release.  This would include:
     - An optional pre-freeze window in which to commit changes
       discussed in the previous step.
     - A time and date for the freeze, after which nothing except
       serious fixes should be committed.
   It probably makes sense for a release branch to be made at the
   freeze.  That way, commits for the release can be limited to
   serious stuff (build failures, TCK failures), and everyone else
   can commit their stuff to tip without having to wait for the
   release.  It also means the people working on the release can
   take as long as it takes.

 - Once the people working on the release are happy it builds and
   passes whatever tests, the final tarball can be made avaialable
   and the release announcements emailed.

 - Once the release is made, the release branch (which hopefully
   should contain only a small number commits) can be merged into
   main trunk.

The branch thing has the advantage that not everyone needs to be
involved in the release.  So, for example, if Fedora needs a new
release but that doesn't fit in with doko's timetable and Deepak
is right in the middle of a ton of plugin stuff, then Lillian et
al can branch and cut a release, and when doko is ready he can
pick up that release or, if a lot of stuff has changed since,
request his own, which the Fedora guys can either join in with
or not, as their schedules dictate.

Ok, that's my thoughts.

Cheers,
Gary

-- 
http://gbenson.net/