Draft Ground Rules

[Andrew John Hughes]

On Wed, Jul 13, 2011 at 02:37:06AM +0200, Dalibor Topic wrote:
> Let's start with the ground rules. 
> 
> They are somewhat inspired in parts by the OpenJDK 6 Process, and try to set the stage for open and transparent development. For example, approval requests for changes submitted to JDK 7 Updates should happen in one central place, to allow the Participants on this list to follow along with the development of the updates. Code reviews, otoh, traditionally have taken place on a variety of openjdk lists, so the draft ground rules take that into consideration.
> 
> Draft Ground Rules:
> 
> Rule 0: This process is subject to change. Changes MUST be approved by Project Lead and Technical Lead. Changes considering development in OpenJDK MUST be publicly discussed on the jdk7-dev mailing list prior to approval to allow for public feedback. Project Lead is Dalibor Topic, Technical Lead is Edvard Wendelin.
> 

+1 to more public discussion.  Too many changes are just committed with no public review.

> Rule 1: All changes that are not specific to JDK 7 Update MUST go into JDK 8 first. As a special exception, a change MAY go into JDK 7 Update if it is at the same time also proposed for inclusion into JDK 8.
> 

With OpenJDK6, we also required that they had 'soaked' for a sufficient time in OpenJDK7, say
one build drop.  This ensured that they had been through release integration prior to backport.

> Rule 2: The always open mainline JDK 7 Update forest is maintained by the Project Lead. Exceptions to that are e.g. specific release repositories, where the Project Lead MAY delegate that authority.
> 
> Rule 3: Changes submitted for a JDK 7 Update forest MUST go through code review, and MUST be approved by the maintainer for that forest. The maintainer of a forest MAY delegate that authority, allowing for approvals to happen in a more finely granular fashion - per repository, for example.
> 
> Rule 4: Maintainer approvals for public JDK 7 Update forests MUST take place on the jdk7u-dev at openjdk.java.net mailing list. Code reviews SHOULD take place on that list - if they take place somewhere else, as part of the approval request a URL for the public code review MUST be provided.
> 

+1 for this as above.

> Rule 5: A maintainer for a forest MAY pre-approve changes undergoing code review for JDK 8 for commit to their forest in JDK 7 Update.
> 
> Rule 6: A maintainer for a forest MAY request additional reviews for changes to be performed before it is approved for their forest.
> 
> Rule 7: A maintainer for a forest SHOULD coordinate with the appropriate stakeholders to determine whether changes are appropriate for their forest.
> 
> Rule 8: For changes submitted for inclusion into a public JDK 7 Update forest, the corresponding bug tracker entry SHOULD be publicly visible.
> 

+1, but what about security issues?

> Rule 9: If the corresponding bug tracker entry is not publicly visible for a change submitted for inclusion into a public JDK 7 Update forest, the submitter SHOULD provide guidance for code review.
> 
> cheers,
> dalibor topic
> -- 

-- 
Andrew :)

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

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37