6821003 and 6821777 (support for Windows 7) hasn't been backported to hsx16

[Volker Simonis]

I suspected something like this and it does not mean that I have an
optimal solution.

But I think at the point where hsxN is forked it should be possible to
tell which extra changes went into hsxN-1 (and hsxN-2, ...) that are
not alerady in hsxN and these changes should be the first ones which
should go into the newly forked hsxN. With the help of the bug
database, this could probably be done mostly automatic and would catch
most of the problems. Relying on each developer to check at every new
hsxN fork for relevant changes he did in a previous hsx fork seems
overly optimistic here...

Thank you for the explanation and best regards,
Volker

On Sat, Nov 21, 2009 at 8:23 AM, Erik Trimble <Erik.Trimble at sun.com> wrote:
> Volker Simonis wrote:
>>
>> 6821003 and 6821777 (support for Windows 7) which was backported to
>> hsx14 hasn't been backported to hsx14 and I think this should be done.
>>
>> Is there a general mechanism in place to aussure thatt all changes
>> which were integrated into hsx14 will also be in hsx16 (i.e. that
>> hsx16 is a true superset of hsx14)?
>>
>> Regards,
>> Volker
>>
>>
>
> This is a hard problem.  Here's why:
>
> (1)  hsN is forked, and hsN+1 becomes the new development branch for JDK 7
> (2)  hsN now becomes targeted at a JDK 6 / OpenJDK 6 release (and, most
> likely, several releases)
> (3)  fixes for hsN are not automatically relevant to hsN+1,  as the fix may
> pertain to something that (a) is being replaced by something better in hsN+1
>  (b) doesn't occur in hsN+1 due to it being used with a different JDK
> version, or (c) breaks something in hsN+1 due to a different JDK version.
>
> Basically, we're in version hell, as with all large projects.
>
> The only way to "sync" is to do it manually - that is, for every fix made to
> a hsN, the developer must manually evaluate it as to it's relevance into
> hsN+M, and push the fix manually.  It's what we do internally at Sun.
>
> Sorry, but I can't see any other way of doing this, except as you've noted:
>  look through the fixes, and forward port anything desired.
>
>
> --
> Erik Trimble
> Java System Support
> Mailstop:  usca22-123
> Phone:  x17195
> Santa Clara, CA
>
>