OpenJDK Community Census

Dr Andrew John Hughes ahughes at
Thu Sep 15 13:27:38 UTC 2011

On 14:51 Mon 12 Sep     , mark.reinhold at wrote:
> 2011/9/8 17:18 -0700, ahughes at
> >     ... I was pleased to see acknowledgement of my work by my new positions,
> > but I am confused by a number of things:
> Thanks for your questions.  Answers inline below.
> > Groups
> > ======
> > 
> > I am a little confused as to how groups fit in or even as to what
> > their purpose is.  The bylaws defines a group as 'a collection of
> > Participants who engage in open conversation about a common
> > interest.'.  It's not clear to me what the point is of defining that
> > collection and having membership of it, given such conversation
> > regularly takes place on the mailing lists between both people who are
> > members of these groups and those who aren't.
> Groups are meant to capture the slowly-evolving social structures of the
> Community.  As such they're generally longer-lived than Projects, and
> they're also a bit harder to create and dissolve.  A Group can have its
> own web content, independent of any particular Project, which is writable
> by all of the Group's Members.  (So far that service hasn't been used
> very much, but I expect it to become more widely used as the overall
> infrastructure improves.)
> Membership in a Group is a stepping stone to becoming an OpenJDK Member;
> being a Committer in at least one Project is the other.  There are two
> paths to OpenJDK Membership so that people who make contributions in
> forms other than code can eventually become OpenJDK Members and thence be
> able to vote on new Project proposals, in GB elections, and so forth.

Ok, so it's essentially about becoming an OpenJDK member and getting voting rights.

> > It's not clear how those currently not in a group become members or create
> > new groups.
> This is spelled out in the Bylaws [1].  Prior to the Bylaws we had
> informal interim guidelines for creating new Groups and for nominating
> new Group Members [2].  They were not often used.

I realised I hadn't been clear here after I sent the first mail.  I understand the
rules for doing so.  What I was referring to was how it would happen *in practice*
as there haven't been many nominations in the past and there still seems to be
a notable Oracle/non-Oracle divide.  I think we covered this below anyway.


> > Even though a member is defined as 'a Contributor who has demonstrated
> > a history of significant contributions to the Community', the
> > automated creation of members is based on the current group system,
> > not contributions.
> Right.  The transition plan [3] was deliberately written to use current
> Group Membership data rather than mandate that someone try to discern who
> should belong to which Group based upon past contributions.  The latter
> approach could too easily lead to controversial decisions.  Insofar as
> there are people -- including you -- who pretty obviously deserve to
> belong to various Groups, I'll be encouraging appropriate Group Leads
> to consider nominating them shortly after the Bylaws go into effect.

Ok, I take it that means there are Oracle group members who are expected
to be group members but haven't committed to OpenJDK.

> >                     It's not clear to me how group membership will
> > grow or how new groups will be created, given the current membership.
> > I know the process (OpenJDK members create groups, group members
> > nominate new members), but I haven't seen many people being voted into
> > groups in the past.
> Under the old informal guidelines there wasn't much benefit to being a
> Group Member, so my best guess is that people just weren't motivated.

I think it may also be an issue of having to be nominated by an existing
group member.  Most group members are Oracle employees and I haven't seen
many nominations of non-Oracle employees.

> > ...
> > 
> > Porters Group
> > =============
> > This follows on from the previous point about electing new members.
> > 
> > This group seems to be sponsoring seven projects (bsd, caciocavallo,
> > haiku, icedtea, macosx, mips and zero) yet none of the leads of these
> > projects are members of the group.  Indeed, the group only has three
> > members, including the lead.
> There's no requirement that the Leads of the Projects being sponsored by
> a Group be Members of that Group.

But there is: "If a Project loses all of its Sponsoring Groups then it is dissolved."

> > I'd also see IcedTea as being a distinct group rather than a porting
> > effort,
> It was originally proposed as a Project, so that's what it is at the
> moment.

It wasn't possible to propose it as anything else AFAIK.

> >         but obviously no-one working on IcedTea is eligible to propose
> > such a group.
> I'm confident that will change fairly soon.

Good.  I note chrisphi is an OpenJDK member so he could nominate other
Red Hat developers to be members.  It all seems a little contrived though.

