Re: Proposal for reducing Subversion's lengthy (and unpredictable) release cycles.

On 13.06.2013 20:00, Greg Stein wrote:
> On Thu, Jun 13, 2013 at 11:29 AM, Branko Čibej <brane_at_wandisco.com> wrote:
>> On 13.06.2013 15:43, Daniel Shahaf wrote:
>>> C. Michael Pilato wrote on Thu, Jun 13, 2013 at 15:27:07 +0200:
>>>> In the interest of serving our user base, we are proposing that each release
>>>> live on the trunk for at most nine months. The first six months of this
>>>> period are open to new features. In the first three months of the new
>>>> feature period, large, destabilizing features will be accepted (under the
>>>> provision that the feature itself is arguably “complete”, which seemingly
>>>> implies that it was developed on a feature branch maintained with routine
>>>> sync merges.
>>> Or, where possible, developed on trunk within #ifdef THAT_FEATURE tags,
>>> with -DTHAT_FEATURE being disabled by default.
>> I'd have thought so too, but in fact, we're supposed to be writing a
>> version control system, so avoiding using branches for their primary
>> purpose (i.e., isolating lines of development) seems kind of
>> counter-productive.
> People don't pay attention to branches. That has been empirically proven.
>
> If you want eyeballs, then you code on trunk.

I have to disagree here -- even through you know I subscribed to that
point of view for a long time. But the thing is, all that we've really
empirically proven is that we, as a community, can't be bothered to
think about more than trunk, and/or more than the next .0 release. I'll
also point out that conditional blocks of code on trunk are just as
"invisible" to exactly the same majority of developers as code on
branches -- and they look messier to boot.

I submit it's time to change that. We've historically done everything on
trunk and "released when it's ready," and the result is that every
release takes longer to produce -- 1.8 was, I believe, by far the
longest in the project's history (apart from 1.0 of course, but that's
not relevant to this discussion). And the galling thing is that we
essentially had a nice set of features ready back in November, but there
was this "just one small thing" that has taken another half a year. From
today's point of view, the infamous 1.5 was blazingly fast. I at least
don't want something like that to happen yet again.

Moreover, we are now discussing features that will likely take years to
implement. I can't think of a sane way to do that other than on a
branch. OK, there are some exceptions, e.g., you can do a whole new
filesystem backend on trunk withour affecting other parts. But that's
the exception rather than the rule.

So instead of just waving a collective hand and repeating the old saw
about branches being invisible, I propose we instead invent ways to make
them visible. Starting by actually documenting a sane workflow based on
feature branches.

-- Brane

-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com