Release process

[Michael Stone]

On Wed, May 28, 2008 at 11:44:07AM +0200, Marco Pesenti Gritti wrote:
> On Wed, May 28, 2008 at 8:00 AM, Michael Stone <michael at laptop.org> wrote:
> > Claims
> > ------
> >
> > I. There is no excuse for breaking centralized build streams that
> > others depend on when one-off 'topic builds' and dedicated build
> > streams are available. Please shout loudly whenever you could use a
> > topic build or build stream. They're very easy to make and if large
> > demand exists, it's straightforward to build better tool support.
> 
> I'm not sure to understand what you mean exactly here. Are we going to
> keep both a centralized unstable build (joyride) *and* decentralized
> topic builds?

My experience over the last few months has been that a centralized
unstable build stream is worth less than it costs to maintain using the
tools we've built today because it tends to aggregate changes of widely
varying quality without recording which changes are good and which are
bad. I now think that we are better served either by relying wholly on
decentralized topic builds for unstable development, on unstable build
streams under the manual control of individuals and teams, or on an
automated unstable streams only if they automatically quarantine
breakage. 

(If other people have found it to be a worthwhile tool, they are
certainly free to continue using it provided that they're willing to
take over some maintenance responsibility for the systems that implement
it. I simply have no desire to rely on it myself.)

> > IV. If we get bigger, then this will cease to scale and we would be
> > well advised to adapt something like the Debian automated filtration
> > process. However, at our present scale, I think I can get us better
> > results by personally negotiating each block of changes. Consequently,
> > with Dennis' help, I'm maintaining build streams for the 8.1.1 release
> > (this week) and soon, for the 8.2 (August) release. If you've made or
> > intend to make changes since 703 and haven't yet done so, you need to
> > come talk to me about how to we're going to release them!
> 
> Which build branch requires your approval and which doesn't?

Only the ones that I'm maintaining.

> I'm fine with personal negotiation, but we need to document how
> maintainers are supposed to negotiate inclusion in the builds and
> through which tools it concretely happens.

Fair enough. I'll propose a first draft:

  1. Contact me on devel@ or in the public IRC channels when you want to
     negotiate. I'll either tell you that I'm busy or I'll talk with
     you. You should be prepared to explain what your changes do and why
     you think they're good.

  2. After we talk, we'll each have a better idea of how things will
     proceed, e.g. 
     
       * when you'll have packages ready for me to try out,
       * what bugs I should try to test carefully, 
       * what areas I need to watch for regressions, 
       * and what other work I might be doing that you could help with
         so that I can get to your changes sooner.
 
  3. These issues are complex and they change over time so we'll need to
     talk regularly in order to apprise one another of status changes
     and to make up answers to questions that we couldn't answer during
     the previous conversation.

  4. We should record the results of these conversations for future
     reference, presumably on the wiki or in Trac. I have a mild
     preference for the wiki because I think we're going to want to edit
     intermediate drafts of these plans but I can be easily persuaded
     toward other systems. The stub at 

       http://wiki.laptop.org/go/User:Mstone/Release_queue

     suggests one way to begin.

Comments?

Michael