On 06/13/2013 08:00 PM, 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.
>
> (and that seems fine, as long as your code does not *destabilize*
> trunk; with the "new rule", it also seems that any new "feature" needs
> to stay hidden until "ready", for some definition of "ready")
Unfortunately for the case you make, we have also empirically proven that
even if you do code on trunk, you are not guaranteed to get eyeballs or even
codepath executions.
This isn't 2004. The kinds of changes we're making are complex changes
which affect multiple areas of the codebase, often bringing dependencies on
new server-side capabilities, relatively non-trivial workflows, and so one.
*We* don't even use the kinds of workflows we're trying to write code for
on behalf of our users, and we certainly aren't popping up new experimental
installations of Subversion on svn.apache.org every other week so we can
exercise our own features, either.
The word "destabilize" has different meanings. We've always tended to use
"trunk is stable" to mean roughly, "trunk compiles and passes the tests".
As you well know, and as the past four (at least) major release cycles bore
out publicly, just because some body of work compiles and passes regression
tests does not mean that body of work is release-worthy -- that APIs and
behaviors introduced are of the sort that we want to live with and maintain
once they reach users hands and then indefinitely beyond as we honor our
compat promises. We can probably name at least one major "oops we didn't
think it would be that hard/take that long/cost that much" moment for every
release we've made over the last half-decade.
So in the context of the discussions today, and for the long-term health of
this community's relationship to an entire class (arguably the lion's share)
of its user base, I suggest that "stable" has to start meaning a little more
than that. That's the sole idea behind the "new rule". The rule isn't
arbitrary and is not the goal. Rather, it is a practical way to help us
achieve that goal, which is getting into a steady release rhythm.
Now, obviously, if you disagree with the goal, you will see this path toward
it as pointless. And for what it's worth, you'd be right. After all, why
would we need to care about the release-readiness of our trunk if releasing
was always something that could be put off until tomorrow when things might
be more stable?
That's how we've worked ever since the 1.0 release shipped. I (and others)
simply believe that as a project, we don't want to work that way any more.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Received on 2013-06-14 01:34:58 CEST