IcedTea6 releases

[Andrew John Hughes]

2009/2/23 Mark Wielaard <mark at klomp.org>:
> 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.

Nice, I have versions of IcedTea6/7 on my own server already and can
hopefully start making use of this.

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

Nice indeed! I could do with cherry-picking for 7.

> Cheers,
>
> Mark
>
>



-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

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