Re: [PROPOSAL] Modified RTC
Matt Hogstrom wrote: *** Begin Proposal *** * Any -1 votes need to be accompanied by a reason and a mutually agreed upon solution to the issue raised. I'm not sure how the "and a mutually agreed upon solution to the issue raised" would work. I agree a -1 should be accompanied by a reason, but I would imagine that it could take some time for a solution to be determined and possibly longer to get mutual agreement on it. I don't think it should be be the responsibility of the person who raises the -1's to come up with a solution? For example, you test my change and find that it breaks the server, should you really be expected to debug it and come up with a solution before you can vote? I would have thought that would be responsibility of the author of the change with the help of the community. Suggesting that a solution needs to be determined and agreed upon before one can raise the -1, that seems overly restrictive to me, but maybe I'm misinterpreting your thinking. Please provide your input for this proposal. I'd like to bring this to the community for a vote this week. I agree with Kevan's later comment in this thread that we should put a summary of the three different options up for discussion and then for a vote. Regards, John
Re: [PROPOSAL] Modified RTC
I think we are going to need a voting matrix for this issue! lol. I'd like see CTR on trunk / Active Branches and, Relaxed RTC on Maintance branches. On 9/6/06, Rodent of Unusual Size <[EMAIL PROTECTED]> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matt Hogstrom wrote: > > *** Begin Proposal *** > > Geronimo Development Process > > Geronimo follows a model similar to Review Then Commit (RTC). Trunk, active branches, maintenance branches, and all? Or how would you refine it across those? - -- #kenP-)} 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 iQCVAwUBRP81bprNPMCpn3XdAQKDcwP8Cfqk7bh1xwF63/vgr5f7eyHj8LAHrp+X FGlBmOE9oJ+YqoYUGqzoGpHdKPppGQKjuyy7mvR/F2L5pNBUk2mg0Uv0bLkUa8x0 N5yNbEJS66BzjZzPK9ZId4a462jhVcCZqSrDWQRiboUqSk8p7x0lRxMA+0slntUK GrkBhlCExl0= =6iRu -END PGP SIGNATURE- -- Regards, Hiram Blog: http://hiramchirino.com
Re: [PROPOSAL] Modified RTC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matt Hogstrom wrote: > > *** Begin Proposal *** > > Geronimo Development Process > > Geronimo follows a model similar to Review Then Commit (RTC). Trunk, active branches, maintenance branches, and all? Or how would you refine it across those? - -- #kenP-)} 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 iQCVAwUBRP81bprNPMCpn3XdAQKDcwP8Cfqk7bh1xwF63/vgr5f7eyHj8LAHrp+X FGlBmOE9oJ+YqoYUGqzoGpHdKPppGQKjuyy7mvR/F2L5pNBUk2mg0Uv0bLkUa8x0 N5yNbEJS66BzjZzPK9ZId4a462jhVcCZqSrDWQRiboUqSk8p7x0lRxMA+0slntUK GrkBhlCExl0= =6iRu -END PGP SIGNATURE-
Re: [PROPOSAL] Modified RTC
I think Kevan was going to summarize the proposals and I believe that was one of them :) Paul McMahan wrote: My opinion on this matter may be a bit extreme but I still probably qualify as an upstart whippersnapper so I can happily enjoy that luxury. I understand why the project needed to switch over to RTC and am impressed by how positively the community has responded. David Blevins' excellent "patches ready for RTC" automated emails are just one example of how this team has responded in a positive and productive way to embrace a difficult change. That being said I think the goal of switching to RTC was to serve as a kick-start for more healthy and pervasive communication, and not to institute a permanent system of checks and balances. IMHO the inevitable follow-on discussion of switching to RTC has played out in productive manner and the necessary synapses are now in place. So I'm hoping that if this thread culminates into an official vote that there's an option for switching back to "classic" Apache CTR without any additional checks and balances. Maybe that's closest to what Kevan proposes in option 1 below(?) Best wishes, Paul On 9/6/06, Kevan Miller <[EMAIL PROTECTED]> wrote: Matt. Agreed that it's time to push this issue to a conclusion. There seemed to be two schools of thought in the "Returning to Commit- Then-Review" thread: 1) CTR with guidelines for documenting new function to the community, and 2) RTC with lazy consensus. The proposal you describe below is a third option (RTC with relaxed review and PMC vote requirements). Which is fine, but I think it's a new/different proposal. I assume this was your intention. I propose we summarize these 3 options and put them to a vote. If we feel that is fragmenting the vote, then we vote on CTR vs. RTC, then refine the specific process. Comments? --kevan On Sep 6, 2006, at 1:50 AM, Matt Hogstrom wrote: > *** Begin Proposal *** > > Geronimo Development Process > > Geronimo follows a model similar to Review Then Commit (RTC). > Patches for new function are provided by developers for review and > comment by their peers. Feedback is conducted through JIRA > comments. The goal of this interaction is to solicit suggestions > from the community and incorporate their feedback as appropriate. > In order for a patch to be accepted it requires the following: > > * Needs to be reviewed by committers on the project. Others may > comment but their comments are not binding. The review may, but > does not have to, include application and testing. The goal of the > review is to understand the technical attributes of the change as > well as the assess other impacts to the project as a whole. > > * 3 +1 votes from committers on the project (1 of these committers > needs to be a member of the PMC) with no outstanding -1 votes. > > * Any -1 votes need to be accompanied by a reason and a mutually > agreed upon solution to the issue raised. > > * If the issues can't be resolved then the PMC can be called upon > to settle the dispute and make a recommendation. > > * Issues are generally of a technical nature. However, issues may > include other items like usability, project cohesiveness or other > issues that impact the project as a whole. > > The goal of these guidelines is to facilitate timely communication > as well as the fostering of ideas and collaboration as well as > innovation. > > *** End Proposal ***
Re: [PROPOSAL] Modified RTC
My opinion on this matter may be a bit extreme but I still probably qualify as an upstart whippersnapper so I can happily enjoy that luxury. I understand why the project needed to switch over to RTC and am impressed by how positively the community has responded. David Blevins' excellent "patches ready for RTC" automated emails are just one example of how this team has responded in a positive and productive way to embrace a difficult change. That being said I think the goal of switching to RTC was to serve as a kick-start for more healthy and pervasive communication, and not to institute a permanent system of checks and balances. IMHO the inevitable follow-on discussion of switching to RTC has played out in productive manner and the necessary synapses are now in place. So I'm hoping that if this thread culminates into an official vote that there's an option for switching back to "classic" Apache CTR without any additional checks and balances. Maybe that's closest to what Kevan proposes in option 1 below(?) Best wishes, Paul On 9/6/06, Kevan Miller <[EMAIL PROTECTED]> wrote: Matt. Agreed that it's time to push this issue to a conclusion. There seemed to be two schools of thought in the "Returning to Commit- Then-Review" thread: 1) CTR with guidelines for documenting new function to the community, and 2) RTC with lazy consensus. The proposal you describe below is a third option (RTC with relaxed review and PMC vote requirements). Which is fine, but I think it's a new/different proposal. I assume this was your intention. I propose we summarize these 3 options and put them to a vote. If we feel that is fragmenting the vote, then we vote on CTR vs. RTC, then refine the specific process. Comments? --kevan On Sep 6, 2006, at 1:50 AM, Matt Hogstrom wrote: > *** Begin Proposal *** > > Geronimo Development Process > > Geronimo follows a model similar to Review Then Commit (RTC). > Patches for new function are provided by developers for review and > comment by their peers. Feedback is conducted through JIRA > comments. The goal of this interaction is to solicit suggestions > from the community and incorporate their feedback as appropriate. > In order for a patch to be accepted it requires the following: > > * Needs to be reviewed by committers on the project. Others may > comment but their comments are not binding. The review may, but > does not have to, include application and testing. The goal of the > review is to understand the technical attributes of the change as > well as the assess other impacts to the project as a whole. > > * 3 +1 votes from committers on the project (1 of these committers > needs to be a member of the PMC) with no outstanding -1 votes. > > * Any -1 votes need to be accompanied by a reason and a mutually > agreed upon solution to the issue raised. > > * If the issues can't be resolved then the PMC can be called upon > to settle the dispute and make a recommendation. > > * Issues are generally of a technical nature. However, issues may > include other items like usability, project cohesiveness or other > issues that impact the project as a whole. > > The goal of these guidelines is to facilitate timely communication > as well as the fostering of ideas and collaboration as well as > innovation. > > *** End Proposal ***
Re: [PROPOSAL] Modified RTC
Matt, I liked this "relaxed RTC" proposal. However, would you be willing to consider one slight change to it. Could you please propose a timelimit before which the patch gets the required +1 or atleast one -1 vote ? After the set time, if there isn't any single "nay" vote, the patch becomes ready for commit with a lazy consensus. One thing that arose some confusion in the past was whether the committer proposing the patch could count his own vote in. This needs to be clarified too. Cheers Prasad On 9/6/06, Joe Bohn <[EMAIL PROTECTED]> wrote: +1 to considering alternatives in addition to relaxed RTC. Joe Kevan Miller wrote: > Matt. > Agreed that it's time to push this issue to a conclusion. > > There seemed to be two schools of thought in the "Returning to Commit- > Then-Review" thread: > > 1) CTR with guidelines for documenting new function to the community, and > 2) RTC with lazy consensus. > > The proposal you describe below is a third option (RTC with relaxed > review and PMC vote requirements). Which is fine, but I think it's a > new/different proposal. I assume this was your intention. > > I propose we summarize these 3 options and put them to a vote. If we > feel that is fragmenting the vote, then we vote on CTR vs. RTC, then > refine the specific process. Comments? > > --kevan > > > On Sep 6, 2006, at 1:50 AM, Matt Hogstrom wrote: > >> *** Begin Proposal *** >> >> Geronimo Development Process >> >> Geronimo follows a model similar to Review Then Commit (RTC). >> Patches for new function are provided by developers for review and >> comment by their peers. Feedback is conducted through JIRA comments. >> The goal of this interaction is to solicit suggestions from the >> community and incorporate their feedback as appropriate. In order >> for a patch to be accepted it requires the following: >> >> * Needs to be reviewed by committers on the project. Others may >> comment but their comments are not binding. The review may, but does >> not have to, include application and testing. The goal of the review >> is to understand the technical attributes of the change as well as >> the assess other impacts to the project as a whole. >> >> * 3 +1 votes from committers on the project (1 of these committers >> needs to be a member of the PMC) with no outstanding -1 votes. >> >> * Any -1 votes need to be accompanied by a reason and a mutually >> agreed upon solution to the issue raised. >> >> * If the issues can't be resolved then the PMC can be called upon to >> settle the dispute and make a recommendation. >> >> * Issues are generally of a technical nature. However, issues may >> include other items like usability, project cohesiveness or other >> issues that impact the project as a whole. >> >> The goal of these guidelines is to facilitate timely communication as >> well as the fostering of ideas and collaboration as well as innovation. >> >> *** End Proposal *** > > > > >
Re: [PROPOSAL] Modified RTC
+1 to considering alternatives in addition to relaxed RTC. Joe Kevan Miller wrote: Matt. Agreed that it's time to push this issue to a conclusion. There seemed to be two schools of thought in the "Returning to Commit- Then-Review" thread: 1) CTR with guidelines for documenting new function to the community, and 2) RTC with lazy consensus. The proposal you describe below is a third option (RTC with relaxed review and PMC vote requirements). Which is fine, but I think it's a new/different proposal. I assume this was your intention. I propose we summarize these 3 options and put them to a vote. If we feel that is fragmenting the vote, then we vote on CTR vs. RTC, then refine the specific process. Comments? --kevan On Sep 6, 2006, at 1:50 AM, Matt Hogstrom wrote: *** Begin Proposal *** Geronimo Development Process Geronimo follows a model similar to Review Then Commit (RTC). Patches for new function are provided by developers for review and comment by their peers. Feedback is conducted through JIRA comments. The goal of this interaction is to solicit suggestions from the community and incorporate their feedback as appropriate. In order for a patch to be accepted it requires the following: * Needs to be reviewed by committers on the project. Others may comment but their comments are not binding. The review may, but does not have to, include application and testing. The goal of the review is to understand the technical attributes of the change as well as the assess other impacts to the project as a whole. * 3 +1 votes from committers on the project (1 of these committers needs to be a member of the PMC) with no outstanding -1 votes. * Any -1 votes need to be accompanied by a reason and a mutually agreed upon solution to the issue raised. * If the issues can't be resolved then the PMC can be called upon to settle the dispute and make a recommendation. * Issues are generally of a technical nature. However, issues may include other items like usability, project cohesiveness or other issues that impact the project as a whole. The goal of these guidelines is to facilitate timely communication as well as the fostering of ideas and collaboration as well as innovation. *** End Proposal ***
Re: [PROPOSAL] Modified RTC
I agree with Kevan. Thanks, Aaron On 9/6/06, Kevan Miller <[EMAIL PROTECTED]> wrote: Matt. Agreed that it's time to push this issue to a conclusion. There seemed to be two schools of thought in the "Returning to Commit- Then-Review" thread: 1) CTR with guidelines for documenting new function to the community, and 2) RTC with lazy consensus. The proposal you describe below is a third option (RTC with relaxed review and PMC vote requirements). Which is fine, but I think it's a new/different proposal. I assume this was your intention. I propose we summarize these 3 options and put them to a vote. If we feel that is fragmenting the vote, then we vote on CTR vs. RTC, then refine the specific process. Comments? --kevan On Sep 6, 2006, at 1:50 AM, Matt Hogstrom wrote: > *** Begin Proposal *** > > Geronimo Development Process > > Geronimo follows a model similar to Review Then Commit (RTC). > Patches for new function are provided by developers for review and > comment by their peers. Feedback is conducted through JIRA > comments. The goal of this interaction is to solicit suggestions > from the community and incorporate their feedback as appropriate. > In order for a patch to be accepted it requires the following: > > * Needs to be reviewed by committers on the project. Others may > comment but their comments are not binding. The review may, but > does not have to, include application and testing. The goal of the > review is to understand the technical attributes of the change as > well as the assess other impacts to the project as a whole. > > * 3 +1 votes from committers on the project (1 of these committers > needs to be a member of the PMC) with no outstanding -1 votes. > > * Any -1 votes need to be accompanied by a reason and a mutually > agreed upon solution to the issue raised. > > * If the issues can't be resolved then the PMC can be called upon > to settle the dispute and make a recommendation. > > * Issues are generally of a technical nature. However, issues may > include other items like usability, project cohesiveness or other > issues that impact the project as a whole. > > The goal of these guidelines is to facilitate timely communication > as well as the fostering of ideas and collaboration as well as > innovation. > > *** End Proposal ***
Re: [PROPOSAL] Modified RTC
Matt. Agreed that it's time to push this issue to a conclusion. There seemed to be two schools of thought in the "Returning to Commit- Then-Review" thread: 1) CTR with guidelines for documenting new function to the community, and 2) RTC with lazy consensus. The proposal you describe below is a third option (RTC with relaxed review and PMC vote requirements). Which is fine, but I think it's a new/different proposal. I assume this was your intention. I propose we summarize these 3 options and put them to a vote. If we feel that is fragmenting the vote, then we vote on CTR vs. RTC, then refine the specific process. Comments? --kevan On Sep 6, 2006, at 1:50 AM, Matt Hogstrom wrote: *** Begin Proposal *** Geronimo Development Process Geronimo follows a model similar to Review Then Commit (RTC). Patches for new function are provided by developers for review and comment by their peers. Feedback is conducted through JIRA comments. The goal of this interaction is to solicit suggestions from the community and incorporate their feedback as appropriate. In order for a patch to be accepted it requires the following: * Needs to be reviewed by committers on the project. Others may comment but their comments are not binding. The review may, but does not have to, include application and testing. The goal of the review is to understand the technical attributes of the change as well as the assess other impacts to the project as a whole. * 3 +1 votes from committers on the project (1 of these committers needs to be a member of the PMC) with no outstanding -1 votes. * Any -1 votes need to be accompanied by a reason and a mutually agreed upon solution to the issue raised. * If the issues can't be resolved then the PMC can be called upon to settle the dispute and make a recommendation. * Issues are generally of a technical nature. However, issues may include other items like usability, project cohesiveness or other issues that impact the project as a whole. The goal of these guidelines is to facilitate timely communication as well as the fostering of ideas and collaboration as well as innovation. *** End Proposal ***
