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-----

Reply via email to