Re: [VOTE] Geronimo Development Process

[Kevan Miller]

Ken, Understand your concerns about communication occurring on the mailing lists. I think these can be addressed in the proposals. I don't think they fundamentally change the nature of the proposals. Do you agree? If we're uncomfortable with the vote, as stands. I can respin... Finally, would prefer not to turn this vote thread into a discussion. The proposals were discussed on the mailing list and summarized in the "[SUMMARY] Proposed Geronimo Development Processes" thread. Perhaps we can move there? --kevan On Sep 12, 2006, at 10:56 AM, Rodent of Unusual Size wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kevan Miller wrote: 1. Relaxed RTC Geronimo follows a Review-Then-Commit (RTC) model.  Patches for new   function are provided by developers for review and comment by their   peers.  Feedback is conducted through JIRA comments. - -1 on that last sentence.  You don't hold discussions in JIRA.. * Any -1 votes need to be accompanied by a reason (the parties should   then attempt to reach a mutually agreed upon solution to the issue   raised). - -1 on the parenthetical clause.  It would be nice, but 'should' is too strong I think.  That's calling for someone who vetoed a change for technical reasons to help resolve his own veto whether he likes the change or not. * If the issues can't be resolved then the PMC can be called upon to   settle the dispute and make a recommendation. - -1.  A veto is a veto.  The above implies that the PMC can override a valid veto.  It cannot. 2. RTC with Lazy Consensus Geronimo follows a Review-Then-Commit model with Lazy consensus.   Patches for new function are provided by developers for review and   comment by their peers. Feedback is conducted through JIRA comments. - -1 on the JIRA means again. 3. CTR with documentation guidelines * Concurrent with the commit of a significant change, the committer   should document the change on the dev list. You should describe what   you are doing, describe why you are doing it, and provide an overview   of how you implemented it. It's useful for historical reasons for most of that to be in the commit log. - -- #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 iQCVAwUBRQbKoprNPMCpn3XdAQJ+sQP/f2qsSKuQG3fv3YbD+x0n86J1FTU3g6Ej sIX24W+VreozwE/fya+nz0vD4QI3+J2QRPUUA0IAbtVQAF7NhQ1FCrtYh8T168e4 /XGgC+hd27xL3WA7eJT4b+SKCVaXjQRQnSbXMxSe0OnUj1RXumURYWOKw6+gIvhO qTKykt6U02U= =rwwV -----END PGP SIGNATURE-----