[sugar] Release process

[Marco Pesenti Gritti]

On Wed, May 28, 2008 at 2:03 PM, Michael Stone <michael at laptop.org> 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
volunteers)?

Thanks,
Marco