You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Hiram Chirino <hi...@hiramchirino.com> on 2006/07/02 06:51:31 UTC
Need clarification on RTC... Yet again... was: [Proposal] Tracking the status of patches under RTC
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 <jr...@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
Re: Need clarification on RTC... Yet again... was: [Proposal] Tracking the status of patches under RTC
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 7/2/06, Aaron Mulder <am...@alumni.princeton.edu> wrote:
> If the PMC interpretation stands, does that mean the only privileges
> of a committer who's not on the PMC are to commit bug fixes?
Yes. That's why I and other think it's so painful and *may* slow down
development, but at the same increase mailing list communication thus
increase overall understanding of Geronimo.
> Aaron
Jacek
--
Jacek Laskowski
http://www.laskowski.net.pl
Re: Need clarification on RTC... Yet again... was: [Proposal] Tracking the status of patches under RTC
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
If the PMC interpretation stands, does that mean the only privileges
of a committer who's not on the PMC are to commit bug fixes?
Thanks,
Aaron
On 7/2/06, Hiram Chirino <hi...@hiramchirino.com> 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 <jr...@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
Re: Need clarification on RTC... Yet again... was: [Proposal] Tracking the status of patches under RTC
Posted by Hiram Chirino <hi...@hiramchirino.com>.
whew... thanks for clearing that up Matt!
On 7/4/06, Matt Hogstrom <ma...@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 <jr...@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
Re: Need clarification on RTC... Yet again... was: [Proposal] Tracking
the status of patches under RTC
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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.
I was mistaken. See http://www.apache.org/foundation/glossary#Vote
If all committers are on the PMC, the distinction vanishes -- but
we do not have that situation.
I apologise for the confusion.
- --
#ken P-|}
Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/
Author, developer, opinionist http://Apache-Server.Com/
"Millennium hand and shrimp!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQCVAwUBRKvwmprNPMCpn3XdAQKPBAP/f9gq3fnJ/mL1mKC0yUwm84z4RDUa2Ts4
C/a8Kgc25BiIS6YNCCvAPYN1e0WDMpCtNEa6m7sgeel9xytjYm9ZKFaVZ+P4nMts
FTcgdR8quFv7TZpMfCd/hbOPUujRF8/aHlr8sqJI0/wGA2lgJHdooo6tx3H/8ROC
TLFdg1lQns8=
=f5Hn
-----END PGP SIGNATURE-----
Re: Need clarification on RTC... Yet again... was: [Proposal] Tracking
the status of patches under RTC
Posted by John Sisson <jr...@gmail.com>.
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 <jr...@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
>>>>> >>
>>>>> >>
>>>>> >
>>>>> >
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
>
Re: Need clarification on RTC... Yet again... was: [Proposal] Tracking the status of patches under RTC
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 7/5/06, David Jencks <da...@yahoo.com> wrote:
> 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.
I couldn't have expressed it clearer! That's how it turned out to me
as well, so I'll await Ken's comment/explanation on it. Thanks Dave
for such a clear statement. It's sad, but the more we talk about it
the more visible it is to me. Having said/read this, I should no
longer be connected to the actions wrt RTC, ok? (uff, much much better
now! Thanks Dave).
> david jencks
Jacek
--
Jacek Laskowski
http://www.laskowski.net.pl
Re: Need clarification on RTC... Yet again... was: [Proposal] Tracking the status of patches under RTC
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 7/5/06, Rodent of Unusual Size <Ke...@golux.com> wrote:
> David Jencks wrote:
> > 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.
>
> Appropriately so. I failed to explain the reason for the
> change. I apologise.
>
> > Not to insult any pmc members, but it appears that this is an issue
> > on which the PMC has absolutely no input.
>
> Not correct.
>
> > As such, it is difficult
> > for me to trust comments on this issue from anyone other than Ken.
>
> Trust, or consider authoritative?
Thanks Ken for coming over - we all missed you much! ;-)
> #ken P-|}
Jacek
--
Jacek Laskowski
http://www.laskowski.net.pl
Re: Need clarification on RTC... Yet again... was: [Proposal] Tracking
the status of patches under RTC
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
David Jencks wrote:
>
> 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.
As I just mentioned in another reply, I was mistaken.
See http://www.apache.org/foundation/glossary#Vote
> 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.
Appropriately so. I failed to explain the reason for the
change. I apologise.
> Not to insult any pmc members, but it appears that this is an issue
> on which the PMC has absolutely no input.
Not correct.
> As such, it is difficult
> for me to trust comments on this issue from anyone other than Ken.
Trust, or consider authoritative?
- --
#ken P-|}
Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/
Author, developer, opinionist http://Apache-Server.Com/
"Millennium hand and shrimp!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQCVAwUBRKvxpJrNPMCpn3XdAQIebQQAw7VDI+nrjo3+pevHC03I7Oj8GnsifTDd
2OzEulM1M/7Y9tdDw+TBaV5QMgFd1pt2U+p2zFZBPs7wOn4kl6bAc+WVSX765mil
uRKr56I58ewGrsqCv/SpTbpNexzFRHewsR8cx7jus3ByjC5Bc13sHwHiLEhLTsA6
8BhX7UEtIVA=
=qA23
-----END PGP SIGNATURE-----
Re: Need clarification on RTC... Yet again... was: [Proposal] Tracking the status of patches under RTC
Posted by David Jencks <da...@yahoo.com>.
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 <jr...@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
>>>> >>
>>>> >>
>>>> >
>>>> >
>>>>
>>>>
>>>
>>>
>>
>
Re: Need clarification on RTC... Yet again... was: [Proposal] Tracking
the status of patches under RTC
Posted by John Sisson <jr...@gmail.com>.
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 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 <jr...@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
>>> >>
>>> >>
>>> >
>>> >
>>>
>>>
>>
>>
>
Re: Need clarification on RTC... Yet again... was: [Proposal] Tracking
the status of patches under RTC
Posted by Matt Hogstrom <ma...@hogstrom.org>.
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 <jr...@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
>> >>
>> >>
>> >
>> >
>>
>>
>
>
Re: Need clarification on RTC... Yet again... was: [Proposal] Tracking the status of patches under RTC
Posted by David Blevins <da...@visi.com>.
On Jul 2, 2006, at 12:43 AM, Jacek Laskowski wrote:
> On 7/2/06, Hiram Chirino <hi...@hiramchirino.com> 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!
>
> It's been cleared up for some time, imho. We can do two things to work
> it out in a gentle manner:
>
> 1/ Be more active and describe the change so that not only are
> developers encouraged to test it out or even PMCers. Why is it that
> only committers and PMCers vote? Is the description of the change not
> easy to understand enough? I wonder what makes them unattractive for
> lurkers?
>
> 2/ Be more active and gain a PMC nomination so the number of PMCers
> increases.
>
3/ Be more active if you are a PMC member.
And, yes, I agree with all three and also concur that as everyone has
limited bandwidth to dedicate to all three. You're right, we
shouldn't just do what is easiest for us.
-David
> They seem to be obvious things, but in RTC mode we operate nothing's
> as obvious as it was. We all learn RTC and with no other projects
> operating in RTC we're pioneers. With a limited bandwidth I've got I'm
> quite certain I'll work on patches that are easy to grasp and have
> extensive documentation behind them. Of course, the more talk about it
> in the dev mailing list the better as it will spur my interest in
> testing.
>
> Jacek
>
> --
> Jacek Laskowski
> http://www.laskowski.net.pl
>
Re: Need clarification on RTC... Yet again... was: [Proposal] Tracking
the status of patches under RTC
Posted by Rick McGuire <ri...@gmail.com>.
Jacek Laskowski wrote:
> On 7/2/06, Hiram Chirino <hi...@hiramchirino.com> 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!
>
> It's been cleared up for some time, imho. We can do two things to work
> it out in a gentle manner:
I disagree that it has been cleared up for some time. The fact that
only PMC members votes count is certainly new news to me. I've already
committed one back of changes improperly, based on receiving 4 +1 votes
that apparantly don't count. I've got 2 more [RTC] reviews pending
where 2 people have taken the time to test and vote on my patches, only
to now discover that their votes don't count, so they were essentially
wasting their time. These patches have been sitting in [RTC] for 10
days now, I've only seen activity from 1 PMC member so far at looking at
these.
>
> 1/ Be more active and describe the change so that not only are
> developers encouraged to test it out or even PMCers. Why is it that
> only committers and PMCers vote? Is the description of the change not
> easy to understand enough? I wonder what makes them unattractive for
> lurkers?
>
> 2/ Be more active and gain a PMC nomination so the number of PMCers
> increases.
And that sounds like a path to do nothing but spending your time testing
and voting on others patches, and not getting to spend any time working
on stuff that interests you.
>
> They seem to be obvious things, but in RTC mode we operate nothing's
> as obvious as it was. We all learn RTC and with no other projects
> operating in RTC we're pioneers. With a limited bandwidth I've got I'm
> quite certain I'll work on patches that are easy to grasp and have
> extensive documentation behind them. Of course, the more talk about it
> in the dev mailing list the better as it will spur my interest in
> testing.
>
> Jacek
>
Re: Need clarification on RTC... Yet again... was: [Proposal] Tracking the status of patches under RTC
Posted by Jason Dillon <ja...@planet57.com>.
> Sadly, I think RTC is shifting Geronimo from being a meritocracy to
> being a bureaucracy.
I completely agree with this statement.
> And only things get done if you have friends in the PMC. I've seen
> several folks say RTC "Has been as success", and while yes, it has
> increased communicatio, If you look back and try to compare what's
> been committed to SVN against what has passed in RTC with 3 PMC
> votes I'm sure you'll be hard pressed to find alot of examples of
> "success".
And this too.
> I think RTC would be fine IF current implementation were slightly
> tweaked to only require: 3 1+ from committers saying, yeah I think
> that patch is a good idea. Notice the requirement for testing the
> patch is gone. The requirement or PMC member is gone. This would
> still generate all the discussion that we are seeing on the lists,
> but now you at least have CHANCE of moving forward with a change.
And I completely agree with this too.
--jason
Re: Need clarification on RTC... Yet again... was: [Proposal] Tracking the status of patches under RTC
Posted by Hiram Chirino <hi...@hiramchirino.com>.
Hi Jacek,
On 7/2/06, Jacek Laskowski <ja...@laskowski.net.pl> wrote:
>
> On 7/2/06, Hiram Chirino <hi...@hiramchirino.com> 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!
>
> It's been cleared up for some time, imho. We can do two things to work
> it out in a gentle manner:
>
> 1/ Be more active and describe the change so that not only are
> developers encouraged to test it out or even PMCers. Why is it that
> only committers and PMCers vote? Is the description of the change not
> easy to understand enough? I wonder what makes them unattractive for
> lurkers?
If you want to review the mail thread that I started a while back, you'll
see that it was a simple migration of code from ActiveMQ to Geronimo. I
posted multiple times to garner support. Sadly, I think RTC is shifting
Geronimo from being a meritocracy to being a bureaucracy. And only things
get done if you have friends in the PMC. I've seen several folks say RTC
"Has been as success", and while yes, it has increased communicatio, If you
look back and try to compare what's been committed to SVN against what has
passed in RTC with 3 PMC votes I'm sure you'll be hard pressed to find alot
of examples of "success".
2/ Be more active and gain a PMC nomination so the number of PMCers
> increases.
>
> They seem to be obvious things, but in RTC mode we operate nothing's
> as obvious as it was. We all learn RTC and with no other projects
Since I previously was on the PMC due to starting Geronimo and actively work
on it and getting it past the CTS testing, excuse me if I think I have all
ready have shown this project that I'm a responsible community member.
Unfortunately, I don't have 8 hours a day to devote to Geronimo anymore but
I don't think that should be held against any PMCer.
operating in RTC we're pioneers. With a limited bandwidth I've got I'm
> quite certain I'll work on patches that are easy to grasp and have
> extensive documentation behind them. Of course, the more talk about it
> in the dev mailing list the better as it will spur my interest in
> testing.
I know you would never think something like this, but I could see how
"spurring interest" could rapidly degenerate to hiring 3 PMC folks on
consulting time.
I think RTC would be fine IF current implementation were slightly tweaked to
only require: 3 1+ from committers saying, yeah I think that patch is a good
idea. Notice the requirement for testing the patch is gone. The requirement
or PMC member is gone. This would still generate all the discussion that we
are seeing on the lists, but now you at least have CHANCE of moving forward
with a change.
Jacek
>
> --
> Jacek Laskowski
> http://www.laskowski.net.pl
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Re: Need clarification on RTC... Yet again... was: [Proposal] Tracking
the status of patches under RTC
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Jacek Laskowski wrote:
> 1/ Be more active and describe the change so that not only are
> developers encouraged to test it out or even PMCers. Why is it that
> only committers and PMCers vote? Is the description of the change not
> easy to understand enough? I wonder what makes them unattractive for
> lurkers?
This is an interesting question that I've been mulling over for some
time. I think that it's due, in no small part, to the tradition of
tallying what votes are binding and what votes are not. Some projects
don't even bother to tally non-binding votes.
I, myself, use to vote on a few projects and got discouraged when my
vote was publicly tallied as "not mattering"; I now don't bother.
During my short tenor of a few years here at ASF as a committer and PMC
member of many projects, I have never seen a vote tallied where it was
necessary to point out the votes that "mattered". This was due to the
fact that a consensus was usually formed by discussion before the vote
took place. I think that as a rule, we shouldn't bother to delineate
voting classes unless it was necessary to break an impasse.
Regards,
Alan
Re: Need clarification on RTC... Yet again... was: [Proposal] Tracking the status of patches under RTC
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 7/2/06, Hiram Chirino <hi...@hiramchirino.com> 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!
It's been cleared up for some time, imho. We can do two things to work
it out in a gentle manner:
1/ Be more active and describe the change so that not only are
developers encouraged to test it out or even PMCers. Why is it that
only committers and PMCers vote? Is the description of the change not
easy to understand enough? I wonder what makes them unattractive for
lurkers?
2/ Be more active and gain a PMC nomination so the number of PMCers increases.
They seem to be obvious things, but in RTC mode we operate nothing's
as obvious as it was. We all learn RTC and with no other projects
operating in RTC we're pioneers. With a limited bandwidth I've got I'm
quite certain I'll work on patches that are easy to grasp and have
extensive documentation behind them. Of course, the more talk about it
in the dev mailing list the better as it will spur my interest in
testing.
Jacek
--
Jacek Laskowski
http://www.laskowski.net.pl