[sugar] Release process

[Marco Pesenti Gritti]

On Wed, May 28, 2008 at 4:32 PM, Michael Stone <michael at laptop.org> wrote:
>> > on unstable build
>> > streams under the manual control of individuals and teams,
>>
>> How is this different then joyride? Are these topic streams?
>
> As Scott said, Joyride is somewhere between an unstable build stream and
> a testing build stream. It's also under automated control insofar as it
> automatically pulls in changes made by anyone with commit access to the
> dist-olpc2 koji branch and to the joyride dropboxes on dev.
>
> I think of topic streams as being things like Dennis' F-9 branch, my
> rainbow branch, Bernie's X branch, etc. (One could plausibly argue that
> Joyride is a topic branch for the Sugar UI redesign - do you think this
> is true?)

Ok, I didn't understand from your definition that you was referring to
topic streams here. If we go down this way I'd rather have a Sugar
stream, it's not clear to me what went in joyride so far.

>> > 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?
>
> The basic idea is to give your build system enough information to
> automatically revert packages that look buggy. Debian does this by
> teaching their build system to talk to their bug tracker and by teaching
> their bug tracker how Debian packages work.
>
> A second approach is based on using buildbot/tinderbox continuous
> integration testing with automated test suites to qualify or disqualify
> changes.
>
> Both approaches give your build system enough information to rapidly
> revert packages that look buggy; however, both systems continue to
> suffer from the "garbage in, garbage out" problem.
>
> Consequently, I think that we are better served by manually improving
> the quality of the build stream inputs by encouraging people to do
> individual testing builds (or just to publish packages for review on top
> of an existing build) before pushing their changes into a shared build
> stream for wider review. (Think of this as the kernel maintainership
> model where changes originate small and private, then manually 'bubble
> up' in into wider and wider testing.)

I agree with you here.

And anyway I don't think the complex systems you are describing would
be ready in time to be useful for August release.

>> >  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...).
>
> It's going to vary from task to task. For small things, I'm perfectly
> happy receiving nothing more than a package to try out. For something
> big like the Sugar UI redesign, I'm going to need something a bit more
> systematic. Maybe we could settle make a list of example changes and the
> packaging events through which they were qualified?
>
> e.g.:
>
> Keyboard       - reviewed patches, then Koji-built packages tested by
>                 the submitter (Sayamindu), then test builds made by
>                 Dennis
>
> olpc-configure - Koji-built packages placed in joyride for
>                 several weeks,
>
> Touchpad       - patches, then an installation script to devel, then
>                 packages for joyride by the release manager, then
>                 inclusion in test builds along with a list of fixed
>                 bugs
>
> Wireless       - several revisions of the wireless firmware with manual
>                 smoke testing by the submitter, and several kernel
>                 patches to the stable kernel, a kernel build by the
>                 release manager, inclusion in a testing build by
>                 Dennis, then more serious independent network testing
>                 this week

A list of examples sounds like a good idea.

Personalized approaches for each change will require a *lot* of your
time and attention, which is a little scary. I hope it will scale
enough.

> P.S. - Surely Marco isn't the only one with questions about how this
> thing is going to work!

Yeah, I feel alone :)

Marco