Thanks to everyone for casting your votes.
The vote passes with nineteen +1 votes (11 from PPMC
members), one +0.5 vote, one 0 vote, and one -0.5 vote (all
from PPMC members). The votes were:
-------------------------------------------------------
+1 Zsolt Kuti
+1 Jerome Bernard
+1 Sean Landis
+1 Jim Waldo*
+1 Dan Creswell*
+1 Vinod Johnson*
+1 Frank Barnaby*
+1 Greg Trasuk
+1 Nigel Daley*
+1 Jukka Zitting*
+1 Mike Morris
+1 Bill Venners*
+1 Jim Hurley*
+1 Jools Enticknap
+1 Calum Shaw-Mackay
+1 Juan Ramirez*
+1 Gregg Wonderly
+1 Peter Jones*
+1 John McClain*
+0.5 Bob Scheifler*
0 Ron Mann*
-0.5 Mark Brouwer*
* - binding vote from PPMC member
-------------------------------------------------------
There were a bunch of positive comments associated with the
votes, but I also wanted to log the requests and concerns that
were also voiced as part of some of the votes:
-- Sean: I encourage commiters to go beyond the requirements
regarding unit tests
-- Mark: I agree with all process guidelines except for CTR related
to non-public API changes, I have good hopes though I will be
proven wrong ...
-- Ron: I share Mark's sentiment [above], although perhaps I'm a tad
more optimistic.
-- Nigel:This is fine as a starting point for incubation. I hope our
testing
requirements and review requirements tighten up over time.
-- Gregg:This will be a good start. I do think that some RTC
considerations
will be made over time and I really do think that there will be
ample
review with CTR because of those involved for most things.
-- PeterJ: I do share some of the concerns expressed by others but
would like to see things move forward and agree that this is a good
starting point.
thanks -Jim
On Sep 11, 2007, at 9:39 AM, Jim Hurley 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.
----------------------------------------------------------------------
---------------
