Re: Returning to Commit-Then-Review?
+1 * I would recommend that folks continue to submit patches for review. * Perhaps we should keep RTC enabled on maintenance branches. This would help stabilize those branches quicker. On 8/22/06, Rodent of Unusual Size <[EMAIL PROTECTED]> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Apache Geronimo has been operating mostly under the Review-Then-Commit model for a couple of months now, and I think the issues the change was intended to highlight have been .. well, highlighted. How do people feel about the idea of switching back to Commit-Then-Review at this point? - -- #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 iQCVAwUBROuM8prNPMCpn3XdAQJasgP6AmIwS/d8cS12D6ClRmeWAdbtkQIPFVsY QvGXkS6/LhrNNKnA+vsKdOOE/dsPa9MaxlhBNqG4qN8Wz+gQMIj6zD5h+u20GG6W LBmDilEYctBZtjTZ+WovEfweQbiAX4aRjWi/mClQzAvKIdMEAph4UmwYQy/F5FG0 anL4nJoStVw= =XJ1j -END PGP SIGNATURE- -- Regards, Hiram Blog: http://hiramchirino.com
Re: Re: Returning to Commit-Then-Review?
On 9/6/06, Jason Dillon <[EMAIL PROTECTED]> wrote: I will support anything that does not leave patches to fester and still provides any required pre-commit oversight. I would really like to see a CTR-like policy that puts trust back into the community for example, I trust Hirams activemq patch but my concurrent patch... well I want others to ack it first, as it his areas of the server which are not as familiar to me. It seems to me that David's proposal fits into this... Can we please make an effort to agree on a policy? And once agreed upon, have the PMC officially announce it? I believe this is critical for our community to move forward. Thanks Jason for bringing it up. I started a page http://cwiki.apache.org/confluence/pages/viewpage.action?pageId=23530 to let us know where we are. Nothing there yet, but let us^H^Hme get started. Will copy emails from Dave and others there. It's accessible from http://cwiki.apache.org/confluence/display/GMOxPMGT/Documentation, but it doesn't look good. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Returning to Commit-Then-Review?
+1On 8/25/06, David Blevins <[EMAIL PROTECTED]> wrote: So anyone have any thoughts on this? I'll assume there's no supportunless I hear otherwise.-DavidOn Aug 23, 2006, at 1:14 PM, David Blevins wrote:> On Aug 22, 2006, at 6:56 PM, David Blevins wrote: >>> I'd be more inclined to talk about what we want to apply it to and>> how.>> More thoughts on the "where" and "how" topic.>> So far my thoughts on "how"; review to your satisfaction and +1, 72 > hour cut off.>> As far as "where" >> I'm inclined to say "at your discretion" where the following are> encouraged:> - Significant new functionality > - Significant changes> - Patches from Contributors> - Borderline "fixes" to a stable branch>> Whether or not it merits RTC would be at your discretion. It is to> your advantage in these situations because: >> - "Significant new functionality" and "Significant changes": It's a>"Get out of jail free" card. Having more people understand your>code keeps you from spending all day on the user list. You do >support your code on the user list, right?>> - "Patches from Contributors": Getting three votes for your patches>is not a bad way to, in time, get your three votes to be a >committer. Let's be clear, someone who commits all your patches>with no review from others on the project isn't doing you any>favors. It's in your interest to push to get your votes on every >patch.>> - "Borderline 'fixes' to a stable branch": It's a given you will>think everything you want to put in a stable branch is important.>But, is it a fix or is it a new feature? If you think others may >disagree, you may want to put it up for review or you may find>yourself running the TCK all alone with no help.>>> Those are the advantages you stand to gain should you choose to use > RTC for any of the above situations. RTC is not the only way to> get the above benefits, so it is at your discretion whether or not> your situation merits it.>> My pragmatic take on RTC for the moment. >> -David>-- Cheers,Guillaume Nodet
Re: Re: Returning to Commit-Then-Review?
I will support anything that does not leave patches to fester and still provides any required pre-commit oversight. I would really like to see a CTR-like policy that puts trust back into the community for example, I trust Hirams activemq patch but my concurrent patch... well I want others to ack it first, as it his areas of the server which are not as familiar to me. It seems to me that David's proposal fits into this... Can we please make an effort to agree on a policy? And once agreed upon, have the PMC officially announce it? I believe this is critical for our community to move forward. --jason On 8/25/06, David Blevins <[EMAIL PROTECTED]> wrote: So anyone have any thoughts on this? I'll assume there's no support unless I hear otherwise. -David On Aug 23, 2006, at 1:14 PM, David Blevins wrote: > On Aug 22, 2006, at 6:56 PM, David Blevins wrote: > >> I'd be more inclined to talk about what we want to apply it to and >> how. > > More thoughts on the "where" and "how" topic. > > So far my thoughts on "how"; review to your satisfaction and +1, 72 > hour cut off. > > As far as "where" > > I'm inclined to say "at your discretion" where the following are > encouraged: > - Significant new functionality > - Significant changes > - Patches from Contributors > - Borderline "fixes" to a stable branch > > Whether or not it merits RTC would be at your discretion. It is to > your advantage in these situations because: > > - "Significant new functionality" and "Significant changes": It's a >"Get out of jail free" card. Having more people understand your >code keeps you from spending all day on the user list. You do >support your code on the user list, right? > > - "Patches from Contributors": Getting three votes for your patches >is not a bad way to, in time, get your three votes to be a >committer. Let's be clear, someone who commits all your patches >with no review from others on the project isn't doing you any >favors. It's in your interest to push to get your votes on every >patch. > > - "Borderline 'fixes' to a stable branch": It's a given you will >think everything you want to put in a stable branch is important. >But, is it a fix or is it a new feature? If you think others may >disagree, you may want to put it up for review or you may find >yourself running the TCK all alone with no help. > > > Those are the advantages you stand to gain should you choose to use > RTC for any of the above situations. RTC is not the only way to > get the above benefits, so it is at your discretion whether or not > your situation merits it. > > My pragmatic take on RTC for the moment. > > -David >
Re: Returning to Commit-Then-Review?
Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jacek Laskowski wrote: I think it's time to sum up the proposals and put them on the Wiki so they are easily found and are in a readable form. No, at least not solely. They need to appear in email messages. Agreed. If Jacek posted a summary of the current proposals running through this thread right now, it would be easier for others to pick up the thread for continuing discussion or, better, consensus. Regards, Alan
Re: Returning to Commit-Then-Review?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aaron Mulder wrote: > > The proposal you shot down wasn't to carry on a conversation on the > Wiki, but to summarize the conversation so far so that people who > didn't catch all the e-mails could stay in the loop. FUD? Yes, FUD. Because I didn't shoot *anything* down. I said: > No, at least not solely. They need to appear in email > messages. Read it again. Can you say 'not only on the wiki'? Can you explain how that equates to 'don't use the wiki at all'? - -- #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 iQCVAwUBRPMlcZrNPMCpn3XdAQINegQAqDR//AcIbi7WaaDybe0rlGyQDRWWIADn 0/B/a6GwpKhzNd36Ps8h+zDmJ/NlKnUhUAZihLS8/ufyuQKZ2IlssiAWCFzzQgiI 5QA1tlFwMD4ovy6L2v2mlgXpOewuHnXhpCvBP8iDzE/dHT+wzowYd+5q4Q8cGBYs GXlKOlvL1FA= =Dc0u -END PGP SIGNATURE-
Re: Returning to Commit-Then-Review?
On 8/28/06, Rodent of Unusual Size <[EMAIL PROTECTED]> wrote: Crock indeed. The wiki is fine, it should be used in whatever manners are considered the best, but it isn't our primary means of communication. For one thing it's pull rather than push, so someone might miss a critical item simply through forgetting to check the wiki. For another, it's not the primary communication medium of *any* ASF function, so using it here would be raising an artificial barrier between Geronimo and people from other projects. Thirdly - -- and this is the killer -- it's not archived holistically with other discussions for future reference. You don't have discussions on a wiki. The proposal you shot down wasn't to carry on a conversation on the Wiki, but to summarize the conversation so far so that people who didn't catch all the e-mails could stay in the loop. FUD? Thanks, Aaron
Re: Returning to Commit-Then-Review?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Um, crock o' FUD time, I see. Aaron Mulder wrote: > > Also, I'm not sure why the PMC Chair continues to attempt to control > and direct communications, Control? No. Direct? Where they don't seem to be happening productively, absolutely. > posting a nearly empty and useless text > file to the list on a regular basis I was all set to remove that when I saw it was actually being used. So I've left it alone. > and telling people how they are or > are not allowed to use the Wiki. Crock indeed. The wiki is fine, it should be used in whatever manners are considered the best, but it isn't our primary means of communication. For one thing it's pull rather than push, so someone might miss a critical item simply through forgetting to check the wiki. For another, it's not the primary communication medium of *any* ASF function, so using it here would be raising an artificial barrier between Geronimo and people from other projects. Thirdly - -- and this is the killer -- it's not archived holistically with other discussions for future reference. You don't have discussions on a wiki. - -- #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 iQCVAwUBRPMQo5rNPMCpn3XdAQL2wQQAwo9U320YrrNQTpvjE9ou58fpvgdxZ2Gb diNy3yey+Pam2gVQ9TmxE/hKGY7IeAcs4Dtag37oTNJu1ArXBwN614isMChQStD0 ZMQV4gVtkCpcpnL6OgicC/IosvBx1sfwqcGYdsUv5nRJ9I9fZQOf0nyScWSG18fr JEzjojAeRGw= =z/oP -END PGP SIGNATURE-
Re: Returning to Commit-Then-Review?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rodent of Unusual Size wrote: > Jacek Laskowski wrote: >> Sure. I wish there were an editor or alike who would put our decisions >> from emails for others who only follow the project rarely, and can't >> cope with the flow. > > Edit the STATUS file, which is getting autoposted. By the way, lest someone think I'm attempting to control communications, the above was meant as a suggestion. Since that's exactly haw the mechanism has been successfully used by other projects. - -- #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 iQCVAwUBRPMLU5rNPMCpn3XdAQIXUgQA1fdP3RWhe5XABbVD86YuFKsdnEsJE7eq wRvg7ek6JmcB7A9PTKS6+SWcJYpeKNDpVl+Jym5f2ppShd4cbNEp974+S+w/s0NB 6xNXqYq3Q1DcnXvAK7KSNe0PEo+2pc1cr4+UbcjESQ+9pl2UWaFFEbzXgNUZSwTC PxZobzxTFnc= =YaGH -END PGP SIGNATURE-
Re: Returning to Commit-Then-Review?
On 8/28/06, Rodent of Unusual Size <[EMAIL PROTECTED]> wrote: Edit the STATUS file, which is getting autoposted. I've tried valiantly, but I can no longer resist posting to this thread. I'm sure my position is well known, but I feel like it needs to be stated anyway. Looking at development progress, RTC has been a disaster. At JavaOne, we had more than 10 people volunteer to implement more than 30 tasks, targeting a release date (including testing and candidates) of 3 months out. There were also 20+ other tasks that we thought would be great but we needed a volunteer to work on them. The notes on all this stuff was posted to this mailing list. It's been more than three months since then (under RTC), and by my count two of the thirty tasks have been completed. Sure, people may be talking more, but this is ridiculous. Maybe OK for a maintenance branch, but a joke for a feature release. I'm OK doing all feature development elsewhere, but it kind of kills the project proper. Clearly I believe trunk should switch to CTR. Also, I'm not sure why the PMC Chair continues to attempt to control and direct communications, posting a nearly empty and useless text file to the list on a regular basis and telling people how they are or are not allowed to use the Wiki. If we're not even allowed to talk among ourselves freely, I can't see how we could be trusted to commit code freely, so on that basis we should clearly stay in RTC. For my 2 cents, a monolithic text file is absolutely not the right forum for summarizing discussions, tallying votes, recording bug status, and so on. We have Jira and a Wiki for a reason, and they should be used appropriately. Thanks, Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRPMAvZrNPMCpn3XdAQL/GAP/eORqsUtLF2fHgwC/7cmc70FHH4uHnoO7 xZn/Sf8x923D+tZE5S0xZolDoXTWdO6zCaTzYqhEgBq/5fjz3mmtOPwO6dOzKRgx B2kHeC0PBUKHJJXdYzZXTDeXv7g27AAZxMbNqE7oT7V9bYdXR71SbUrhhPScrfrT HELp9rPbqgU= =G2uL -END PGP SIGNATURE-
Re: Returning to Commit-Then-Review?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jacek Laskowski wrote: > > Sure. I wish there were an editor or alike who would put our decisions > from emails for others who only follow the project rarely, and can't > cope with the flow. Edit the STATUS file, which is getting autoposted. - -- #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 iQCVAwUBRPMAvZrNPMCpn3XdAQL/GAP/eORqsUtLF2fHgwC/7cmc70FHH4uHnoO7 xZn/Sf8x923D+tZE5S0xZolDoXTWdO6zCaTzYqhEgBq/5fjz3mmtOPwO6dOzKRgx B2kHeC0PBUKHJJXdYzZXTDeXv7g27AAZxMbNqE7oT7V9bYdXR71SbUrhhPScrfrT HELp9rPbqgU= =G2uL -END PGP SIGNATURE-
Re: Returning to Commit-Then-Review?
I guess... though I'm still not really sure that we need to be this formal about things. For example, ActiveMQ seems to be working fine with CTR, and they are getting releases out quickly and features implemented. Seems like we are getting so bogged down by politics :-( But I do think that it is natural and rather obvious that if something big is going to change that there should be discussion about it on the list... so that everyone is on the same page. --jason On Aug 25, 2006, at 3:17 PM, Dain Sundstrom wrote: I think you analysis is spot on. The only think I would change is the "how" section at the top. I'd rather see that to commit you need either 3 +1 (no -1s) from a committer or 72 hours pass which ever happens first unless there is active discussion. Also, I'd strongly suggest one complains loudly if they get no comments after 48 hours. -dain On Aug 25, 2006, at 1:47 PM, David Blevins wrote: So anyone have any thoughts on this? I'll assume there's no support unless I hear otherwise. -David On Aug 23, 2006, at 1:14 PM, David Blevins wrote: On Aug 22, 2006, at 6:56 PM, David Blevins wrote: I'd be more inclined to talk about what we want to apply it to and how. More thoughts on the "where" and "how" topic. So far my thoughts on "how"; review to your satisfaction and +1, 72 hour cut off. As far as "where" I'm inclined to say "at your discretion" where the following are encouraged: - Significant new functionality - Significant changes - Patches from Contributors - Borderline "fixes" to a stable branch Whether or not it merits RTC would be at your discretion. It is to your advantage in these situations because: - "Significant new functionality" and "Significant changes": It's a "Get out of jail free" card. Having more people understand your code keeps you from spending all day on the user list. You do support your code on the user list, right? - "Patches from Contributors": Getting three votes for your patches is not a bad way to, in time, get your three votes to be a committer. Let's be clear, someone who commits all your patches with no review from others on the project isn't doing you any favors. It's in your interest to push to get your votes on every patch. - "Borderline 'fixes' to a stable branch": It's a given you will think everything you want to put in a stable branch is important. But, is it a fix or is it a new feature? If you think others may disagree, you may want to put it up for review or you may find yourself running the TCK all alone with no help. Those are the advantages you stand to gain should you choose to use RTC for any of the above situations. RTC is not the only way to get the above benefits, so it is at your discretion whether or not your situation merits it. My pragmatic take on RTC for the moment. -David
Re: Returning to Commit-Then-Review?
I think you analysis is spot on. The only think I would change is the "how" section at the top. I'd rather see that to commit you need either 3 +1 (no -1s) from a committer or 72 hours pass which ever happens first unless there is active discussion. Also, I'd strongly suggest one complains loudly if they get no comments after 48 hours. -dain On Aug 25, 2006, at 1:47 PM, David Blevins wrote: So anyone have any thoughts on this? I'll assume there's no support unless I hear otherwise. -David On Aug 23, 2006, at 1:14 PM, David Blevins wrote: On Aug 22, 2006, at 6:56 PM, David Blevins wrote: I'd be more inclined to talk about what we want to apply it to and how. More thoughts on the "where" and "how" topic. So far my thoughts on "how"; review to your satisfaction and +1, 72 hour cut off. As far as "where" I'm inclined to say "at your discretion" where the following are encouraged: - Significant new functionality - Significant changes - Patches from Contributors - Borderline "fixes" to a stable branch Whether or not it merits RTC would be at your discretion. It is to your advantage in these situations because: - "Significant new functionality" and "Significant changes": It's a "Get out of jail free" card. Having more people understand your code keeps you from spending all day on the user list. You do support your code on the user list, right? - "Patches from Contributors": Getting three votes for your patches is not a bad way to, in time, get your three votes to be a committer. Let's be clear, someone who commits all your patches with no review from others on the project isn't doing you any favors. It's in your interest to push to get your votes on every patch. - "Borderline 'fixes' to a stable branch": It's a given you will think everything you want to put in a stable branch is important. But, is it a fix or is it a new feature? If you think others may disagree, you may want to put it up for review or you may find yourself running the TCK all alone with no help. Those are the advantages you stand to gain should you choose to use RTC for any of the above situations. RTC is not the only way to get the above benefits, so it is at your discretion whether or not your situation merits it. My pragmatic take on RTC for the moment. -David
Re: Returning to Commit-Then-Review?
On 8/25/06, Hernan Cunico <[EMAIL PROTECTED]> wrote: May I propose the place for such summary to be: http://cwiki.apache.org/GMOxPMGT/apache-geronimo-development-process.html +1 (wherever actually as far as it's easily found) I'm one of those who miss some "key" things in those mile long threads but I'll be happy to do the Confluence makeup and put it in the wiki if somebody wraps up a summary. I'm going to give it a show, but I'm not available until late Sunday. Have fun! Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Returning to Commit-Then-Review?
On 8/25/06, Rodent of Unusual Size <[EMAIL PROTECTED]> wrote: No, at least not solely. They need to appear in email messages. Sure. I wish there were an editor or alike who would put our decisions from emails for others who only follow the project rarely, and can't cope with the flow. So, yes - emails are our primary means of communication whereas Wiki would support it. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Returning to Commit-Then-Review?
May I propose the place for such summary to be: http://cwiki.apache.org/GMOxPMGT/apache-geronimo-development-process.html I'm one of those who miss some "key" things in those mile long threads but I'll be happy to do the Confluence makeup and put it in the wiki if somebody wraps up a summary. Cheers! Hernan Jacek Laskowski wrote: On 8/25/06, David Blevins <[EMAIL PROTECTED]> wrote: So anyone have any thoughts on this? I'll assume there's no support unless I hear otherwise. I think it's time to sum up the proposals and put them on the Wiki so they are easily found and are in a readable form. Those who are not skilled to read lenghty threads may have lost a few. I think it would help in general for a future reference when we decide to not give it a try and keep RTC, perhaps for other projects or to become a base for an ASF official document. Jacek
Re: Returning to Commit-Then-Review?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jacek Laskowski wrote: > > I think it's time to sum up the proposals and put them on the Wiki so > they are easily found and are in a readable form. No, at least not solely. They need to appear in email messages. - -- #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 iQCVAwUBRO9s75rNPMCpn3XdAQIy2QP+PHfqzNtXqEoJW7+WAG/eOZk9Z1wWSZiB zzSbuV6P3F9jjhIG+FArievfE2tHWB0pc4OIMooPSx4+q3mytxFPnzkV8nSSssRU GFw5ZQQQWm+Wm4OrMbWM/PURtlv4VroGB3XezcLCi4qRzK1/Qoqhxy43chO9q21d w5Z1hL2b/u0= =lf8n -END PGP SIGNATURE-
Re: Returning to Commit-Then-Review?
On 8/25/06, David Blevins <[EMAIL PROTECTED]> wrote: So anyone have any thoughts on this? I'll assume there's no support unless I hear otherwise. I think it's time to sum up the proposals and put them on the Wiki so they are easily found and are in a readable form. Those who are not skilled to read lenghty threads may have lost a few. I think it would help in general for a future reference when we decide to not give it a try and keep RTC, perhaps for other projects or to become a base for an ASF official document. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Returning to Commit-Then-Review?
So anyone have any thoughts on this? I'll assume there's no support unless I hear otherwise. -David On Aug 23, 2006, at 1:14 PM, David Blevins wrote: On Aug 22, 2006, at 6:56 PM, David Blevins wrote: I'd be more inclined to talk about what we want to apply it to and how. More thoughts on the "where" and "how" topic. So far my thoughts on "how"; review to your satisfaction and +1, 72 hour cut off. As far as "where" I'm inclined to say "at your discretion" where the following are encouraged: - Significant new functionality - Significant changes - Patches from Contributors - Borderline "fixes" to a stable branch Whether or not it merits RTC would be at your discretion. It is to your advantage in these situations because: - "Significant new functionality" and "Significant changes": It's a "Get out of jail free" card. Having more people understand your code keeps you from spending all day on the user list. You do support your code on the user list, right? - "Patches from Contributors": Getting three votes for your patches is not a bad way to, in time, get your three votes to be a committer. Let's be clear, someone who commits all your patches with no review from others on the project isn't doing you any favors. It's in your interest to push to get your votes on every patch. - "Borderline 'fixes' to a stable branch": It's a given you will think everything you want to put in a stable branch is important. But, is it a fix or is it a new feature? If you think others may disagree, you may want to put it up for review or you may find yourself running the TCK all alone with no help. Those are the advantages you stand to gain should you choose to use RTC for any of the above situations. RTC is not the only way to get the above benefits, so it is at your discretion whether or not your situation merits it. My pragmatic take on RTC for the moment. -David
Re: Returning to Commit-Then-Review?
Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Blevins wrote: But the lazy consensus "cut off" you mention is something to think about. That sort of model has been used before successfully. IIRC, it was as part of the 'controversial issues are RTC' part of CTR. In other words, rather than committing something that might be controversial (which shouldn't be done under pretty much any circumstances), it would be posted as a patch for people to examine and check out, with a comment of 'if no-one - -1s this in 72 hours I'll commit it.' An acceptable middle ground procedure. This seems like a nice RTC/CTR compromise to me. Regards, Alan
Re: Returning to Commit-Then-Review?
Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Apache Geronimo has been operating mostly under the Review-Then-Commit model for a couple of months now, and I think the issues the change was intended to highlight have been .. well, highlighted. How do people feel about the idea of switching back to Commit-Then-Review at this point? I like RTC. I hope that it stays. However, I will not fight hard to keep it. I know human tendency and I believe that w/ CTR we will fall back into old bad habits. Regards, Alan
Re: Returning to Commit-Then-Review?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jacek Laskowski wrote: > > Just run across a question - let me think out loud. I think it's not > been answered yet. If only PMCers votes are binding and only when a > change gets 3 +1's binding votes (i.e. PMCers) the change may be > checked in, the question is what's the role of the commiters group? > We've got 3 groups: the PMC, the committers and the community and I > don't see how the committers are different from the community even > though they've been armed with something that's I think is unusable? The distinction you're drawing between the PMC and the committers is an artificial one. I among others think they should be identical. - -- #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 iQCVAwUBRO0AYZrNPMCpn3XdAQLeYgP/aqdZM4lqzE4hS1Dty86/xi27lgOJ7L06 Pt+tJCWKLt2Txj84rrXGvCExVhmk5RXxSTXdaTLO2sLIwmhFC4a8oj6ZkYi6DfzQ lZnniciJ1DAiD3eGHSBXwX/pY2ZfKbznnJvrZWAzUOkmof3GGq31pFYT5phjZbfM 2qLHWQ/6FTM= =22ir -END PGP SIGNATURE-
Re: Returning to Commit-Then-Review?
Just a correction On Aug 23, 2006, at 1:14 PM, David Blevins wrote: On Aug 22, 2006, at 6:56 PM, David Blevins wrote: I'd be more inclined to talk about what we want to apply it to and how. More thoughts on the "where" and "how" topic. So far my thoughts on "how"; review to your satisfaction and +1, 72 hour cut off. As far as "where" I'm inclined to say "at your discretion" where the following are encouraged: - Significant new functionality - Significant changes - Patches from Contributors - Borderline "fixes" to a stable branch Whether or not it merits RTC would be at your discretion. It is to your advantage in these situations because: - "Significant new functionality" and "Significant changes": It's a "Get out of jail free" card. Having more people understand your code keeps you from spending all day on the user list. You do support your code on the user list, right? The sentence "Having more people...", should be "Also, having more people..." as to make it clear that it's a second unrelated point rather than an explanation of the first point. Thanks, David - "Patches from Contributors": Getting three votes for your patches is not a bad way to, in time, get your three votes to be a committer. Let's be clear, someone who commits all your patches with no review from others on the project isn't doing you any favors. It's in your interest to push to get your votes on every patch. - "Borderline 'fixes' to a stable branch": It's a given you will think everything you want to put in a stable branch is important. But, is it a fix or is it a new feature? If you think others may disagree, you may want to put it up for review or you may find yourself running the TCK all alone with no help. Those are the advantages you stand to gain should you choose to use RTC for any of the above situations. RTC is not the only way to get the above benefits, so it is at your discretion whether or not your situation merits it. My pragmatic take on RTC for the moment. -David
Re: Returning to Commit-Then-Review?
On Aug 22, 2006, at 6:56 PM, David Blevins wrote: I'd be more inclined to talk about what we want to apply it to and how. More thoughts on the "where" and "how" topic. So far my thoughts on "how"; review to your satisfaction and +1, 72 hour cut off. As far as "where" I'm inclined to say "at your discretion" where the following are encouraged: - Significant new functionality - Significant changes - Patches from Contributors - Borderline "fixes" to a stable branch Whether or not it merits RTC would be at your discretion. It is to your advantage in these situations because: - "Significant new functionality" and "Significant changes": It's a "Get out of jail free" card. Having more people understand your code keeps you from spending all day on the user list. You do support your code on the user list, right? - "Patches from Contributors": Getting three votes for your patches is not a bad way to, in time, get your three votes to be a committer. Let's be clear, someone who commits all your patches with no review from others on the project isn't doing you any favors. It's in your interest to push to get your votes on every patch. - "Borderline 'fixes' to a stable branch": It's a given you will think everything you want to put in a stable branch is important. But, is it a fix or is it a new feature? If you think others may disagree, you may want to put it up for review or you may find yourself running the TCK all alone with no help. Those are the advantages you stand to gain should you choose to use RTC for any of the above situations. RTC is not the only way to get the above benefits, so it is at your discretion whether or not your situation merits it. My pragmatic take on RTC for the moment. -David
Re: Returning to Commit-Then-Review?
On 8/23/06, Rodent of Unusual Size <[EMAIL PROTECTED]> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Apache Geronimo has been operating mostly under the Review-Then-Commit model for a couple of months now, and I think the issues the change was intended to highlight have been .. well, highlighted. How do people feel about the idea of switching back to Commit-Then-Review at this point? I think that until those matters that made it happen are finally sorted out we should keep this course. I'm not convinced that highlighting them is what should change the mode to CTR. Also, I'd say it's only a few days when we've got such a large PMC group to keep the development pace at a reasonable speed. It's almost as if everybody with commit karma were on the PMC, so we should *now* be able to manage the flow. In fact, I don't see a difference between RTC and CTR when the number of people with binding votes have just increased significantly. Just run across a question - let me think out loud. I think it's not been answered yet. If only PMCers votes are binding and only when a change gets 3 +1's binding votes (i.e. PMCers) the change may be checked in, the question is what's the role of the commiters group? We've got 3 groups: the PMC, the committers and the community and I don't see how the committers are different from the community even though they've been armed with something that's I think is unusable? Wouldn't CTR get rid of the question? Should I ask the question at all? Should I worry about it? Just thinking out loud hoping I'll get some helpful responses to clear up the mess I've got in my mind. Too much to think about before I get asleep. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Returning to Commit-Then-Review?
JBohn pointed out I had RTC as my last statement...I meant CTR Matt Hogstrom wrote: From a purely discussion perspective I'm in favor of a change. I'm not sure a total shift to CTR is appropriate but I'm not particularly opposed to it either. I don't think the development model itself is the issue. The major issue that we've been dealing with is the community dynamics and alignment of people's interests and Apache's community model (or lack of alignment). I would expect that if we were to move to CTR we'd see a continuation of what we're doing now with the exception that all changes would not require the current voting requirements. I plan on reviewing the commits as they go in (as Jason alluded to in another thread). I think we all are expecting more things to be documented via JIRA for improved documentation and communication. That major items are announced as their inspired so the community can provide feedback in the form of comments or assistance. We all assume comments are constructive and spend a few minutes thinking about an e-mail before sending it (boy and I guilty of violating this one:) Overall, I'm in favor of changing. Part of me would like to simply go to RTC and let the community dynamics prove themselves. Definitely not a return to the previous model though. Rodent of Unusual Size wrote: Apache Geronimo has been operating mostly under the Review-Then-Commit model for a couple of months now, and I think the issues the change was intended to highlight have been .. well, highlighted. How do people feel about the idea of switching back to Commit-Then-Review at this point?
Re: Returning to Commit-Then-Review?
From a purely discussion perspective I'm in favor of a change. I'm not sure a total shift to CTR is appropriate but I'm not particularly opposed to it either. I don't think the development model itself is the issue. The major issue that we've been dealing with is the community dynamics and alignment of people's interests and Apache's community model (or lack of alignment). I would expect that if we were to move to CTR we'd see a continuation of what we're doing now with the exception that all changes would not require the current voting requirements. I plan on reviewing the commits as they go in (as Jason alluded to in another thread). I think we all are expecting more things to be documented via JIRA for improved documentation and communication. That major items are announced as their inspired so the community can provide feedback in the form of comments or assistance. We all assume comments are constructive and spend a few minutes thinking about an e-mail before sending it (boy and I guilty of violating this one:) Overall, I'm in favor of changing. Part of me would like to simply go to RTC and let the community dynamics prove themselves. Definitely not a return to the previous model though. Rodent of Unusual Size wrote: Apache Geronimo has been operating mostly under the Review-Then-Commit model for a couple of months now, and I think the issues the change was intended to highlight have been .. well, highlighted. How do people feel about the idea of switching back to Commit-Then-Review at this point?
Re: Returning to Commit-Then-Review?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Blevins wrote: > > But the lazy consensus "cut off" you mention is something to think > about. That sort of model has been used before successfully. IIRC, it was as part of the 'controversial issues are RTC' part of CTR. In other words, rather than committing something that might be controversial (which shouldn't be done under pretty much any circumstances), it would be posted as a patch for people to examine and check out, with a comment of 'if no-one - -1s this in 72 hours I'll commit it.' An acceptable middle ground procedure. - -- #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 iQCVAwUBROx7uZrNPMCpn3XdAQITDQQA3oq9WMLV5MFANtDEdpW3RdQcKS4byz7M ibu2l6vhRdyhvLGKQwUnQBmPzzvnG+WAMQrCyxI3nNZAMbeQ2R2vqpUL/5ODULdn 7SYBf2iFBuS9+ouodGjTccCv3zGTPa130VZwVusvAdn36Qk+5FjF1SO0J7jG8FBA Z3hW59qp1wI= =Xlj6 -END PGP SIGNATURE-
Re: Returning to Commit-Then-Review?
+1 for CTR which I believe is accurately summarized in its most common manifestation by Kevan's #1. Joe Kevan Miller wrote: On Aug 22, 2006, at 7:02 PM, Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Apache Geronimo has been operating mostly under the Review-Then-Commit model for a couple of months now, and I think the issues the change was intended to highlight have been .. well, highlighted. How do people feel about the idea of switching back to Commit-Then-Review at this point? I'm certainly in favor of switching back. However, RTC has put an improved focus on communication within the community. I definitely want that to continue. Possible options would include: 1) Follow CTR. Document best practices and use community-based persuasion to keep things working well. 2) Follow CTR. Follow a strict procedure for documenting enhancements. 2) Follow RTC. Relax the reviewed/merged/tested aspect of RTC 3) Follow RTC. Institue a lazy consensus policy 4) 2 & 3 5) etc. IMO, 1) is the way a healthy community should be operating and I think that's the process we should be following. The best practices/guidelines should not be strict dogma -- common sense should prevail. It's communication that's important, not process. Guidelines are something along the lines of: 1) For larger changes (or potentially controversial changes), announce your intentions. Give the community an indication of what you're planning. You should allow enough time (and detail) to allow the community to understand and discuss. 2) Before you commit your changes, document your change. Describe what you are doing, why you are doing it, and provide an overview of how you did it (or a roadmap on how you plan on doing it). --kevan
Re: Returning to Commit-Then-Review?
On 8/22/06, Kevan Miller <[EMAIL PROTECTED]> wrote:
The best practices/guidelines should not be strict dogma -- common
sense should prevail. It's communication that's important, not
process.
The statements above are what should really prevail from this
conversation. I agree with this sentiment because, IMO, a process is
meant to guide the direction of a set of tasks. It is not meant to be
dogmatically enforced. I feel I understand The Apache Way and all too
often I've seen process enforced for process sake, rather than
allowing common sense to prevail and doing what makes the most sense
in the given situation. Of course, it's also not always a matter of
what you say, but how you say it.
Guidelines are something along the lines of:
1) For larger changes (or potentially controversial changes),
announce your intentions. Give the community an indication of what
you're planning. You should allow enough time (and detail) to allow
the community to understand and discuss.
2) Before you commit your changes, document your change. Describe
what you are doing, why you are doing it, and provide an overview of
how you did it (or a roadmap on how you plan on doing it).
I also agree with the two items noted above. A simple message to
announce your intentions would be really great. But this also doesn't
mean that such an announcement needs to spiral into a debate about how
or why something should be implemented.
Additionally, all too often when I'm digging into how something works
I find that there is little to no documentation so I'm forced to
question others about it which in turn just aggravates those people
because I'm bugging them so often. I'd really like to see a peer
pressure system enforced where we are telling each to document changes
and new features.
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/
Apache ActiveMQ - http://incubator.apache.org/activemq/
Apache ServiceMix - http://incubator.apache.org/servicemix/
Castor - http://castor.org/
Re: Returning to Commit-Then-Review?
On Aug 22, 2006, at 7:33 PM, Brett Porter wrote: From the peanut gallery... On 23/08/06, David Blevins <[EMAIL PROTECTED]> wrote: I'd be more inclined to talk about what we want to apply it to and how. That said, I've stared at this email for an hour after writing the above sentence and am still not sure what the answer would be Part of me wouldn't mind seeing an RTC process where - it's not enforced. meaning we could pull the plug whenever we like So, that would be RTC by lazy consensus? After 72 hours it gets committed anyway if there are no -1's? No, more like "we as a project choose to do RTC of our own free will and reserve the right to switch models or evolve it to a new model" I think the fact that it will be a conscious choice as opposed to being imposed is a significant difference. But the lazy consensus "cut off" you mention is something to think about. - your +1 could simply mean you've reviewed it to your satisfaction (whatever that means for you) and agree with the change. I think I'd ask people to just +0 or say that to be clear so you know how well tested it was. You don't want to be asking what their +1 really meant. I'm fine with a +1 and an optional comment as to how it was reviewed. I'm not as concerned about testing as I am about getting people to see, understand, and *support* the changes. I went to the extreme to build a cluster of computers to automatically build, test, and tck certify all active Geronimo branches 24x7, so I'm understandably less concerned about testing. If someone breaks Geronimo, we'll know. I just want to know that there are three people that have Read, Understand, and Support the changes. This is significant in that there are now 4 people who can support that code rather than just one. Definitely my biggest concern by far. Tempted to also throw in "three +1s from any committer other than the proposer are sufficient", but if that's going to be a topic of debate, I'd rather see it put on hold and the first two items implemented first. The first one sort of allows this. I think anything that encourages more committers to review is a good thing. So, are you saying you don't think Geronimo is ready for CTR yet? I don't know if I'm ready, no. Don't know how the other guys/gals feel on if they're ready. One thing that struck me is that if there was trouble getting reviews done under RTC then its likely to be that CTR dissolves to just C :) We don't know that, really. What we do know is that we had a hard time getting people to successfully apply and build all patches. But we really don't have a good sense of how much we can review in the sense of reading, understanding and agreeing to changes. So perhaps some work on building a culture of review (including ensuring enough committers have an eye on each area of the code) is still helpful, with steps such as those you've highlighted. That's what's in my head currently. Still waiting to hear what others say. -David
Re: Returning to Commit-Then-Review?
On Aug 22, 2006, at 7:02 PM, Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Apache Geronimo has been operating mostly under the Review-Then-Commit model for a couple of months now, and I think the issues the change was intended to highlight have been .. well, highlighted. How do people feel about the idea of switching back to Commit-Then-Review at this point? I'm certainly in favor of switching back. However, RTC has put an improved focus on communication within the community. I definitely want that to continue. Possible options would include: 1) Follow CTR. Document best practices and use community-based persuasion to keep things working well. 2) Follow CTR. Follow a strict procedure for documenting enhancements. 2) Follow RTC. Relax the reviewed/merged/tested aspect of RTC 3) Follow RTC. Institue a lazy consensus policy 4) 2 & 3 5) etc. IMO, 1) is the way a healthy community should be operating and I think that's the process we should be following. The best practices/guidelines should not be strict dogma -- common sense should prevail. It's communication that's important, not process. Guidelines are something along the lines of: 1) For larger changes (or potentially controversial changes), announce your intentions. Give the community an indication of what you're planning. You should allow enough time (and detail) to allow the community to understand and discuss. 2) Before you commit your changes, document your change. Describe what you are doing, why you are doing it, and provide an overview of how you did it (or a roadmap on how you plan on doing it). --kevan
Re: Returning to Commit-Then-Review?
I think that folks do review after commits... I know I peek at all change logs and see if anything looks fishy. --jason On Aug 22, 2006, at 7:33 PM, Brett Porter wrote: From the peanut gallery... On 23/08/06, David Blevins <[EMAIL PROTECTED]> wrote: I'd be more inclined to talk about what we want to apply it to and how. That said, I've stared at this email for an hour after writing the above sentence and am still not sure what the answer would be Part of me wouldn't mind seeing an RTC process where - it's not enforced. meaning we could pull the plug whenever we like So, that would be RTC by lazy consensus? After 72 hours it gets committed anyway if there are no -1's? - your +1 could simply mean you've reviewed it to your satisfaction (whatever that means for you) and agree with the change. I think I'd ask people to just +0 or say that to be clear so you know how well tested it was. You don't want to be asking what their +1 really meant. Tempted to also throw in "three +1s from any committer other than the proposer are sufficient", but if that's going to be a topic of debate, I'd rather see it put on hold and the first two items implemented first. The first one sort of allows this. I think anything that encourages more committers to review is a good thing. So, are you saying you don't think Geronimo is ready for CTR yet? One thing that struck me is that if there was trouble getting reviews done under RTC then its likely to be that CTR dissolves to just C :) So perhaps some work on building a culture of review (including ensuring enough committers have an eye on each area of the code) is still helpful, with steps such as those you've highlighted. I know I feel somewhat reassured that when I do something dumb in Maven that someone always seems to find it. Just my 2c. Cheers, Brett
Re: Returning to Commit-Then-Review?
From the peanut gallery... On 23/08/06, David Blevins <[EMAIL PROTECTED]> wrote: I'd be more inclined to talk about what we want to apply it to and how. That said, I've stared at this email for an hour after writing the above sentence and am still not sure what the answer would be Part of me wouldn't mind seeing an RTC process where - it's not enforced. meaning we could pull the plug whenever we like So, that would be RTC by lazy consensus? After 72 hours it gets committed anyway if there are no -1's? - your +1 could simply mean you've reviewed it to your satisfaction (whatever that means for you) and agree with the change. I think I'd ask people to just +0 or say that to be clear so you know how well tested it was. You don't want to be asking what their +1 really meant. Tempted to also throw in "three +1s from any committer other than the proposer are sufficient", but if that's going to be a topic of debate, I'd rather see it put on hold and the first two items implemented first. The first one sort of allows this. I think anything that encourages more committers to review is a good thing. So, are you saying you don't think Geronimo is ready for CTR yet? One thing that struck me is that if there was trouble getting reviews done under RTC then its likely to be that CTR dissolves to just C :) So perhaps some work on building a culture of review (including ensuring enough committers have an eye on each area of the code) is still helpful, with steps such as those you've highlighted. I know I feel somewhat reassured that when I do something dumb in Maven that someone always seems to find it. Just my 2c. Cheers, Brett
Re: Returning to Commit-Then-Review?
+1 for switching back to CTR On 8/22/06, Rodent of Unusual Size <[EMAIL PROTECTED]> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Apache Geronimo has been operating mostly under the Review-Then-Commit model for a couple of months now, and I think the issues the change was intended to highlight have been .. well, highlighted. How do people feel about the idea of switching back to Commit-Then-Review at this point? - -- #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 iQCVAwUBROuM8prNPMCpn3XdAQJasgP6AmIwS/d8cS12D6ClRmeWAdbtkQIPFVsY QvGXkS6/LhrNNKnA+vsKdOOE/dsPa9MaxlhBNqG4qN8Wz+gQMIj6zD5h+u20GG6W LBmDilEYctBZtjTZ+WovEfweQbiAX4aRjWi/mClQzAvKIdMEAph4UmwYQy/F5FG0 anL4nJoStVw= =XJ1j -END PGP SIGNATURE-
Re: Returning to Commit-Then-Review?
On Aug 22, 2006, at 4:02 PM, Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Apache Geronimo has been operating mostly under the Review-Then-Commit model for a couple of months now, and I think the issues the change was intended to highlight have been .. well, highlighted. How do people feel about the idea of switching back to Commit-Then-Review at this point? I'd be more inclined to talk about what we want to apply it to and how. That said, I've stared at this email for an hour after writing the above sentence and am still not sure what the answer would be Part of me wouldn't mind seeing an RTC process where - it's not enforced. meaning we could pull the plug whenever we like - your +1 could simply mean you've reviewed it to your satisfaction (whatever that means for you) and agree with the change. Tempted to also throw in "three +1s from any committer other than the proposer are sufficient", but if that's going to be a topic of debate, I'd rather see it put on hold and the first two items implemented first. -David - -- #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 iQCVAwUBROuM8prNPMCpn3XdAQJasgP6AmIwS/d8cS12D6ClRmeWAdbtkQIPFVsY QvGXkS6/LhrNNKnA+vsKdOOE/dsPa9MaxlhBNqG4qN8Wz+gQMIj6zD5h+u20GG6W LBmDilEYctBZtjTZ+WovEfweQbiAX4aRjWi/mClQzAvKIdMEAph4UmwYQy/F5FG0 anL4nJoStVw= =XJ1j -END PGP SIGNATURE-
Re: Returning to Commit-Then-Review?
+1 --jason On Aug 22, 2006, at 4:02 PM, Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Apache Geronimo has been operating mostly under the Review-Then-Commit model for a couple of months now, and I think the issues the change was intended to highlight have been .. well, highlighted. How do people feel about the idea of switching back to Commit-Then-Review at this point? - -- #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 iQCVAwUBROuM8prNPMCpn3XdAQJasgP6AmIwS/d8cS12D6ClRmeWAdbtkQIPFVsY QvGXkS6/LhrNNKnA+vsKdOOE/dsPa9MaxlhBNqG4qN8Wz+gQMIj6zD5h+u20GG6W LBmDilEYctBZtjTZ+WovEfweQbiAX4aRjWi/mClQzAvKIdMEAph4UmwYQy/F5FG0 anL4nJoStVw= =XJ1j -END PGP SIGNATURE-
