+1 (non-binding) On 9/11/07, Jim Hurley <[EMAIL PROTECTED]> 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. > > ------------------------------------------------------------------------ > ------------- > > > > >
-- Jérôme BERNARD, Kalixia, SARL. http://weblog.kalixia.com
