geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <kevan.mil...@gmail.com>
Subject Re: [VOTE] Geronimo Development Process
Date Tue, 12 Sep 2006 15:56:21 GMT
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-----


Mime
View raw message