On Wed, May 28, 2008 at 02:54:24PM +0200, Marco Pesenti Gritti wrote: > On Wed, May 28, 2008 at 2:03 PM, Michael Stone <[EMAIL PROTECTED]> 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.
Awesome. Let me know if you get stuck as I can probably unstick you. > > 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?) > > 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.) > >> > >> 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? 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...). 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 > > * 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. Test cases make me happy; however, you can make me happy to accept your changes in other ways. > Also, executing the test cases and reporting to you about the results > is maintainer responsibility (either personally or through > volunteers)? It will vary from contract to contract. As I've said before - we'll work together to scrape up test resources. However, maintainers should definitely expect me to ask them to take some responsibility for testing their work. Michael P.S. - Surely Marco isn't the only one with questions about how this thing is going to work! _______________________________________________ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar