On Wed, May 28, 2008 at 4:32 PM, Michael Stone <[EMAIL PROTECTED]> 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 _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