> > jdk7 & jdk8
> > ===========
> > I've been given a role as reviewer for both these projects (thanks for
> > that).  However, I'm not clear how this works.  I've never committed
> > to either and I doubt many others have either, as changes are fed
> > from other repositories (tl, awt, 2d, build, etc.) into these trees
> > by the release team at Oracle.  So how will I actually review changes?
> > Is there a further change planned?
> > 
> > I have committed to 2d, awt, tl, build and swing in the past, which I
> > believe should make me a committer on these projects.  But I have no
> > such role.  Indeed, I'm not even an author.  Could someone explain the
> > logic here?
> Both the JDK 7 and JDK 8 Projects have a set of integration forests
> (tl, awt, 2d, build, etc.) into which Committers push their changes.
> If you've committed to one of thoese integration forests then you have,
> effectively, committed to the corresponding Project even though you
> didn't push directly into the Project's master forest.
> There are Groups whose names are the same as some of these integration
> forests (e.g., AWT, Build, Swing), but there is no formal connection
> between Groups and integration forests.

Ok, that was the confusion.  That's not very clear to external developers.

> > HotSpot
> > =======
> > I've contributed a number of fixes to HotSpot.  However, it is impossible
> > for me to become a contributor as:
> > 
> > 'If you have directly pushed one or more changegroups into a Project's
> > Mercurial repositories then you are considered a Committer.'
> > 
> > Every time I have submitted a patch, I have been told this needs to go
> > through an internal JPRT system and has to be done by a member of Oracle.
> > So, even if I had contributed over a hundred patches, I could still not
> > become a HotSpot committer.  However, someone committing a single patch
> > inside Oracle can.
> > 
> > Was some attempt made to accomodate this inequality during the census?
> > And will this requirement be removed going forward?
> Sorry, but no attempt was made to address this issue during the Census.
> Properly addressing it requires making the JPRT system, or something
> similar, available externally.  We want to make that happen in due
> course, but in the meantime I'll encourage the HotSpot Express Project
> Lead to add you and other regular HotSpot contributors as Authors.

Good to hear this is being worked on.

> > jdk6 members
> > ============
> > 
> > The jdk6 project membership seems a little odd to me and I was wondering
> > how the positions were arrived at.  The following are all listed as reviewers:
> > 
> > alanb 	       Alan Bateman
> > andrew 	       Andrew John Hughes
> > anthony        Anthony Petrov
> > chegar 	       Chris Hegarty
> > darcy 	       Joe Darcy
> > dcubed 	       Daniel D. Daugherty
> > igor 	       Igor Nekrestyanov
> > jjg 	       Jonathan Gibbons
> > jjh 	       Jim Holmlund
> > katleman       David Katleman
> > ksrini 	       Kumar Srinivasan
> > malenkov       Sergey Malenkov
> > martin 	       Martin Buchholz
> > michaelm       Michael McMahon
> > mullan 	       Sean Mullan
> > prr 	       Phil Race
> > tbell 	       Tim Bell
> > weijun 	       Max Weijun Wang
> > 
> > While I know I've committed a lot to OpenJDK6 (including several big
> > HotSpot merges), I'm not aware of any others on this list having
> > 'pushed at least 32 changegroups into such a Project's Mercurial
> > repositories' (apologies if I'm wrong here).  I know some like
> > Jonathan, Daniel and Martin have actively contributed changesets, but
> > I can't recall it being more than ten.  Obviously, Joe is the
> > former maintainer so he deserves the merit for that instead.
> > The others I struggle to remember being involved at all.
> Going strictly by the 32-changegroup threshold, the list of Reviewers for
> the JDK 6 Project would be just:
>     andrew  Andrew John Hughes
>      darcy  Joe Darcy
>        jjg  Jonathan Gibbons
>      ohair  Kelly O'Hair
> That seemed unnecessarily limiting, especially in light of the fact that
> many contributors into JDK 6 already have the Reviewer role in JDK 7 and
> its successor Projects.  In order to avoid having to vote a bunch of
> people into the Reviewer role for JDK 6 just to get their backporting
> work done I decided to make any JDK 6 Committer who's already a JDK 7
> Reviewer into a Reviewer for JDK 6 as well.

Ah ok, so the issue here is not what I thought (that authors were being
used in preference to committers), but just the fallout of many OpenJDK6
committers not being very active in 7.

> It's been suggested to me by others that even that's too limiting, and
> that instead the roles for JDK 6 should be initialized exactly as for the
> JDK 7, JDK 7 Updates, and JDK 8 Projects.  I'd appreciate feedback from
> you, Kelly, and Joe as to whether you think that's a reasonable approach.

That makes sense to me.  As OpenJDK6 commits are backports, the original
committers need to be eligible to review the backport.  Of course, how useful
reviewer status is depends on whether a reviewer can approve a backport or
it has to be Kelly.


> That's up to Kelly.  I'll let him speak for himself.
> - Mark
> [1]
> [2]
> [3]

Andrew :)

Free Java Software Engineer
Red Hat, Inc. (

Support Free Java!
Contribute to GNU Classpath and IcedTea
PGP Key: F5862A37 (
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37

More information about the discuss mailing list