Setting a 1.7 branch goal

["Hyrum K. Wright" <hy...@mail.utexas.edu>]

I've been visiting with a number of users and other interested parties about the future of Subversion, but one of the things I'm constantly hearing is "when will 1.7 be released?"  It'd be nice to be able to address that. :)

1.7 will be an important release, but it feels as if we've been stalling a bit lately.  I'm excited to see Mike, Julian and other getting involved, and I think the work we've left to do is well-scoped (if not well understood by everybody yet).

In the past, we've been hesitant to commit to a specific date, but I think making such a commitment to ourselves would be both useful and motivating.  To kick things off, I propose the following:
* We shoot for a mid-May branch date, say May 15.
* We can use the June Berlin hack-a-thon to do a final push for any bugs which have popped up during the RC phase (or a push toward an RC if something postpones the branch date).
* A final release happens sometime mid-summer

I'd be very happy if this process were to accelerate, but I think as things look right now, the above looks reasonable.

Thoughts?

-Hyrum

Re: Setting a 1.7 branch goal

[Julian Foad <ju...@wandisco.com>]

C. Michael Pilato wrote:
> Hyrum K. Wright wrote:
[...]
> > In the past, we've been hesitant to commit to a specific date, but I
> > think making such a commitment to ourselves would be both useful and
> > motivating.  To kick things off, I propose the following:
> >
> > * We shoot for a mid-May branch date, say May 15.
> >
> > * We can use the June Berlin hack-a-thon to do a final push for any bugs
> > which have popped up during the RC phase (or a push toward an RC if
> > something postpones the branch date).
> >
> > * A final release happens sometime mid-summer
> > 
> > I'd be very happy if this process were to accelerate, but I think as
> > things look right now, the above looks reasonable.
> > 
> > Thoughts?
> 
> I think folks' hesitation in the past to commit to a date has been less the
> result of laziness and more the result of self-awareness.  Subversion is a
> volunteer community, and for most of our volunteers, I think the risks are
> pretty low.   Whether we ship 1.7 in the Summer or the Fall of the year is
> of little measurable consequence to them.  That's not a bad thing, and
> please don't assume that I mean otherwise.  I'm just saying that I believe
> the inherent riskiness of deadlines (note the "dead" in the first half of
> the word) is at odds with a workforce that, for the most part, doesn't bear
> the burden of any risk.  In such a universe, the motivation to contribute
> has to come from something other than a somewhat arbitrarily chosen deadline.
> 
> Of course, none of this means that those who *are* so motivated can't decide
> for themselves to embrace the challenge of a deadline, and the dates you
> present are as good as any to embrace.  I have faith that if, in fact,
> Subversion is beta-ready by mid-May, our community as a whole will accept
> the recommendation of branching for stabilization at that point.
> 
> So if you're game and I'm game, then let's call it a challenge we accept.
> If our corporately-sponsored peers are game, too, all the merrier.  And if
> anyone else reading this comes bearing preexisting motivation but lacks a
> challenge at the moment, we welcome you to the table, too!

Hmm... that makes sense, Mike. OK, I accept the challenge.

- Julian

Re: Setting a 1.7 branch goal

["C. Michael Pilato" <cm...@collab.net>]

Hyrum K. Wright wrote:
> I've been visiting with a number of users and other interested parties
> about the future of Subversion, but one of the things I'm constantly
> hearing is "when will 1.7 be released?"  It'd be nice to be able to
> address that. :)
> 
> 1.7 will be an important release, but it feels as if we've been stalling
> a bit lately.  I'm excited to see Mike, Julian and other getting
> involved, and I think the work we've left to do is well-scoped (if not
> well understood by everybody yet).
> 
> In the past, we've been hesitant to commit to a specific date, but I
> think making such a commitment to ourselves would be both useful and
> motivating.  To kick things off, I propose the following:
>
> * We shoot for a mid-May branch date, say May 15.
>
> * We can use the June Berlin hack-a-thon to do a final push for any bugs
> which have popped up during the RC phase (or a push toward an RC if
> something postpones the branch date).
>
> * A final release happens sometime mid-summer
> 
> I'd be very happy if this process were to accelerate, but I think as
> things look right now, the above looks reasonable.
> 
> Thoughts?

