On Thu, Jun 13, 2013 at 9:06 PM, Branko Čibej <br...@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
