geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Sisson <jrsis...@gmail.com>
Subject Re: Need clarification on RTC... Yet again... was: [Proposal] Tracking the status of patches under RTC
Date Wed, 05 Jul 2006 00:47:14 GMT
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
>>>>> >>
>>>>> >>
>>>>> >
>>>>> >
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
>


Mime
View raw message