On Feb 8, 2007, at 11:41 AM, Sam Ruby wrote:
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.
Consensus may have been the wrong word - common understanding of what
the branch is for might have been better phrasing. There's been talk
about stabilizing for a release (which is often when branches are
used for), but also about developing new features (which is usually
done in trunk). Is this someone's personal environment, or a
revolution? I simply don't know.
I think consensus here though is important - not on whether we create
a branch but in the impact this has on how we develop as a community.
We were working together, all of a sudden something has changed and
now we have friction. That's what we need to fix.
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?
I don't know.
One of the factors here is the change in the spec APIs from 0.95 to
1.0 which had many incompatible changes. I think we all want to
support 1.0 but reality is that all of our samples, "end-to-end
scenarios" and itests are written against the 0.95 level. We knew
evolution to 1.0 would be disruptive which is why we have a "pre-
spec" branch as a baseline for ongoing development at the 0.95 level;
it seems like some friction is coming because this is not working and
perhaps tackling that will make things smoother.
People have talked about working on scenarios and Jira issues, but
it's not clear if they are intending to do that at the 0.95 level or
at the 1.0 level. If at the 1.0 level, the harsh reality is that we
don't have a 1.0 level runtime yet to support them - some of us are
working on it but it's not done yet. I think joining in that work is
the most effective way to get something that can run 1.0 level
scenarios, but if people want to start a branch and do it there
that's cool too.
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.
I've been wondering about that too - not for stability, but for the
community-building aspect. It's certainly a better option than
throwing vetos around.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
