On 2/8/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
>
> So I think we need a branch to do this stabilization work
I'm disturbed by this proposal as I don't think we have consensus in
the community yet on this issue.
This is not an issue that requires consensus. I've referred
previously to a memo tited 'rules for revolutionaries'[1] which
addresses the need to reduce friction in times like these.
If the issue here is that trunk is unstable, then we should stabilize
trunk.
That would be wonderful. But let's put that in concrete terms. At
least one individual (and possibly several) is interested in working
on the 'BigBank' end to end scenario. Other (others?) are interested
in verifying fixes to issues reported in JIRA.
Which would minimize friction more? Allowing that work to proceed in
a branch, or for that individual (or individuals) to start exercising
their right to veto any change that impedes their progress? The
latter approach would put a significant, albeit short term, damper on
refactoring efforts, independent of the long term value in said
refactoring.
So, to put a not so fine point on it, it would represent essentially a
moratorium on all but the most insignificant refactoring efforts.
Is that what this group wants?
If so, another way to proceed is for the project to adopt a 'review
then commit model', whereby all changes are proposed for discussion
and voted on before commits are made. Projects which place a high
premium on stability, like the Apache HTTPD project operate in this
way everyday.
- Sam Ruby
[1] http://incubator.apache.org/learn/rules-for-revolutionaries.html
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
