Mercurial repo for openjdk6 drops

[Kelly O'Hair]

Andrew John Hughes wrote:
> 2008/9/25 Kelly O'Hair <Kelly.Ohair at sun.com>:
>>
>> Mark Wielaard wrote:
>>> Hi Kelly,
>>>
>>> On Thu, 2008-09-25 at 14:53 -0700, Kelly O'Hair wrote:
>>>> I'm starting to work on the OpenJDK6 Mercurial conversion. My plan is for
>>>> Build 5 to be the Rev 0 changeset, and I will try and create changesets
>>>> for each of the bug fixes in a Build.
>>> Would it be possible to reconstruct the openjdk7 revision that was the
>>> original starting point for the openjdk6 tree? That would be very
>>> helpful to have for forward and backward porting between the two trees.
>>> If you could make that rev0 and then have one giant changeset to build 5
>>> as rev1 that would be really great.
>> Sorry... unknown legal issues may be lurking in Builds 0-4, not sure I
>> want to go there. :^(
>>
> 
> I don't think Mark's intention was to include builds 0 to 4, but to
> have the initial
> import as the OpenJDK7 build drop which was the original base for OpenJDK6
> (this code has already been released) and then have the next commit as b5.

Easier said than done... We started with jdk7 b19, but it was jdk7 b23 that
did the major restructuring of the source tree. So we started with something
between jdk7 b19 and jdk7 b23. I'll use jdk7 b23 as rev0, so the first
changeset will take us to openjdk6 b00 (the starting point for openjdk6),
then a changeset for b1, b2. b3. b4, and b5. Then between b6 -> b12 there
will be multiple changsets, the last one for each build bringing it into
sync with the formal build source drops. That's my plan anyway...

Having b0-b4 is a minor effort, and may help in sorting out where bugs got
fixed prior to the official open source b5.

> 
>>> For example we have found some nasty AWT bugs that have been fixed in
>>> openjdk7, but it was somewhat hard to track down what was needed because
>>> the origin of the awt code in openjdk6 wasn't exactly known.
>>>
>>>> So I'll be going through the list of fixes for each build, try and create
>>>> a
>>>> changeset for it, and at the end I'll copy in the final source for that
>>>> build and see what I missed. The final changeset may be one for the
>>>> remaining
>>>> bugs fixed. Then I'll tag that changeset and move on to the next build.
>>>> I'm calling this Total Recall, in that I'm essentially doing a replay
>>>> of the Build 5 through Build 12 changes.
>>> Wow. That is really, really great. And it must be a real pain to go
>>> through all that. Thanks a lot for doing this! Hope it will not drive
>>> you mad.
>> Mad? Mad? Ha Ha! ...  Hopefully they aren't coming to take me away...
>> http://uk.youtube.com/watch?v=2o7bMdAyPes
>>
> 
> Indeed, this is really great.  Thanks for doing it.

No problemo...  but wait to thank me until it's done... ;^)

-kto


> 
>>>> One of my concerns is that normally we want every changeset fully vetted
>>>> with regards to at least building on all platforms.
>>>> Unfortunately with Teamware, the changes are often not kept in any
>>>> sequential
>>>> order like the Mercurial changesets, they are independent SCCS file
>>>> changes.
>>>> The history file can help me, but I'm dealing with a very old DSCM system
>>>> here.
>>>>
>>>> So I'll try and re-create the same order the changes were made, and then
>>>> occasionally make sure it builds on all platforms.
>>>> The final sources for each Build we know builds ok on all platforms,
>>>> those
>>>> are effectively the source bundle drops.
>>>> So I can't guarantee that every changeset is cleanly buildable on all
>>>> platforms.
>>>> Is that acceptable to everyone?
>>> It would certainly be to me. I am already very pleased that you are
>>> attempting to get more than just one changeset per build drop. I think
>>> the data will mostly be used for historical purposes (what was changed
>>> when together with what?). Not for actually building.
>> Good. I'll do the best I can...
>>
>> -kto
>>
>>> Thanks,
>>>
>>> Mark
>>>
> 
> Ok for me too.