IcedTea release process
gbenson at redhat.com
Fri Jan 23 05:27:27 PST 2009
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
- 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
- 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
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.
More information about the distro-pkg-dev