Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Date: Mon, 10 Sep 2007 16:06:36 -0400
From: Jim Hurley <Jim.Hurley@Sun.COM>
Subject: v0.3 Draft Proposal - River basic dev process
Sender: Jim.Hurley@Sun.COM
To: river-dev@incubator.apache.org
Message-id: <955FBDDE-E5A9-4677-84F9-FD674CE8ACBE@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII
Content-transfer-encoding: 7BIT

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.

------------------------------------------------------------------------ 
-------------