Re: My views on release management
Brandon Mitchell wrote:
> And for debian's sake, I hope it works. I have my doubts, mainly because
> I think you have identified some problems and some effects, but I fear you
> haven't found all the true problems and therefore may be trying to fix an
> effect.
*grin* Are you suggesting that Debian should solve the general problem
of software engineering? I don't think we will ever find all the true
problems, but I look forward to a glorious future of gradual refinement.
The more radical solutions are all based on the idea that we should
have a release process that will always have a release candidate
ready. This idea is based on sound principles, and I think it's good.
When I said these solutions were not ready for use, I did not intend
to discourage anyone from working on them. I'm just not about to base
a release management plan on an idea that's still unformed.
So far, we seem to be agreeing :)
> I do believe you will fill the release managers roll nicely, but
> another fear is that your solutions may not work for a successor.
That doesn't worry me... a successor will just have to get his own
solutions :) In fact I'd be worried about a successor that didn't
come with definite plans.
> The other solutions look at radical changes. I'd be interested to hear
> what problems you have had implementing other solutions.
Well, off the top of my head:
- We need new code, of a most sophisticated kind. We'll need
to be able to automatically enforce a number of invariants on
the dependency web in an archive, and to figure out which packages
can be safely installed in which combinations.
- Packages have wildly different release characteristics. Bdale Garbee
said that most packages have short periods of "churn" followed by long
periods of stability, but that doesn't apply to _all_ packages. Consider
ones like wine, that make a new snapshot every two weeks.
- All of these solutions (except the package pool) involve moving
package files around. This is Bad for the mirrors. The package pool
has a different problem: it's hard to make a partial mirror.
- How would the project migrate to a completely new system? We have
too much mass now to make a clean break. I think the best way is to
start with a "research archive" that uses the new system to maintain
a sort of "shadow Debian".
- It will be difficult to make changes in what's expected of maintainers.
Fortunately we now have a Constitution that provides a framework for
making such changes.
None of these problems are intractable, but I think that it will take
at least a year to change to a new system. Lately you've been refining
these ideas into a more low-key solution, though. I'm interested to
see what comes out of that.
> The symptoms/effects:
> 1) long freezes
> 2) lots of package updates near beginning of freeze
> 3) previous versions of good packages are removed in unstable by updates
> with the potential to introduce bugs
Point 3 doesn't look right to me. Most updates will fix bugs and
introduce new ones at the same time.
> Some problems:
> 1) too many developers working on new packages in comparison with those
> working on the next release
I haven't observed this. Many developers seem eager to help with
the release. What I have seen is that Debian activity in general seems
to be high one month and low the next. Obviously the release should
be staged during a high month :-) (Can anyone hand me a predictor
function for this?)
Eagerness to help is not enough, however, because the nature of things
is that the release will be delayed by the problem that gets the least
attention. One aspect of release management is to stick big warning
signs on problems that are being forgotten.
> These thoughts are simply so they go in the archive for the next time we
> need to talk about this. Richard, if you would like, I'm willing to make
> a formal proposal. I think you would prefer to try your way and I'm more
> than happy to respect that.
Thanks :)
Richard Braakman
Reply to: