geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino" <hi...@hiramchirino.com>
Subject Re: Need clarification on RTC... Yet again... was: [Proposal] Tracking the status of patches under RTC
Date Tue, 04 Jul 2006 16:44:16 GMT
whew... thanks for clearing that up Matt!

On 7/4/06, Matt Hogstrom <matt@hogstrom.org> 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.
>
> 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
> >> >>
> >> >>
> >> >
> >> >
> >>
> >>
> >
> >
>



-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Mime
View raw message