michael at laptop.org
Wed May 28 08:03:54 EDT 2008
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
(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
* 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
suggests one way to begin.
More information about the Devel