OpenJDK6 Repositories

[Kelly O'Hair]

Andrew John Hughes wrote:
> 2008/12/9 Kelly O'Hair <Kelly.Ohair at sun.com>:
>>
>> Andrew John Hughes wrote:
>>> 2008/12/8 Kelly O'Hair <Kelly.Ohair at sun.com>:
>>>>  * They should match the contents of the OpenJDK6 source bundles, except:
>>>>   - No control directory, these files are in the top repository now
>>>>   - Previously you had to 'cd control/make && gnumake', now just 'cd . &&
>>>> gnumake'
>>>>   - README-builds.html is in the top repository, it's movement has
>>>> created
>>>>     a little confusion in the changesets, ultimately we will have one
>>>> copy.
>>> This causes issues with supporting the new hg tree in IcedTea as the
>>> patches are against paths with the control subdirectory present.  Is
>>> the intention for 6 to now follow 7 and not have a control directory,
>>> and will this extend to future bundles?
>> Yes and yes. For the most part the changes are simple, the
>> control/make/Makefile
>> becomes ./Makefile and the control/make/make directory becomes the ./make
>> directory. Less than 20 files are involved as I recall.
>>
>> The source bundle contents will look exactly like the forest, minus all the
>> .hg/ directories.
>>
> 
> The changes may be small, but it means maintaining separate copies of
> a number of IcedTea patches, purely because of the path change.  Can
> we have a new bxx drop and corresponding bundle when the repositories
> are launched so the two are in sync?

I assume Joe Darcy can speak to this. But I've assumed that B15 will be
released as "the" first mercurial version, and the b15 source bundle
will match the repositories. I think b15 is reserved for changes related
to this mercurial conversion and little else.

Are these IcedTea patches to these control makefiles anything we just want to
drag into the openjdk6 sources?

> 
>>>>  * Contributed changes should be documented in the changeset comments,
>>>>   if the contribution information is missing please let me know
>>>>  * These repositories were created from the TeamWare workspaces and a set
>>>>   of patches and documentation on those patches, we may have to re-create
>>>> them.
>>>>   If we re-create repositories again, the old ones will not be related
>>>>   to the new ones.  So any changesets you create with your clones
>>>>   should be viewed as temporary until the final repositories are put in
>>>> place.
>>>>  * The hotspot repository may be completely replaced when we upgrade to
>>>> HS14,
>>>>   so when that happens you may need to re-clone the hotspot repository.
>>>>
>>> Why not just pull from the latest HotSpot tree to JDK6?  Or will JDK6
>>> dispense with a HotSpot directory altogether?
>> There are some technical issues, and that may be the way it happens,
>> it just remains to be seen.
>> The hotspot express release requires that the VM be 100% operational for
>> multiple jdk releases, this will place different requirements on the
>> hotspot sources than other parts of openjdk6.
>> We want the most stable hotspot we can get in the openjdk6, I assume.
>>
> 
> I'm not suggesting the HotSpot repositories are constantly tracked,
> just that the tree is updated by a pull rather than purged and
> recreated.  I guess the problem might be that OpenJDK6 currently uses
> a HotSpot which never had a Mercurial repository so moving from that
> to b24 may be necessary first.

Again, I'm just not sure how this will happen yet.
I'll pass this on to the hotspot team.

> 
>> Mercurial changesets cannot be pulled and pushed around without also
>> getting all the parent changesets connected to them.
>> Changesets can be bundled and re-applied to another repository, but
>> they actually become new changesets (different revs) that are unrelated
>> to the original changeset. Picking and choosing changesets will probably
>> mean unrelated repositories.
>> Some decisions need to be made about how the hotspot and openjdk6
>> team wants to manage this over the long haul.
>>
>>>> Please let me know if you see anything wrong with these repositories.
>>>>
>>> Apart from being quite slow, they seem to work ok so far.  It took two
>>> goes to get a checkout, the build stalled and eventually timed out on
>>> jdk.
>> I assume your 'checkout' means 'fclone'?
>>
> 
> Yes.
> 
>> Cloning a forest is usually a one time operation, you keep a forest
>> around, and just do an occasional 'hg fpull -u' to update it, or that's
>> what I do. The 'pull' operations are usually fast.
>>
> 
> Yes, I expect people will make more use of the option to use a
> specified directory for OpenJDK with IcedTea6 than to constantly
> perform live checkouts.

Not sure what that means. I haven't built via IcedTea6.

With Mercurial you can use tags to get the clones as of a particular build:

   hg fclone --rev jdk6-bNN http://hg.openjdk.java.net/jdk6/jdk6 yourjdk6

where bNN is any build (b00 -> b14 right now) and you will get the
repositories as of that build, in the new layout (without control).
I must confess I did not verify all these build, just b13 and b14.

-kto

> 
>> We will continue to provide source bundles too, and it may make more sense
>> in some situations to just use the source bundles.
>>
> 
> This is still the default.  Enabling hg support in IcedTea6 is to
> enable the testing of changes between releases now that these will
> finally become fully visible.
> 
>> -kto
>>
>>>> The target date for official repositories is next week, once it is
>>>> official
>>>> we can add more changesets to correct problems, but we can't go back and
>>>> change the changesets already created.
>>>>
>>>> -kto
>>>>
> 
> Thanks,