OpenJDK 6 Build 17

[Gary Benson]

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/