OpenJDK6 Repositories

[Andrew John Hughes]

2008/12/9 Kelly O'Hair <Kelly.Ohair at sun.com>:
>
>
> 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.
>

Good, that means we can just change the patches when b15 is released.

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

I need to look at the affected patches in more detail, but they are
mainly the ones relating to building with ecj or Shark/Zero support.
Perhaps Gary can comment more on whether the latter could go upstream.

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

The default IcedTea builds download a tarball of either OpenJDK6 or
OpenJDK7.  There are options that can be passed to configure to use
Mercurial directly (--enable-hg) or an already downloaded zip
(--with-alt-src-zip) or an existing directory tree
(--with-openjdk-src-dir).

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



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