I think folks' hesitation in the past to commit to a date has been less the
result of laziness and more the result of self-awareness.  Subversion is a
volunteer community, and for most of our volunteers, I think the risks are
pretty low.   Whether we ship 1.7 in the Summer or the Fall of the year is
of little measurable consequence to them.  That's not a bad thing, and
please don't assume that I mean otherwise.  I'm just saying that I believe
the inherent riskiness of deadlines (note the "dead" in the first half of
the word) is at odds with a workforce that, for the most part, doesn't bear
the burden of any risk.  In such a universe, the motivation to contribute
has to come from something other than a somewhat arbitrarily chosen deadline.

Of course, none of this means that those who *are* so motivated can't decide
for themselves to embrace the challenge of a deadline, and the dates you
present are as good as any to embrace.  I have faith that if, in fact,
Subversion is beta-ready by mid-May, our community as a whole will accept
the recommendation of branching for stabilization at that point.

So if you're game and I'm game, then let's call it a challenge we accept.
If our corporately-sponsored peers are game, too, all the merrier.  And if
anyone else reading this comes bearing preexisting motivation but lacks a
challenge at the moment, we welcome you to the table, too!

-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Re: Setting a 1.7 branch goal

[Stefan Sperling <st...@elego.de>]

On Sat, Feb 13, 2010 at 10:46:51AM +0100, Bert Huijben wrote:
> I don't think we should set a specific date unless we are willing to cut
> features at that date.

I agree on not setting a date.

> And if we would cut WC-NG, we would have to cut most of the libsvn_client
> stuff too as we implemented svn patch and other features on top of WC-NG.

Well, what is left if you cut WC-NG? Some bugfixes we haven't backported,
and svn patch, HTTPv2, and the first baby steps of an obliterate feature.
Anything else I forgot? Definitely not much.

E.g. svn patch is a nice handy tool, but it's not a killer feature.
The world won't end if it isn't released by next week.
But we really need WC-NG to move Subversion forward, as a whole.
Without WC-NG, we can't make improvements we want, well, need, to make
in future releases.
 
And I don't think delaying the 1.7 release cycle is comparable to
what happened with 1.5.

In 1.5, merge-tracking was added on top of an *existing* stable code base.
The feature was highly anticipated because it had merits of its own.
It also happened to be hard to design and implement, and took several
point releases until it became stable enough for general use. This is
what caused the delay of the 1.5 release. Along with another part of the
problem, which was that merge-tracking was heavily advertised as Subversion's
new killer feature which would definitely be in 1.5. The expectation was set
by marketing, and no attempt was made to revert this expectation once set.
So people got impatient and some even disappointed.

With WC-NG, we're in a completely different situation.
While we cannot avoid the first problem (hard to implement), we can certainly
avoid the second problem (setting unrealistic expectations).

WC-NG is *not* a "new feature", but a major rewrite of a major part of the
guts of Subversion. If it wasn't for WC-NG, we could declare Subversion
as done, move the 1.6.x code base into CVS-style maintenance mode, and stop
adding features and stop fixing existing major problems.
WC-NG does not have merit on its own, but is needed so that Subversion can
continue moving forward. We will be implementing new features, and fix
currently unfixable problems, on top of WC-NG. If we don't, then WC-NG is
simply a huge waste of time.

So it's well worth giving it all the time it needs to mature and stabilise.
Even if that means not releasing for a while. If it's not mature and usable
when it's finally released, i.e. unfit to serve as a solid base for future
improvements, we have missed our target. I'd rather never release 1.7 and
spend time fixing smallish, and fixable, problems in 1.6 instead. Our users
don't need another unfit or even unfixable working copy implementation.

