Please read Ken's original email:
http://mail-archives.apache.org/mod_mbox/geronimo-dev/200605.mbox/[EMAIL
PROTECTED]
As far as not considering commiters votes binding, this has never been
the way Geronimo was run. If things have changed and the PMC has
decided that this is the new way to go, ok. But let there be no
confusion as to the way things used to work.
Please confirm that this is the new way that the PMC has decided to run
things.
Regards,
Alan
John Sisson wrote:
AFAIK, it has never changed from having three binding +1 votes from
the PMC, which is why there is an issue with a bottleneck processing
RTCs due to the size of the PMC.
It may not have been clearly communicated that that is how RTC works.
See Ken's comment in
http://www.mail-archive.com/dev%40geronimo.apache.org/msg24899.html
Also see http://www.apache.org/foundation/voting.html where it says
"Only votes by PMC members are considered binding on code-modification
issues".
Made change below...
John
Alan D. Cabrera wrote:
I don't understand how things changed from an RTC needing three +1
votes from other committers to three +1 votes from a PMC member. Did
I miss an email that got sent out from the PMC?
Regards,
Alan
John Sisson wrote:
One of the issues I see with the current process we have for changes
under RTC is that it is hard to keep track of what patches are
pending RTC.
Ken suggested that we reintroduce the STATUS file as a way of
keeping track of the status of patches (
http://www.mail-archive.com/dev%40geronimo.apache.org/msg24780.html ).
On the same thread, Dain suggested introducing a "review-required"
status in JIRA (
http://www.mail-archive.com/dev%40geronimo.apache.org/msg25122.html
) and is the method of tracking work that I prefer.
PROPOSAL
1. Add a "review-required" and "review-complete" statuses to JIRA. I
thought having two statuses might allow a cleaner workflow in JIRA,
but would be interested in hearing others opinions.
2. To make it easy for those reviewing and voting on the patches
(there could end up being a number of revisions of the patch before
it is accepted) the file names of the patches attached to the JIRA
should be prefixed with the JIRA issue identifier followed by an
optional text followed by a mandatory patch version number (starting
at 1).
Example patch names:
GERONIMO-1234-FixNPE-v1
GERONIMO-1234-FixNPE-v2 (second attempt at patch)
GERONIMO-3421-v1
2.1 This status should only be set by a committer (can we can get
JIRA to enforce this?) when they have tested the patch attached to
the JIRA and believe it is ready for review. 2.2 The JIRA should
contain all information about the patch. If the changes were
previously discussed on the dev list prior to the JIRA being
created, a summary of the discussions should be moved into the JIRA
so that those reviewing the patch have all the information in one
place. It would also be preferable to add links to the original
discussions on the dev list archives. The way we document changes
may be subject to change (e.g. detailed documentation placed in a
linked JIRA) based upon the outcome of the discussions in the thread
"[DISCUSS] Tracking documentation tasks in JIRA ( was Re: [RTC]
Clarification please from the PMC )"
2.3 Each PMC member who reviews the patch attached to the JIRA must
do the following:
* Add a JIRA comment containing the file name of the patch they
reviewed. This is so there is no confusion if there ends up being
multiple revisions of the patch when collating votes.
* In the JIRA comment add the results of their review (e.g.
comments or a vote). If a PMC member vetos the patch, they must
include a technical justification in their JIRA comments. I propose
that when there is a veto that we leave the status as
"review-required", as others may still want to vote and so that the
patch remains getting daily visibility in the "JIRAs Pending Review"
daily email (proposed below). The committer can then re-submit
another patch (where the patch filename has the version number
bumped up)
A committer could veto, but it wouldn't be binding, so the above
paragraph should probably be changed to:
* In the JIRA comment add the results of their review (e.g. comments
or a vote). If a committer vetos the patch (note that only PMC votes
are binding), they must include a technical justification in their
JIRA comments. I propose that when there is a veto that we leave the
status as "review-required", as others may still want to vote and so
that the patch remains getting daily visibility in the "JIRAs Pending
Review" daily email (proposed below). The committer can then
re-submit another patch (where the patch filename has the version
number bumped up)
* If a PMC member is the person who completes the vote ( three
binding +1s and no vetos) for the latest version of the patch then
they should change the status to "review-complete".
3. Non-committers who submit patches will not be able to set this
status. A committer needs to pick up their patch and test it
(possibly making changes to the patch). When the patch is ready the
committer then sets the "review-required" status.
4. Have a daily email automatically sent to the dev list containing
JIRA's pending review. It appears this should be easy to implement
as it would be a variation of the weekly "Unassigned Patches"
reports that are currently in place.
I would be interested in your comments Jason, as you are more
familiar with customizing JIRA.
If this proposal is accepted I will document it as part of the work
I plan to do to document the use of JIRA in
http://issues.apache.org/jira/browse/GERONIMO-2080 .
John
