OpenJDK6 Repositories

[Joseph D. Darcy]

Kelly O'Hair wrote:
>
>
> 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.

That is correct; b15 will the first Mercurial-based source drop.  The 
code in b15 will be semantically the same as b14 except for movement of 
the control workspace files, moving the README file, and other other 
changes necessary for the Mercurial conversion.

New bug fixing, etc. will resume with b16.

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

We may just want to adopt one of the existing already Mercurialized 
HotSpot 14 repositories managed by that team; details will need to be 
worked out later.

-Joe