develooper Front page | perl.perl5.porters | Postings from June 2009

The Other Timeboxing (was: Perl 5.10.1)

Thread Previous | Thread Next
Aristotle Pagaltzis
June 24, 2009 03:29
The Other Timeboxing (was: Perl 5.10.1)
Message ID:
* Aristotle Pagaltzis <> [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

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?

Aristotle Pagaltzis // <>

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About