On 2/8/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
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.
It actually is unknowable. It is the nature of the work.
The branch could go nowhere. It could become the basis for people to
quickly these scenarios to the trunk. It could expose problems
earlier than would otherwise be found on the trunk.
At a minimum, it will not disrupt continued progress on the trunk, and
by being done in the open and under a compatible license, it can be
readily cannibalized at any point.
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.
Reviewing the archives, what I see is mounting frustration, one that
would benefit from a release valve. No-one seems to be questioning
that the work that is going on in the trunk is necessary, the only is
growing recognition that more parallelism is required.
>> 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.
Actually, I would seriously doubt it.
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.
Perhaps. But it is also possible that a branch that is closer to the
current trunk would be less disruptive long term. And not necessarily
just one branch, this process could conceivably even repeat
periodically, and eventually converge.
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.
At some point you hit the mythical man month "nine women, one baby" issue.
re: "if people want to start a branch and do it there that's cool too."
+1
> 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.
Geronimo recently had this imposed on them. It was just the jolt that
they needed, but once that was accomplished, it was quickly disposed
of. My thoughts are that it is an option to consider, but one not to
be taken lightly.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
