river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Hurley <Jim.Hur...@Sun.COM>
Subject Re: [Vote] - River basic dev process
Date Fri, 14 Sep 2007 17:33:06 GMT
Thanks to everyone for casting your votes.

The vote passes with nineteen +1 votes (11 from PPMC
members), one +0.5 vote, one 0 vote, and one -0.5 vote (all
from PPMC members).  The votes were:

-------------------------------------------------------
+1  Zsolt Kuti
+1  Jerome Bernard
+1  Sean Landis
+1  Jim Waldo*
+1  Dan Creswell*
+1  Vinod Johnson*
+1  Frank Barnaby*
+1  Greg Trasuk
+1  Nigel Daley*
+1  Jukka Zitting*
+1  Mike Morris
+1  Bill Venners*
+1  Jim Hurley*
+1  Jools Enticknap
+1  Calum Shaw-Mackay
+1  Juan Ramirez*
+1  Gregg Wonderly
+1  Peter Jones*
+1  John McClain*

+0.5  Bob Scheifler*

0    Ron Mann*

-0.5  Mark Brouwer*

* - binding vote from PPMC member
-------------------------------------------------------

There were a bunch of positive comments associated with the
votes, but I also wanted to log the requests and concerns that
were also voiced as part of some of the votes:

-- Sean: I encourage commiters to go beyond the requirements  
     regarding unit tests

-- Mark: I agree with all process guidelines except for CTR related  
     to non-public API changes, I have good hopes though I will be
     proven wrong ...

-- Ron: I share Mark's sentiment [above], although perhaps I'm a tad  
     more optimistic.

-- Nigel:This is fine as a starting point for incubation.  I hope our  
testing 
     requirements and review requirements tighten up over time.

-- Gregg:This will be a good start.  I do think that some RTC  
considerations 
     will be made over time and I really do think that there will be  
ample
     review with CTR because of those involved for most things.

-- PeterJ: I do share some of the concerns expressed by others but 
     would like to see things move forward and agree that this is a good
     starting point.


thanks -Jim



On Sep 11, 2007, at 9:39 AM, Jim Hurley wrote:
> We're ready to move on a vote...  please respond with a:
>
> +1  (accept this Proposal as the starting point for the River
>         project basic dev process)
> 0    no strong opinion
> -1   Do not accept because...
>
> The vote is open for 72 hours (until Friday).  I encourage everyone
> to vote (it really gives us a much better sense for what the general
> consensus is), but PPMC votes are binding.
>
> thanks -Jim
>
>
> ---------------------------------------------------------------------- 
> ---------------
>   PROPOSAL
> ---------------------------------------------------------------------- 
> ---------------
>               Apache River - Basic Development Process
>
> * Tracking issues and changes
>      A JIRA issue is required for any substantive change.
>      JIRA issues are not needed for small (e.g., typos) changes.
>
>      In order to keep the list of JIRA issues under control, it is  
> expected
>      that any controversial issue or user request for a feature or  
> design
>      change be discussed on the river-dev list prior to entering it  
> into JIRA.
>
> * Issue discussions
>      The preferred place of discussion on issues is the river-dev  
> mailing
>      list.  A link to the beginning of the mail thread on the issue  
> should be
>      placed in the JIRA issue so that users looking through JIRA  
> can easily
>      view the thread of discussion on an issue. Please keep the  
> Subject line
>      the same so that the email thread hangs together.  It's also  
> recommended
>      that a summary/conclusion on an issue (if appropriate) be  
> recorded in
>      the JIRA issue.
>
> * Code Reviews
>      - for public API changes:
>             RTC <http://apache.org/foundation/ 
> glossary.html#ReviewThenCommit>
>             These changes have potentially broad effects on developers
>             and users, and therefore will require a code review and  
> vote.
>             Since some of these changes will affect the API docs  
> ('specs'),
>             everyone within the Jini/River community is encouraged  
> to review
>             and vote.  The Committer votes are binding, but the  
> sentiment
>             of the entire Jini/River community will certainly be  
> strongly considered.
>
>      - for all other changes:
>             CTR <http://apache.org/foundation/ 
> glossary.html#CommitThenReview>
>             Although CTR is what's specified, developers should feel
>             comfortable requesting the list for peer review before  
> committing.
>
> * Testing
>       Developing test cases and running test suites are desired but  
> not
>       required prior to an integration.  If unit tests are created  
> for a change,
>       the developer is encouraged to add them to the JIRA issue for  
> sharing.
>
> * Handling security -related issues
>       There are three options associated with the "Security Level"  
> field
>        in the River JIRA instance:
>          o  "None"
>          o  "Security risk, visible to committers" - only  
> committers have access to
>              the issue with this option set
>          o "Security risk, visible to anyone" - the issue has a  
> security risk associated
>              with it, and the committers understand the impact.  A  
> resolution/fix has
>              been developed.
>
>      When a potential security -related issue is identified in the  
> River sourcebase,
>      initial discussion on it should occur on the private PPMC  
> list.  If the
>      person(s) who identified the issue are not on the PPMC, they  
> should be
>      included in the discussion.
>
>      If the issue is acknowledged as a valid security issue, a JIRA  
> issue needs
>      to be created with the "Security Level" field marked to  
> "Security risk, visible
>      to committers".
>
>      As soon as appropriate (for example, when the impact is  
> understood
>      and/or there is a resolution/fix developed), the "Security  
> Level" should
>      be changed to "Security risk, visible to anyone" and an  
> explanation/
>      discussion should occur in the broader River community on the  
> river-dev list.
>
> ---------------------------------------------------------------------- 
> ---------------
>
>
>
>


Mime
View raw message