OpenJDK 6 Build 17

[Andrew John Hughes]

2009/11/10 Gary Benson <gbenson at redhat.com>:
> Greg Lewis wrote:
>> On Tue, Nov 10, 2009 at 02:12:17AM +0000, Andrew John Hughes wrote:
>> > 2009/11/10 Kurt Miller <kurt at intricatesoftware.com>:
>> > > It would be fantastic if Sun would host a mercurial repository
>> > > for OpenJDK6 (i.e. bsd-port6 or the like). Is there a chance
>> > > that Sun could set that up for us? The lack of a central
>> > > repository is one of the reasons I haven't worked on OpenBSD
>> > > support for OpenJDK.
>> >
>> > Rather than creating a new separate tree, how about we just try
>> > and get the necessary changes into OpenJDK6 directly?  Then that
>> > would give a good base to move forward on getting support in 7
>> > too.
>>
>> For me, the latter is the key question.  How do we move forward with
>> getting BSD support (ultimately) into the current development tree
>> so we have less heavy lifting to do going forward?
>>
>> That's what I'd really like to come out of the discussion here.  I
>> think we've been pretty good at keeping the bsd-port tree of
>> OpenJDK7 up to date (its currently at b75 and I'll start moving it
>> to b76 once that tag goes down) but we still don't seem to be any
>> closer to getting the changes into the main source tree than we were
>> when we started.  How do we move forward with that?  Is Sun's
>> preferred method for us to go through OpenJDK6?  That certainly
>> doesn't seem to have been the case for Zero, which is probably of a
>> similar order of disruption, but I'm open to it for the BSD patches
>> if there is a solid reason for doing it that way.
>
> I would have thought the best way would be to get it into 7, and then
> propose a backport to 6 if you want it there too.  But I don't work
> for Sun so my word needs taking with a pinch of salt.
>
> As for how to go about getting it in, my experience has been that the
> Sun engineers are more amenable to being presented with a small number
> of large patches than they are to a large number of small patches.
> That confused me at first; if someone presents _me_ with some massive
> monolithic patch my first response is generally, "hmmm, can you split
> that?"  I guess they have a certain amount of process attached to each
> commit -- create a bug, run the regression tests, etc, etc -- and they
> don't want to do that 50 times.
>
> Having said that, you do need to split the patches (webrevs really)
> across the different forests.  Zero ended up being split into a
> HotSpot webrev and an everything-else webrev, but Zero had no class
> library changes and I understand the BSD port does.  So maybe make
> three webrevs: HotSpot, class library, and everything else.  Just
> bear in mind that each team will most likely test only its own webrev,
> so each one needs to work in isolation on the existing platforms that
> Sun will test it with.  Obviously the BSD port _won't_ work, but it
> must still build on the other platforms.
>
> I'd also suggest getting some kind of one-to-one contact for each
> separate webrev.  Find an actual person at Sun that you can email
> (I guess Dalibor can help you with that) and assign one person on
> your side who is in contact with them.  It's not the open-source
> way, but it seems to work better.
>
> And be patient.  Between mailing the initial Zero webrev and having
> stuff committed took 2-3 months, and a lot of that was waiting for
> various teams at Sun to have a meeting or whatever.
>
>> Certainly its starting to get a little demotivating to me personally
>> and I can't help but wonder if other team members don't feel the
>> same.
>
> I know your pain.
>
> Hope that helps :)
>
> Cheers,
> Gary
>
> --
> http://gbenson.net/
>
>

Thanks Gary.  I'll second what you've said, though it's worth noting
that the per-team splitting Gary mentions applies within the JDK
repository.  Every team but the HotSpot and compiler teams work on the
JDK workspace in different areas.  Gary's changes were build changes
and so were reviewed and approved by the build team.  I'm guessing
there will be actual Java and native code changes/additions in the BSD
port, which will need review by the other JDK teams in their
particular specialist area.  I also suspect that, unlike the Zero
patch, there will be multiple features from making some code just
build on BSD to adding a implementation of an API for the platform and
these probably make more sense under different bug IDs (though, as
Gary says, Sun engineers seem to be happy to create bug IDs such as
XXXXXX: BSD port work).

But as I say, we're guessing here.  It sounds like the best thing to
do to begin with is for those working on the BSD port to first of all
come up with a list of the BSD-only changes on the new wiki, and we
can start splitting things up from there -- IcedTea has such a 'hit
list' at http://icedtea.classpath.org/wiki/IcedTea_JDK6_Patches
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

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