Of course, we really need more people spending time on WC-NG development.
Which does not necessarily mean that we add more people to the team hacking
the core WC-NG code. For example, once svn patch is releasable, I am planning
to systematically test WC-NG's behaviour when faced with tree refactorings.
I'll report any problems, and add or improve regression tests.
I already encountered and reported a bug with deleting children of copied
directories. I'd like to know if there are more bugs like this hidden in the
design and implementation. With 1.7 and onwards, I'd like to be able to rely
on WC-NG to handle arbitrary tree refactorings really, really well.
This is a must-have requirement for better tree conflict support.

Developers with some time to spare but not enough to dive into core WC-NG
development can make a big difference by doing similar things, making
sure WC-NG is fit for features and improvements they want to add on top of it
(maybe we should make a list of such features and improvements :)
We need to test it thoroughly now (before, not after, 1.7 release) to make
sure the design and implementation does deliver what we need it to deliver.

Stefan

RE: Setting a 1.7 branch goal

[Bert Huijben <be...@qqmail.nl>]

> -----Original Message-----
> From: Hyrum K. Wright [mailto:hyrum_wright@mail.utexas.edu]
> Sent: vrijdag 12 februari 2010 20:57
> To: Subversion Development
> Subject: Setting a 1.7 branch goal
> 
> I've been visiting with a number of users and other interested parties
> about the future of Subversion, but one of the things I'm constantly
> hearing is "when will 1.7 be released?"  It'd be nice to be able to
> address that. :)
> 
> 1.7 will be an important release, but it feels as if we've been
> stalling a bit lately.  I'm excited to see Mike, Julian and other
> getting involved, and I think the work we've left to do is well-scoped
> (if not well understood by everybody yet).
> 
> In the past, we've been hesitant to commit to a specific date, but I
> think making such a commitment to ourselves would be both useful and
> motivating.  To kick things off, I propose the following:
> * We shoot for a mid-May branch date, say May 15.
> * We can use the June Berlin hack-a-thon to do a final push for any
> bugs which have popped up during the RC phase (or a push toward an RC
> if something postpones the branch date).
> * A final release happens sometime mid-summer

I don't think we should set a specific date unless we are willing to cut
features at that date.

At this time we would have to cut WC-NG as it misses certain stability
guarantees. 

If you press ^C somewhere during update you can now have half updates on
files (the data, but not the conflict or its properties, etc.). WC-NG must
be 100% stable or not part of the release.

And if we would cut WC-NG, we would have to cut most of the libsvn_client
stuff too as we implemented svn patch and other features on top of WC-NG.

> 
> I'd be very happy if this process were to accelerate, but I think as
> things look right now, the above looks reasonable.

On Subconf 2009 we had an indicative calculation of getting to a single
administrative area around January and working copy format stable early
after that; Beta around April and release around June.

I don't see us getting to a single administrative area in the next few
weeks.. so just hoping for a beta around may would be a gigantic increase in
development speed while no major milestones have been reached since October.
(The in-DB properties code was working then, but still not in use as primary
property storage)

And before beta we have to get a stable working copy format. We can't ask
beta users to expect their working copies to be incompatible broken. (Of
course we can still change it if we find design bugs, but we can't go into
beta with known issues that have to resolved later)



Getting a group of new developers focusing on WC-NG will only get us an
acceleration when these developers already have all the knowledge required.
Providing that knowledge to them causes an initial slowdown. (Read any
software project management book about this)



Yes, I would like to speed up the development, but just throwing a date on
the table won't help :(

I wish I could spend more time on WC-NG but my $dayjob doesn't sponsor
development work on Subversion and free time is spare with a baby in the
house. 

And the Windows buildbot out of order delays starting up development every
time as there are still unresolved Windows test failures..

	Bert