On Thu, Aug 07, 2008 at 01:21:40PM -0400, C. Michael Pilato wrote:
> Karl Fogel wrote:
> > So I guess I'm sort of surprised that we're having trouble agreeing to
> > such a low-risk, high-(potential)-payoff experiment...
>
> To quote Mark: "What he said"
Good morning everyone,
After reading everything which has accumulated over night
in this thread (from the point of view of my timezone), I get the
impression that the following are the options being discussed:
1). Let Mark, Senthil and whoever wants to join their effort
create a feature-branch based on 1.5.x. Complete work on the
desired features in trunk and backport them to this branch.
The backport of the desired features happens in our public
repository.
To prevent version confusion among our users, vendors are
asked to ship binaries compiled from this branch to the general
public only if they are explicitly designated as not being based
on the official Subversion-1.5.x code, because they contain
features not present in stock 1.5.x.
Users of the feature branch are effectively acting as
beta-testers for the new features before they officially
ship in 1.6 at the end of this year.
2). Complete the desired features in trunk and ship 1.6 early,
partly in order to avoid version confusion among users caused by
binaries compiled from the feature-branch, and partly to get the
desired features out to all of our users and not just users of
the feature-branch.
There is no beta-testing except for the soak period.
Only binaries based on officially blessed 1.6 code are shipped.
Confusion about different versions among users is avoided.
Everything happens in our public repository.
3). Don't do any of the above, and let Mark, Senthil and whoever
wants to join their effort manage a patched Subversion 1.5
in private. Release 1.6 as originally planned.
It seems no one wants option 3.
Mark, Karl, Lieven, Arfrever and Michael said they favour option 1.
Justin seems to favour option 2, but also said that one of the
problems he'd see with option 1 would be vendors shipping binaries
designated as "Subversion 1.5" from the feature branch. It seems
that virtually everyone agrees that this is an issue, so I made
this condition part of option 1 above.
The other issue with option 1 being that it makes the features
available early only to users of the feature branch until 1.6 is
released.
Martin Furter and Peter also expressed agreement with option 2.
Blair is against option 2 because he wants to use the time until
1.6 release to complete file externals work.
I myself am -1 on option 3, +0 on option 2 and +1 on option 1.
I think option 1 is the most reasonable option because:
- Nobody is forced to help working on the feature-branch.
People who don't want to work on it can just ignore it.
OTOH, if we released 1.6 now, many of us would probably be
inclined to help with release stabilisation, taking time
away from other things.
- The features will be shipped to all users in 1.6 anyway.
1.6 is scheduled to be released in about 4 months,
this is not a very long time.
- I think the features receiving beta testing in a real environment
is a good thing, because there may still be bugs lurking here and
there (some known, e.g. issue #3226). Anyone who wants to help beta
testing the features can compile their own builds from the feature
branch (or trunk, for that matter, but that is probably less safe
in production environments).
- It also gives people time to complete work they'd like to see in
1.6 as planned. I'd like to fix issue #3226, Blair would like to
finish file externals, Arfrever would like a bunch of features to
be ready. And I don't think this implies that anyone would block
the 1.6 release as originally scheduled, even if some feature isn't
ready by then. We've learned our release-disaster lessons, right? ;)
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-08-08 13:26:34 CEST