On the 1.0.x branches I think it would be safe to say that what your doing
should be tierd to a JIRA. That's not to say every activity requires a
spearate JIRA entry (ala, preperation for build can contain several commits over
time) but since we are concerned about breaking things I think the JIRA entry is
a good compromise. Everyone will see the issue go by and its targetted release
number.
I would prefer to operate in CTR as much as possible. If we can't trust each
other we have bigger issues than the process.
David Blevins wrote:
On Jan 16, 2006, at 10:29 AM, Rodent of Unusual Size wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
David Jencks wrote:
I also am not so sure that this magnitude of change needs prior
discussion on the list. I've frequently made larger changes without
discussion of my specific code. I've also broken lots of stuff at
various times.
Let's all come into agreement on the development model, then.
Apache historically has use two distinct models, called Review
Then Commit (RTC) and Commit Then Review (CTR).
Under the RTC model, all changes -- except to docco or minor
bug fixes -- need to be reviewed and garner at least three +1
votes before being committed. Giving a +1 means you've applied
the patch and tested it yourself. If a patch doesn't get the
requisite number of positive votes, it doesn't get committed.
Under CTR, any change can get committed at any time, although
major ones are supposed to follow the RTC model. Committers
need to ask themselves whether the commit will spark controversy;
if so, they should follow RTC and get support first.
The advantages of RTC are code quality and team building. Nothing
goes in that hasn't been tested by at least three people. The
primary disadvantage is that its conservative approach tends to
slow down development. Its enemies are self-interest and apathy;
supporters need to lobby for their work to be tested, and all
developers need to remember that they're dependent upon one
another.
The advantage of CTR is prototyping speed. Its disadvantages
are less-assured quality and community divisiveness. Its
enemy is ego. Since criticism occurs after code has been
committed, personal investment is greater and defensiveness
higher. Developers are typically less aware of each others'
work.
I believe it is safe to say that Geronimo has been operating
in CTR mode, but I think the specifics and ground rules may
not have been spelt out, or need to be again. Is this the
way in which the majority wants to continue to proceed?
I'm fine with CTR on trunk. Discussion is a plus. If you don't
discuss and check in and break something, well ... let's just say it's
an opportunity to impress everyone with how much of a team player you
are ;)
I'm mostly fine with CTR on a branch like 1.0.x, tempted to say RTC but
don't want to go quite that far. Discussion or a heads up being more
or less required; a really good idea at the least. Don't want to say
full RTC because I think after a while we'll get a feel for what we
think is good to add to a stable branch and what is not. We're
probably going to have to be a bit chatty on what goes in 1.0.x in the
sort term, though, while we find our groove.
-David
