Re: Release early, branch later

On tor, 2008-09-25 at 12:40 -0600, Alex Rousskov wrote:

> Understood. Well, if we branch now, I think you will not have cycles to
> work on the above for at least a month, because of the back/forward
> porting overhead, _especially_ if the trunk becomes open again.

trunk being open is not that big problem for the maintenance, at least
not until there is some major surgery taking place such as moving
everything around crossing file boundaries (not just moving fies around)
or new indentation style. Bug fixes is easy to identify in the queue.

> I wonder if it would be more _efficient_ to make 3.1.0.1 snapshot from
> the branch in early October, followed by one or two more snapshots, and
> then a branching point sometime in November (depending on early 3.1.0.x
> feedback)?
>
> For example, this would allow us to finish the "source layout" project
> _before_ we branch, saving tons of time down the road. No matter how
> smart bzr is, I am sure that moving, splitting, and renaming 90% of the
> source files is going to complicate merging so it is better to do that
> before the branching point...

Indeed, as I said before.

Major surgery or restructuring of trunk should not take place during the
stabilization phase, as it will significantly increase the workload for
getting the branch stable. Such things should be done before branching,
when the current "stable" tree is mature and low-maintenance.

And it's no problem from a maintenance procedure point of view to merge
back some minor features if there is an overlap between next-version
features and needed features.

> > I like the idea. But what I've seen of the underlying website support
> > systems can't easily handle releases in HEAD which are not labeled 3.HEAD-X.
>
> Do we need those systems for a few temporary 3.1.0.x snapshots? Can we
> build and post them on the web site by hand?

I don't see why we should not branch trunk when starting to label things
as 3.1. But the structure do support having 3.1 reside in HEAD until
it's branched. This model has been used for both 3.0 and 2.6.

The practice of starting a stable branch in trunk has a number of
downsides:
  - trunk gets locked with no new features until branched, no matter how
well isolated or tested they are.
  - broken / unfinished things can not be backed out without risking
loosing them.

During the time window we talk about both of the above is quite likely
to need to happen. The first to not block new developments, the second
to let the branch stabilize as it's not that uncommon that testing for
stable reveals that changes in trunk isn't quite yet finished and needs
more work, and therefore unsuited for the sable cycle. (does not mean
they are inherently broken, just not quite finished)

Yes, having trunk open during the stabilization phase of the next
release also has it's down sides, but not as much as one may think. But
it's very very important that bugfixes gets committed separately from
new features, even if the bugfix is needed for and triggered by the new
feature.

Regarding stabilization, developers find most bugs while developing new
things, and locking trunk slows down the development of new things
considerably while everyone involved holds their breath waiting..

"end users" find most of the critical bugs, and hopefully files their
findings via bugzilla.

If the situation is that developers is less interested in helping out
fixing reported bugs because trunk is open then there is a major
problem. In 99% of the cases these bugs is relevant for trunk as well.
In my experience most developers do care about bug reports in the areas
they care for, no matter the state of trunk.

And there is another positive sideeffect of bugfixes going in via trunk
in that in many cases it's possible to ask the reporter to verify the
change in trunk before it gets merged into stable. This way the change
gets better tested, and as a sideeffect trunk in general gets more
testing.

Regards
Henrik