2011/5/26 17:40 -0700, david.hol...@oracle.com: > Section 4 Groups states: > "Groups do not have code repositories of their own but they may sponsor > Projects, which do. " > > Is this a prohibition or just an expectation?
A prohibition. > I'm unclear on the notion of > "ownership" here and the implications. For example, at present the Hotspot > group uses numerous repositories within the JDK7 forest, and while I would > have > said the Hotspot group owns them, it may be more correct to the say the JDK7 > project owns them and the Hotspot group just uses them within the context of > the JDK7 project. Yes, the latter is correct. > However, moving forward the Hotspot group has expressed a > request that its repositories be independent of the current JDK version and so > there are no hotspot repositories under jdk8 but rather they have been created > as a hsx forest. Actually there will be at least one Hotspot repo under JDK 8, namely the one into which the Hotspot Group integrates the version of Hotspot to be used in JDK 8. > Does this rule imply that there needs to be a "Hotspot > Express" project, sponsored by the Hotspot group, which then owns the hsx > repositories? Yes. In fact it appears that an HSX Project was proposed and voted upon in 2009 [1], but while the repos exist somehow the rest of the Project was never set up. I'll look into that. > Or does the jdk8 project implicitly own the hsx repositories (at > least until jdk9 comes along)? The more I think about it the more unclear is > the relationship between groups, projects and repositories. >From the Q&A: Groups are meant to capture the long-lived, slowly evolving social structure of the Community, whereas Projects are time-bound efforts to create specific artifacts. The Core Libraries Group, e.g., has existed for many years, and its Members participate in a variety of Projects (e.g., JDK 7, New I/O, Coin, and Jigsaw). The Sponsorship mechanism allows a Project that does not have the attention of at least one Group to be garbage-collected, and also provides for the selection of a Project's Lead by the Group Leads of all Sponsoring Groups. Large Projects may well be led by individuals who also happen to be Group Leads; small Projects, by contrast, might be led by Contributors who are not yet even OpenJDK Members. Does that help? > Section 7 Project Roles: > > The relationship between group membership and project "membership" is > unclear. Do the authors/commiters/reviewers of a project have to be members of > the sponsoring group? No. > Do group members have any automatic role in the projects > the group sponsors? No. > Does a project have to publicly list all its authors/commiters/reviewers ? This information will be publicly accessible, in the core community database. > How do projects relate to each other? For example we presently have Project > Lambda looking at defining closures with the intent to make them part of the > Java language in JDK8. But the JDK8 project is responsible for defining > everything in JDK8, so how is the connection between the two projects made? Is > there a notion of sub-projects? There is no notion of sub-projects; that level of structure doesn't seem necessary. Relationships between Projects are informal, and up to the respective Project Leads. In the case of Lambda the expectation is that eventually the Lambda code will be delivered into JDK 8 (though not by merging all the changesets from the Lambda forest into JDK 8, that would add a lot of noise). At that point Lambda itself will be, essentially, done. > How do Projects relate to Java Specification Requests and the JCP process? The relationship is, again, informal. If a Project is associated with a JSR then that relationship should be declared up front, and it will be up to the Project Lead to satisfy the requirements of the JCP process. > Both Project leads and Group Leads can delegate obligations but not > authority. This would seem to be problematic if the lead may be away even for > just a couple of weeks. Is there provision for appointing an interim-lead in > such circumstances? No, not at the moment, but we'll consider that. > --- > > Technical Appeals Process: > > There seems to be no time constraint on the formation of the panel of experts. > > There seems to be no time-limit on when an appeal must be lodged after a > decision by the OpenJDK Lead has been made. Good points. We'll consider whether and how to impose such limits. > --- > > Transitioning to these Bylaws > > As part of the transition will the newly appointed Project leads, formulate > and > make public the initial set of authors/commiters/reviewers for each project? Authors and committers will be carried over from the current database. Reviewers will be appointed by the OpenJDK Lead, in consultation with the Project Leads. Thanks for your feedback! - Mark [1] http://mail.openjdk.java.net/pipermail/discuss/2009-August/001374.html
