IcedTea release process

[Matthias Klose]

Andrew Haley schrieb:
> Andrew John Hughes wrote:
> 
>> 2009/1/23 Gary Benson <gbenson at redhat.com>:
>>> 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.

There's another model, which works fine for OOo (IMO): The ooo-build repository
accumulates patches (even distribution specific) for an upstream release (which
could be compared to a source drop), and once the patches stabilize or there is
a new upstream version, the ooo-build repo is branched.

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

basing branches on source drops would have the advantage of not having these
gaps between source drops in IcedTea releases.

> In my view, IcedTea 6 trunk should permanently be in a state where it
> is fit to cut a release.  This requires continuous testing.  Already
> at Red Hat we run a TCK test every night, and any changes to IcedTea
> that cause a TCK failure will immediately be fixed.

As mentioned in another post, making test results of public tests available for
comparision would be nice (e.g. include/post the jtreg-summary.log). How much
relevance do have the mauve tests? AFAIK Fedora does run a subset of these on
their buildds.

> With that in mind, I think that anyone should be able to request a
> release from trunk for whatever reason they want.  At that point, if
> there is work (on the plugin, for example) that is partially done, the
> maintainer will point this out.

That should work as well. I'd like to ask for some days between the prerelease
announcement and the final release to be able to at least include something in
the release notes.

  Matthias