On 3/14/07, Daniel Rall <dlr@collab.net> wrote:
>
> 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.
>
>
I posted something a little like this last week but hearing you Mike and
Greg all suggest it really causes me to agree. We should try to stay a
little more focused on the goals we set and see them to completion. The
features in trunk are useful, but we have told people that 1.5 will have
these (merge tracking, sparse directories) features and together they make a
great release.
Dan, these questions are probably for you, since you have led the merge
tracking effort.
This 1.5 discussion seems to be based on the "fact" that merge tracking has
6 more months of development. I do not recall ever hearing you give that
estimate. We are all developers, we know this could take 6 more months, but
what do you *think* it is going to take given the current resources working
on it? I think it would be bad for the community if we did 1.5 now, which
means a May GA and you guys wrapped the development in June/July. Now we
have to sit on the feature everyone wants because we just did a release.
Do you have a good handle on the work that is left? l have looked at the
TODO and it seems pretty thorough. If people had time to contribute:
a) Does the work that remains lend itself to parallelization or is it all
intertwined?
b) With a few more developers tackling parts of this, what sort of timeline
could we hope for?
c) Are you prepared to lead the effort in terms of guiding people that want
to contribute towards chunks of work that need attention?
I sense with some more developers, even more code review and smallish fixes,
we could talk about branching for the release in just a couple/few months.
I cannot personally contribute to the Subversion side, but I can start
trying to use it from Subclipse which might help shake out bugs and validate
the API.
FWIW, I was actually shocked that the users@ list had so many people that
thought we should wait. We basically said, you can have these new features
now, and it will not delay merge tracking and a large number of them said
they would rather we finish merge tracking.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on Thu Mar 15 01:14:09 2007