I've made some mods to the "Tracking issues and changes" and
"Handling security -related issues" sections.
Anxious to hear other feedback, especially opinions on the
"Issues discussions" and "Code Reviews" sections, where
MarkB had issues with the proposal.
thanks -Jim
------------------------------------------------------------------------
-------------
DRAFT PROPOSAL (v0.2)
------------------------------------------------------------------------
-------------
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
Discussion on issues should occur via the Comments facility
in JIRA. This copies the river-dev list for the entire River dev
community to see. River-dev email thread discussions on an
issue are not prohibited (but not preferred), and if they occur
than a summary must be posted back on 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 effect the API docs
('specs'),
everyone within the Jini/River community is encouraged
to review
and vote. The PPMC member 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.
------------------------------------------------------------------------
-------------
