Rollo, Dan wrote: > 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>
+1 > 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:[EMAIL PROTECTED] > Sent: Monday, September 10, 2007 4:07 PM > To: [email protected] > 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. > -------------------------------------------------- >
