Request for creation of OSX integration repo forest

[Kelly O'Hair]

My concern with this speeding up of the delivery of the Mac changes into jdk7u is that the jdk7u
and jdk8 repositories were related at one point in time, but are no longer directly related.
You cannot pull or push changesets back and forth between jdk8 and jdk7u repositories, you can
only transplant them by re-applying patches and hope it works.

Most projects are getting changes into jdk8 first, they let them bake and hopefully then transport the
same patch to jdk7u. As jdk8 morphs away from jdk7u, this may get more difficult but in my
opinion is easier than the other way around.
Patches that have been accepted in jdk8, get less scrutiny as they enter jdk7u in my opinion, because of
that bake time.

If this project works in the opposite way as all others, that could create problems if the patches put into
jdk7u are unacceptable to jdk8 reviewers. It also skews jdk7u and jdk8 for everyone else.
So although this may speed up this need, it may slow down many others.

I would rather see an all out effort to get these changes into jdk8 first, and perhaps pull in the
changes incrementally into jdk7u as it progresses.
That doesn't mean you can't have such a forest to hold the jdk7u work, but allowing it to be a development
forest without any controls on the changesets seems to open the door to the exact same problem we have
now, where we have a MacOS port set of changes that do not work on the other 8 platforms, and whose
changesets are potentially unacceptable to the jdk8 reviewers.

If having this forest provides a place to hold vetted MacOS port changesets, that vetting needs to include
review and acceptability into the jdk8 repositories, in which case, why can't they be in jdk8 too.

Just my opinion.

-kto

On Oct 9, 2011, at 9:59 PM, Paul Hohensee wrote:

> Inline:
> 
> On 10/7/11 5:11 PM, Phil Race wrote:
>> Hi Paul,
>> 
>> A few comments ..
>> On 10/7/2011 1:36 PM, Paul Hohensee wrote:
>>> The ideas are:
>>> 
>>> 1. In the interest of delivery speed, we want the OSX port to go into the 7
>>> update train and get forward-ported to 8 from there.  At the moment,
>>> there's not much difference between 7u and 8, so for at least the initial
>>> work a forward port should be not very difficult.
>> 
>> That is understood but a lot of us still bear scars from the 6ux - > JDK 7 fix deficit
>> and the rule was made "jdk 8 first, back port to 7". So someone would have
>> to negotiate an exception to this.
> 
> Yes.  I think that's me. :)  If necessary, I'll take on the forward port.
> 
>> 
>>> 
>>> 2. The proposed forest would be a development integration forest
>>> and thus as stable at any given time as the component development
>>> teams make it.  It's specifically a child of jdk7u, which the macos-port
>>> forest is not, and we don't want to necessarily start with the current
>>> content of the macos-port forest.  The proposed forest isn't a "master"
>>> forest in the sense of jdk7u or for that matter jdk8.  Think of it as being
>>> like the jigsaw development forest.
>> 
>> In mercurial there isn't such a thing as a "child". They are all peers.
>> So what this seems to be, is more a "cleaned up" version of
>> the macosx-port forest, conforming to jcheck, etc. I hope we don't
>> lose much of the "useful" history in doing this ...
> 
> "Logical child", in the same way that the hotspot group forests (hsx/hotspot-rt,
> hsx/hotspot-gc and hsx/hotspot-comp) are children of the hotspot integration
> forest hsx/hotspot-main.  Imo, it's up to the component groups whether or not
> changesets are transplanted as-is from macosx-port to the proposed repo.  For
> hotspot, we don't intend to do so.  The bsd portion of the port got pushed
> recently, and the rest will come along soon, though possibly not in the same
> form as Apple's code.
> 
>> 
>>> 
>>> 3. "Stable" should be defined by the component teams, but imo at
>>> a minimum it should be "pass the jcks on OSX and the complete
>>> set of current tests we're running on jdk7u for all other platforms".
>>> I.e., minimal stability for OSX and no regressions on other platforms.
>>> Once we've done that, we can think about discarding the proposed
>>> forest and pushing directly to jdk7u for further work.
>> 
>> Agree it must not cause regressions on other platforms.
>> But I suspect its going to take a while to get to all the tests passing ..
> 
> Yes.  Best to start soon. :)
> 
> Paul
> 
>> 
>> -phil.
>> 
>>> 
>>> 4. The current macos-port forest would be obsoleted.
>>> 
>>> Paul
>>> 
>>> On 10/6/11 2:41 PM, Phil Race wrote:
>>>> I think there's a while to figure out what makes sense as the "stable port" will take
>>>> a while to come about but someone needs to figure out what gets us where we
>>>> want to be, so I wouldn't rush the implementation ..
>>>> 
>>>> Anyway, on  openjdk we currently have
>>>> 1. macos-porting project
>>>> 2. 7u-dev
>>>> 3. jdk8
>>>> 
>>>> The goal has to be that #1 eventually becomes obsolete because the code
>>>> is stable and is in #2 and #3
>>>> 
>>>> If we replace #1 with a #4: 7u-dev-osx then the question is what does that buy us ?
>>>> I can suppose it is intended to be more controlled than the macosx-port but
>>>> less stable than the mainline 7u-dev, until sometime later. But if we are to
>>>> release a 7uN port for all platforms then we would need to make sure that
>>>> the fixes going into mainline also get merged into 7u-dev-osx .. and some day
>>>> we need to obsolete that. I think that there's a gap opening up already since
>>>> SFAIK, the macosx-port is based 7 GA.
>>>> 
>>>> Also we ought to consider when this all goes into 8. There it really should
>>>> go straight into 8.
>>>> 
>>>> -phil.
>>>> 
>>>> On 10/6/2011 9:37 AM, Dalibor Topic wrote:
>>>>> On 10/6/11 8:16 AM, Paul Hohensee wrote:
>>>>>> At JavaOne, Oracle announced the developer preview of the JDK7 Mac OSX
>>>>>> port. Apple is open-sourcing the port and Oracle plans to deliver it in
>>>>>> a future JDK7 update release.   Since the initial port will use the JDK7 code
>>>>>> base, I'd like to propose the creation of a project repo forest for the port
>>>>>> as a sub-project of the JDK7 update project. Once a stable port exists
>>>>>> in the OSX project repo forest, we can request permission to push it to jdk7u.
>>>>> Thanks for this proposal, Paul.
>>>>> 
>>>>> I posted a link to the Oracle JDK 7 Update release roadmap published at JavaOne
>>>>> and the corresponding press releases which give some more background information
>>>>> on the plans wrt to the Mac OS X port to provide some more background for this
>>>>> request. [1]
>>>>> 
>>>>> I'd like to open up this proposal for discussion until Monday.
>>>>> 
>>>>> cheers,
>>>>> dalibor topic
>>>>> 
>>>>> [1] http://mail.openjdk.java.net/pipermail/jdk7u-dev/2011-October/000534.html
>>>>> 
>>>> 
>>