Release process

Marco Pesenti Gritti mpgritti at
Wed May 28 08:54:24 EDT 2008

On Wed, May 28, 2008 at 2:03 PM, Michael Stone <michael at> wrote:
> 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,

We will try to find time at linuxtag to experiment with these for Sugar.

> on unstable build
> streams under the manual control of individuals and teams,

How is this different then joyride? Are these topic streams?

> or on an
> automated unstable streams only if they automatically quarantine
> breakage.

Can you elaborate on how breakage would be quarantined? How difficult
it will be to build infrastructure for it? Do we have time to do it
for August?

>> Which build branch requires your approval and which doesn't?
> Only the ones that I'm maintaining.

And you maintain the stable builds for 8.1.1 and 8.2.0, correct?

>> 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,

We need to tell people how they should build these packages and how to
let you try them out (provide a custom build, get them in one of the
unstable streams, just provide one or more rpms to install on the base
of the current stable build...).

>       * what bugs I should try to test carefully,
>       * what areas I need to watch for regressions,

Do you still want test cases for each change? If so I think it should
be made more clear.

Also, executing the test cases and reporting to you about the results
is maintainer responsibility (either personally or through


More information about the Devel mailing list