OpenJDK6 Repositories

[Andrew John Hughes]

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?

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

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

> 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,
-- 
Andrew :-)

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