river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rollo, Dan" <DRo...@ETS.ORG>
Subject RE: v0.3 Draft Proposal - River basic dev process
Date Mon, 10 Sep 2007 21:02:06 GMT
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>
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