On Thu, Jun 13, 2013 at 9:06 PM, Branko Čibej <brane_at_wandisco.com> wrote:
> On 13.06.2013 20:00, Greg Stein wrote:
>...
>> 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
I concur with your assessment. Such is the nature of volunteers :-)
> 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.
Depends on how much you #ifdef away. Julian's experimental obliterate
stuff was mostly present, for everybody. The only thing "hidden" was
its visibility at the command line.
> 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
Euh... did you go into a coma during 1.7? :-P
1.7 was the longest, at a full 31 months. Then 1.5 at 21 months, and
1.8 at 20 months.
[ http://subversion.apache.org/docs/release-notes/ ]
> 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.
Sure. And I think CMike's original note about time-based releases will
fix this. Then, he continues on a phased-approach to "stability", but
I believe that requires more definition.
I have *no* problem with time-based releases. You may recall back in
2001, that I put myself and The Chicago Four onto cranking out
releases every two weeks. To this day, I believe that the change in
activity level, and the constant stream of new work really helped the
project.
There isn't much stopping a similar style of effort today. Apache
"rules" allow an RM to make a release at any time, as long as they get
three +1 votes. That RM could branch trunk after six months of dev
work, and then cherry-pick stabilization fixes for the next three
months, and then begin release candidates. Nothing stopping anybody
from doing that, beyond the simple fact of trying to stabilize a
moving target without some level of help/cooperation from the devs.
But we don't put our RMs into that position. As a community, we help
out the RM according to certain consensus policy. I see CMike's email
(and its reflection of the Hackathon participants) as a suggestion
towards adjusting that policy. Cool.
It just seems that we need to figure out that consensus in more detail
before offering "solutions". Personally, I have some more issues with
the proffered solutions, than the originating policy changes.
> 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.
Agreed. That's why we let a total newcomer develop svnrdump right in
trunk. It really didn't affect anybody, and it was dead easy to remove
if we felt it wasn't ready for shipping.
[ unfortunately, it has created some issues that nobody saw, but
that's the nature of the game; we would have missed those deeper
problems even using a branch-based approach ]
> 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.
Fair enough. But I think you're talking about Step Two. There is more
work on what "stable" means, what time schedules to use, etc. That's
Step One.
(well, figuring out a "sane workflow" can certainly be developed in
parallel, but I'll continue to posit there may be other solutions)
Cheers,
-g
Received on 2013-06-14 04:30:56 CEST