I tried my best to weave an acceptable path through all the
different options and opinions stated in the thread. It's quite
likely I didn't nail it the first time - so before calling for any vote
on this Proposal, I'd like to discuss any major problems (or need
for clarification) that people see.
Just a comment as well - as has been stated... we don't have to
get it perfect. I'm sure whatever we agree to start with will evolve,
as we gain experience with it, to something that will work best
for us over time. Let's get an acceptable starting place and
move on.
thanks -Jim
------------------------------------------------------------------------
-------------
DRAFT 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.
* 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
Enable a special field in JIRA to mark an issue as a security
issue
and restrict access to the JIRA issue to the PPMC and
committers.
Hold initial discussions on potential security issues on the
private
PPMC list. When acknowledged that it's an valid security issue,
create a JIRA issue with special security field marked.
As soon as appropriate (for example, when the impact is
understood
and/or there is a resolution and fix developed), open the
issue and
discussion to the river-dev list.
------------------------------------------------------------------------
-------------
