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
signature.asc
Description: This is a digitally signed message part