IcedTea release process

[Andrew John Hughes]

2009/1/23 Gary Benson <gbenson at redhat.com>:
> 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.
>

Yes, that's a good idea.  I don't want to go into it too much now
either, but we should raise things both now and after FOSDEM on the
list so that non-attendees are also involved in the discussion.

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

Yes, primarily for promoting our work.  On that respect, we should be
pushing release announcements to a wider audience, and make mention of
a certain company which pays the wages of many developers on
IcedTea...

>  - 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?
>

My impression is that both use a mix of release and non-releases as
the basis for distro versions e.g. I apparently have '1.4' on my F10
laptop but obviously there is no 1.4 yet.  So that was based on a
non-release tarball, but I know Lillian also does the releases so she
can do matching RPMs.  I've not looked at the Debian and Ubuntu
releases in as much detail (mainly because there is still no Debian
stable release yet), but I get the impression doko does something
similar.

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

I packaged IcedTea6 and 7 for Gentoo, and these are based on releases.
 As Gentoo is source-based, having release tarballs is preferable
otherwise the project has to host its own tarball containing a
snapshot of the repository.
Clearly others are less concerned about the release tarballs going
forward, because I seem to be the only one backporting the security
fixes... they would be a good reason for a release branch.

>  - 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?
>

Maybe mjw has/could get some web stats as he maintains the server...

> 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 :)

Exactly, and to reach points of stability.

> 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.
>

I do wish more people were doing TCK runs.  You know as well as I do
how hideous the secrecy of it all is, but it's something we have to
live with until Sun work out to handle this better.  It's already a
pity we can't put Classpath through the TCK, at least we should be
making use of it on all released IcedTea builds (i.e. I'm thinking
primarily of the Debian/Ubuntu ones...)

> 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.
>

That's a release process I've not seen before, but then IcedTea is a
project we've not really seen the like of before.  Other than you, aph
and Deepak, no-one really does any hacking on new code for IcedTea.
It's all fixing bugs in code from elsewhere and making things
distributable so it's really a joint distro project of sorts.  In that
regard, this idea of letting individual distros handle their own
releases effectively is an interesting and perhaps workable one.

However, I think to give IcedTea an identity of its own, it needs to
have its own release cycle and the simplest way to do that is to
simply have a point at which things stabilise and release on a regular
basis; maybe every 3-4 months.  If distros want to use that, they can.
 If they want to do it later or earlier, they should tag the tree and
use a known snapshot at that point.  aph will know much more about
this, but I believe gcc works something like this - there is a regular
release cycle (with a clear stability period) from the core team, but
often distros ship something else and have their own branches for
working on these.  And releases have their own branch too, so they
don't bitrot with major bugs and security issues.

Remember with hg everyone has a branch already, so a public
icedtea6-fedora or icedtea6-ubuntu tree would be fairly low cost if
Lillian or doko want more control over what they use.  I know more
about handling separate trees than Mercurial's branching options so
we'd need to look into that more if we wanted to use it instead.
icedtea7 itself is a very wayward branch of icedtea6 these days; it
sips up most of the patches coming from icedtea6 but works against a
different OpenJDK tree which has its own foibles and requirements.

> Ok, that's my thoughts.
>
> Cheers,
> Gary
>
> --
> http://gbenson.net/
>

Cheers,
-- 
Andrew :-)

IcedTea/OpenJDK software engineer
Red Hat, Inc.

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8