The unintended "private email" CMike referred to a bit ago:
On Jun 13, 2013 8:13 PM, "Greg Stein" <gstein_at_gmail.com> wrote:
> On Thu, Jun 13, 2013 at 7:34 PM, C. Michael Pilato <cmpilato_at_collab.net>
> wrote:
> > On 06/13/2013 08:00 PM, Greg Stein wrote:
> >...
> >> 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.
>
> Wait. So if I boil down your lengthy explanation, you're saying "well,
> developing on trunk introduces bugs, too, so therefore we should use
> branches." Is that it?
>
> It seems that you've jumped to a "solution" before you have defined
> "stable".
>
> I believe you're defining "trunk is stable" as "if I release it right
> now, then our users won't be screwed". That's quite a long way from
> our current definition of "trunk is stable". Not disagreeing with the
> notion, but it seems that must be defined first.
>
> And it also sounds like there may be different definitions of "trunk
> is stable" based on which trimester the project is in. In the first
> trimester, we use the current definition? In the second, it tightens
> up to ???, and the third is the "I should be able to ship this"
> definition?
>
> When that stuff is defined, to a consensus position, then I think we
> can look at solutions. That may or may not be branch-based
> development. But I bet it will be more obvious. And we'll be able to
> better document/describe how our community likes to operate. And we
> can point to our rationale for time-based releases, stability
> guarantees at each point, etc.
>
> (and yes, at this pace, 1.8 would be unsupported in 18 months; adding
> one more release into the "supported" train extends that would to 27
> months, which feels about right)
>
> Cheers,
> -g
>
Received on 2013-06-17 20:42:15 CEST