IcedTea release process

[Andrew Haley]

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

Some random thoughts:

I agree that IcedTea releases probably should have their own release
branches.

Gcc is a complicated project, and at any time several independent
projects are going on, each in its own branch, with merges from trunk.
We could do that in IcedTea, but we don't need to at present.

The distros need a clear gcc release version to use, so they make
their own branches, bases on the gcc release branches.

The gcc model of stabilizing the trunk and then blocking all
non-critical checkins is IMO not one for us to follow on IcedTea.  It
holds up all progress for an indeterminate time.  Besides, we are not
in control of everything here: when upstream OpenJDK does something
big, we pull it in.  So, upstream really has control of the timetable,
and that's how it should be.

We need to sympathize with each other.  There are several independent
projects in IcedTea, each with their own life cycle.  Core OpenJDK on
x86 is highly performant and stable.  Zero is almost at a point where
it is stable.  Shark is not yet done, and will continue to change very
rapidly.  JWS and the plugin are stabilizing.  Etc., ...

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.

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.

The elaborate processes that gcc uses are not all necessary for
IcedTea because we're a fairly small group and, as Andrew Hughes pointed
out, we are mostly working on stability and bug fixes for a project
that's fairly stable anyway.

Andrew.