river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Venners <bv-...@artima.com>
Subject Re: [Vote] - River basic dev process
Date Wed, 12 Sep 2007 16:45:05 GMT
+1

On Sep 11, 2007, at 6: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