David,
I will ensure this gets followed up by Ken. CCing the PMC.
Regards,
John
David Jencks wrote:
>
> On Jul 4, 2006, at 4:54 PM, John Sisson wrote:
>
>> Matt Hogstrom wrote:
>>> I do not believe the +1's need to be from PMC members but other
>>> committers. This is a snippet from Ken's personal web page:
>>>
>>> "Consequently, acting ex officio my VP/chair of Apache Geronimo
>>> role, yesterday (Sunday, 21 May 2006) I changed the project's
>>> development model from CTR (Commit-Then-Review) to RTC
>>> (Review-Then-Commit). This means that all code changes that aren't
>>> to documentation or specific bug fixes must be proposed to the
>>> development list as patches, and three *[other] committers* need to
>>> verify them and vote in favour of them before they can be applied to
>>> the code in the repository. (This doesn't apply to the sandboxes and
>>> experimental areas, only the main lines and branches of development.)"
>>>
>>> In Ken's original e-mail the vote required three other committers
>>> and not specifically PMC members. Here is the original e-mail.
>>>
>>> http://mail-archives.apache.org/mod_mbox/geronimo-dev/200605.mbox/%3c4470FE4D.1090806@Golux.Com%3e
>>>
>>>
>>> It is my understanding that the an RTC request needs 3 other
>>> committers to +1 it and does not require the other +1's to be PMC
>>> members.
>>>
>> I understand that there has been confusion due to the original
>> message from Ken mentioning committers in his original message, but
>> Ken cleared this up in a message on the 18th of June (since his blog
>> entry on the 22nd May).
>>
>> Please see
>> http://www.mail-archive.com/dev@geronimo.apache.org/msg24899.html
>>
>> Nobody should assume anything has changed from requiring 3 binding
>> votes for RTC until they hear otherwise from Ken.
>
> I do not think that Ken is providing sufficient communication to the
> dev list. As matt pointed out, the original edict to the dev list and
> ken's blog entry clearly and unequivocally stated that committer votes
> were binding for commit decisions. Sometime later ken appears to have
> commmented on this policy with an interpretation that is radically
> different from the original very clear statement with an comment deep
> in a thread. Personally I find that rather ambiguous. I think that
> if Ken has any interest in having clear rules that he has an
> obligation to clearly state changes to them either in the thread in
> which the rules are originally promulgated or in a separate thread but
> in any case clearly indicating what has changed.
>
> Not to insult any pmc members, but it appears that this is an issue on
> which the PMC has absolutely no input. As such, it is difficult for
> me to trust comments on this issue from anyone other than Ken.
>
> thanks
> david jencks
>
>>
>> I encourage those not on the PMC to also vote on RTC requests as your
>> input is valuable.
>>
>> John
>>> Hiram Chirino wrote:
>>>> Whoa!
>>>>
>>>> I think we have been operation under a different assumption. I know I
>>>> committed a patch when 1 got 3 committer +1s... And not even 1 PMC
>>>> member
>>>> looked at it. And that took over a week to garner enough votes.
>>>> Imagine
>>>> how long it would take if we had to get 3 PMC +1! I think we need
>>>> to clear
>>>> this up ASAP!
>>>>
>>>> On 7/1/06, John Sisson <jrsisson@gmail.com> 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
>>>>> >>
>>>>> >>
>>>>> >
>>>>> >
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
>