The unintended "private email" CMike referred to a bit ago: On Jun 13, 2013 8:13 PM, "Greg Stein" <gst...@gmail.com> wrote:
> On Thu, Jun 13, 2013 at 7:34 PM, C. Michael Pilato <cmpil...@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 >