river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jérôme BERNARD" <jerome.bern...@gmail.com>
Subject Re: [Vote] - River basic dev process
Date Tue, 11 Sep 2007 14:52:24 GMT
+1 (non-binding)

On 9/11/07, Jim Hurley <Jim.Hurley@sun.com> 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.
>
> ------------------------------------------------------------------------
> -------------
>
>
>
>
>


-- 
Jérôme BERNARD,
Kalixia, SARL.
http://weblog.kalixia.com

Mime
View raw message