"Mark Phippard" <markphip_at_gmail.com> writes:
> 1) Take a serious look at the reintegrate option and what it does. If
> there are common scenarios that it does not handle but that your
> branch will, then you need to articulate those scenarios as best you
> can.
>
> 2) If you cannot find any, then I think a note from you that
> encourages us to branch for 1.5 now without your change would do a
> great deal towards getting us moving towards release.
>
> Everybody sees how much work you have put into that branch and so we
> are all hesitant to do the release without it. It just really seems
> like the reintegrate option handles the major scenarios that we are
> most concerned with and it would be best to just proceed towards the
> release.
I second Mark's points. The 2897 work is important, but it may
actually go beyond what we want to do in 1.5. We don't need 1.5 to be
everything under the sun; we just need it to do better tracking of
merges. 1.6 will do even more.
For comparison:
The branch for the sparse-directories work was created on August 9th,
2006, and not merged until March 21st, 2007. That's *8.5 months*
before it was merged (and we still had to do more work after merging
it). Also, what made it okay to merge was that people other than me
finally read, understood, and started changing that code. That was
key.
By contrast, the issue-2897 branch was created on November 22nd of
last year, so it's only about two months old now, for a problem of
similar complexity (in some ways less, in some ways more).
Two months is not a long time, really!
For those very familiar with the branch (especially Kamesh), mails
like this are perhaps a bit frustrating to read, because if the rest
of us would just take the time to understand the branch's code, we
would see that it is maintainable and solves important problems. I
sympathize, a lot. But as a group, we have to take perceived
complexity into account as a concern in itself, because we'll have to
maintain that code collectively. Until we really understand what it
does and how it interacts with the rest of the code, we shouldn't
release it. I'm not sure we can grok it in time for 1.5, that's all.
Improving our merge algorithms is something we should aim for over the
long term. If close inspection of 2897 during the 1.5 branch period
shows that it can get us better merges without imposing new
complexities that we or our users are not prepared to deal with, then
we can merge it in before 1.5. But it's also okay if we have to wait
until 1.6. (There is no way that 1.6 is going to take as long as 1.5
did, because we know not to try a release that big again.)
So, I hope this explains Mark's and my cautiousness.
Right now, my instinct is that we should branch 1.5 from trunk, and
not let 2897 block the 1.5 release; but we should be willing to merge
2897 into the 1.5 branch (via trunk, of course) if we are confident
that we understand what it does and that it won't be too destabilizing
in an already-large release.
Kamesh, does this sound like a good course to you?
Thanks,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-01-29 04:20:02 CET