We don't have as much control over release timelines as we like to
think. Look at what happened with 1.3: a lot of the delay between
branching 1.3.x and making the first release was due to unplanned
minor nits that we discovered, well beyond the mandatory soak time.
One advantage of the shorter release schedule (appx every 4 months) is
that when a release encounters unpredictable delays, it still only
puts us out at 5 or 6 months, instead of 7 or 8. And if we don't
encounter delays, so much the better.
We've already heard from administrators who prefer more frequent
releases, and those who prefer less frequent ones. There's never
going to be a clear answer on that one, because different admins have
different needs.
As far as getting the serf changes into 1.4: isn't this committing
Error 33? It's way too early to predict how long the serf changes are
going to take. They shouldn't be figuring into Subversion release
schedules until they're closer to completion. I don't say they have
to be complete, just closer. The point is that inserting another
couple of months into the release cycle now would still have an
unknown effect on serf's chances of making it in anyway. Would it
raise the chances by 50%? 75%? 10%? No one has any idea (or if they
do, they're fooling themselves :-) ).
So let's please get a bit further with that code first. We're always
free to hold the door open if it looks like things are close. But we
should also make sure other useful changes don't block for an unknown
length of time on a feature still under development.
For these reasons, I favor David James's proposed timeline. We are
free to change it as we get closer to the branching date, depending on
how libsvn_ra_serf is going. (And we are also free to accelerate 1.5
for serf's sake, if it comes to that!)
-Karl
--
www.collab.net <> CollabNet | Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jan 29 23:01:31 2006