+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.
----------------------------------------------------------------------
---------------
