river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Creswell <...@dcrdev.demon.co.uk>
Subject Re: v0.3 Draft Proposal - River basic dev process
Date Tue, 11 Sep 2007 20:15:05 GMT
Rollo, Dan wrote:
> One suggestion:
> 
> Maybe change:
> 
> * Testing
>        Developing test cases and running test suites are 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.
> 
> To:
> 
> * Testing
>        Developing test cases and running test suites are <desired but>

+1

> 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. 
> 
> 
> Dan (testing zealot) ;)
> 
> -----Original Message-----
> From: Jim Hurley [mailto:Jim.Hurley@Sun.COM] 
> Sent: Monday, September 10, 2007 4:07 PM
> To: river-dev@incubator.apache.org
> Subject: v0.3 Draft Proposal - River basic dev process
> 
> I've updated the Proposal again based on last Friday's input:
> changing the "Issues discussion" section, and the binding votes on
> public API code reviews from PPMC to Committers.
> 
> Ready to move to a vote unless there's concerns/issues raised by
> tomorrow.
> 
> thanks -Jim
> 
> ------------------------------------------------------------------------
> -------------
>     DRAFT PROPOSAL  (v0.3)
> ------------------------------------------------------------------------
> -------------
>                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 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.
> 
> ------------------------------------------------------------------------
> -------------
> 
> 
> 
> --------------------------------------------------
> This e-mail and any files transmitted with it may contain privileged or confidential
information.
> It is solely for use by the individual for whom it is intended, even if addressed incorrectly.
> If you received this e-mail in error, please notify the sender; do not disclose, copy,
distribute,
> or take any action in reliance on the contents of this information; and delete it from
> your system. Any other use of this e-mail is prohibited.
> 
> Thank you for your compliance.
> --------------------------------------------------
> 


Mime
View raw message