IcedTea6 releases

[Mark Wielaard]

Hi,

On Mon, 2009-02-23 at 10:20 -0500, Lillian Angel wrote:
> Andrew John Hughes wrote:
> > 2009/2/23 Andrew Haley <aph at redhat.com>:
> >> Mark Wielaard wrote:
> >>> So for now we wanted to go with a separate repo that someone can "claim"
> >>> when doing the release. They will then be responsible for updating the
> >>> release tree to the current icedtea6 tree, call for test results, merge
> >>> in any needed regression fixes, tag and finally release.
> >>>       
> >> Sure, but there's no need to re-use the same release tree. Â Once the
> >> release is done, further bug fixes may be needed against the same
> >> release, so a release tree should never be re-used.
> >
> > Reusing the same release tree seemed very strange to me as well.  I
> > have the vain hope that having a release tree might mean we can have
> > an upstream backport of important things like security fixes.  Hence,
> > I was thinking along the lines of something like releases/icedtea6/x
> > trees e.g. releases/icedtea6/1.4.1.
>
> I agree with this. Having a separate release tree for every release. It 
> could initially be created as an exact copy of the main tree (or some 
> tagged version), and appropriate patches could be applied or added.

I feel somewhat outvoted :)

So, I worked out a solution to the only technical objection I had to
doing this, no easy way to create repos or clones on the server. There
is now a hg-remote-clone command that will create a on-server clone of a
repo, so that it actually cheap (because it will use hard links when
possible). It also allows people with an account on the server to have
their own projects and repos on the server. I'll send out a separate
email on how to use it. But for releases it means that whoever claims to
be doing a release can now do:

ssh user at icedtea.classpath.org \
  hg-remote-clone /hg/icedtea6 /hg/release/icedtea6-x.y

So, I will remove the release/icedtea6 repo on the server now and let
the first person that want to do a release branch do the above.

> > I can't see any reason you'd want to feed a release tree back into
> > trunk.  The usual course of action and the point of a release branch
> > is to be able to cherry-pick suitable additional patches and apply
> > them against a known stable base for release.

So, my reason for the original suggestion was to make sure that there is
one repo "with everything". Especially tags. So that once a release was
made the "trunk repo" was also updated with everything and you could see
the branch points, the patches and tags for each release made.

I do agree that fixes should always go on the main tree, and only then
be applied to the stable branch(es). I see that mercurial actually has a
(standard, but not enabled by default) extension "transplant" for doing
that easily:
http://www.selenic.com/mercurial/wiki/index.cgi/TransplantExtension
(Why are so many nice mercurial extensions disabled by default?)

Cheers,

Mark