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