On Tue, 13 Mar 2007, Greg Stein wrote:
> On 3/8/07, C. Michael Pilato <cmpilato@collab.net> wrote:
> >...
> >But here's my concern. Of the features in the trunk so far that Hyrum as
> >touted, I don't really see any that strike me as Big Ones Most Everyone Is
> >Clamoring For. I don't say this to diminish the features or the fantastic
> >work of those that provided them, but compared to Merge Tracking, they all
> >seem to fill somewhat niche-y voids applicable to relatively small sets of
> >users.
>
> Yeah.
As the work on the sparse-directories branch doesn't include a UI for
the command-line client, I have to agree with this. trunk currently
offers no one compelling Big New Feature which will tempt users to
upgrade their servers. (I noticed this refrain while reading through
the thread Hyrum started on the user's list -- write-through DAV
proxying was the most compelling improvement mentioned for which users
might be willing to upgrade their servers.)
> >So here's a counterproposal -- rather than continuing the recent trend of
> >fifteen Subversion committers all working on a individual features by
> >themselves, why don't more of the committers try directing a group effort
> >at
> >the Merge Tracking problem (the Big One Most Everyone Is Clamoring For)?
> >No
> >harm can come from having more eyes on the problem. And it's possible,
> >just
> >possible, that we can improve its delivery date in the process, if only by
> >improving the quality prior to the release stabilization period.
>
> +1
>
> And continually peeved that "merge the branch into trunk" didn't
> happen right after the summit like people had discussed. So here we
> are five/six months later without any serious visibility/testing on it
> because "oh wah wah, it isn't ready." It will NEVER be ready as long
> as it sits on a branch.
>
> Branches were supposed to be for features that could destabilize and
> needed to be evaluated before merging. Once it looked like they were
> reasonable, then you merge and complete them. I have no idea where the
> idea of "trunk is sancrosanct" came from, but it is death to important
> feature work. 1.4 is the stable, sancrosanct release. NOT trunk. "Does
> the feature generally work? Does it avoid mashing working copies? Does
> it keep server data intact?" All yes? Merge the thing. Only during
> that "this code will smear your WC over the drive" stage do you keep
> it separate.
>
> Am I being unfair because my time isn't contributed? Possibly. Maybe
> call me the peanut gallery. But I do know one thing from years of
> shipping stuff: what was done with the merge branch is NOT the way to
> get software shipped. It is really, really sad to see.
For quite some time now, I've been bemused to see everyone working on
their own thing, quite a change from Subversion development of the
past, where the community worked together to define goals, which the
development team voraciously attacked until they'd knocked'em out.
At last October's Subversion Summit, we the developers defined 1.5's
compelling new feature as Merge Tracking. Let's stand behind our
goal. As Greg says, the most realistic way to achieve this is to pull
the merge-tracking branch into trunk to catalyze our effort around a
compelling new feature. Yes, this is going to break some minor
things. But it will also focus our strength-in-numbers on a tangible
goal which we will reach much, much more quickly than with a couple
developers working independently on a now-mostly-stable branch. The
best way to deliver this new feature is to do it together.
Personally, I'm ready for this as I was not ready after the Summit
(having just become a father).
I propose:
1. Karl merges sparse-directories onto trunk.
2. Dan deals with the conflicts on the merge-tracking branch
introduced by Karl's merge.
3. Dan merges merge-tracking onto trunk.
4. Work continues on these features until at least Merge Tracking can
thoroughly handle merge history at any level of a merge target.
- application/pgp-signature attachment: stored
Received on Thu Mar 15 00:35:43 2007