geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Dudney <bdud...@apache.org>
Subject Re: [VOTE] Geronimo Development Process
Date Tue, 12 Sep 2006 15:08:32 GMT
Hi Ken,

General question: Why is it bad to hold a discussion in a JIRA since  
the whole of the discussion is archived in the issues mailing list.  
Seems like the JIRA is the ideal place to hold the discussion because  
its archived and organized for all to follow. If the JIRA magically  
or mysteriously disappears then we still have the issues mailing list  
log to look to.

If we hold the discussion about a JIRA in the mail list it seems to  
me we'd have two places to look at to understand the JIRA, and that  
IMO is bad.

TTFN,

-bd-

On Sep 12, 2006, at 8: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