Front page | perl.perl5.porters |
Postings from June 2009
* Aristotle Pagaltzis <pagaltzis@gmx.de> [2009-06-24 12:00]: > I’m not advocating to roll a release the moment a fix for an > accidentally released regression is checked in either. There > has to be some testing, obviously. > > But I think what’s absent from much of the debate right now is > that the reality is that regressions do get released; 5.10.0 > did happen. Because another reality is that users can’t be made > to care about release candidates no matter how much we’d like > them to and how annoying that may be to pumpkings who want to > do their work diligently. So what might work better? The standard strategy to achieve timeboxing goes like this: every new feature is developed on a branch, and when the time to release rolls around, any branches deemed stable are merged and the resulting combination of features, whatever it happens to be, becomes the new release. I have seen two solid objections to this: 1. Features in a programming language are not all independent. You can’t just bundle a random collection of stuff and get a coherent result. 2. Merging branches once they are stable is a chicken-egg problem; you cannot stabilise a feature fully without first merging it and seeing what happens. Arguably, #1 is why Perl 6 started over from scratch. Some of you on this list may have a particular opinion about *that*. But it’s a valid argument. So is #2. One partial counterargument to #1 that immediately suggests itself is: not all branches are going to be cross-cutting features. Some will be simple bug fixes. (Which I think should happen off trunk too; an argument is to avoid slightly dodgy fixes after all.) Some will be rather isolated additions, like my `length undef` proposal that was accepted and implemented. So while you can’t give all features the same “time to release, this is stable, let’s merge it” treatment, there is an appreciable portion of work for which this is the case. No one said that all branches have to be regarded as being of exactly the same import. The other argument, that stability as a prerequisite to merging creates a circular dependency, is more interesting. To me, this suggests timeboxing the roadmap instead of the release. Let me explain. Let’s assume that the maintainers have decided to aim for tri- annual releases – note this is not a fixed release schedule. Then, three weeks (say) ahead of projected release time, branches are evaluated for their fitness, and a decision is made about which of them will be included in the next release. Once picked, they are merged into trunk, and further work on trunk then focusses on stabilising this compound. This implies an end to further feature work on those branch. If whoever is working on the branch in question still wants to improve it further, they can beg off for that release; then they can keep working on the branch, independently of the trunk. Once the release has been cut, open branches have to merge in the new release, so they won’t diverge from trunk to the point of big headaches in the future. Given some experience, the pumpkings should be able to make a good estimate for how big a bite each release stabilisation cycle can take out of the branch plate, and thus be able to keep to the projected schedule closely enough. Sound sane? Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>Thread Previous | Thread Next