On Tue, 2013-02-12 at 07:43 +0100, Martin Pitt wrote: > Hello fellow GNOME developers, > > this already came up as a side issue recently[1], but now we are at a > point where have reasonably stabilized our GNOME jhbuild continuous > builds/integration test server to become actually useful: > > https://jenkins.qa.ubuntu.com/view/Raring/view/JHBuild%20Gnome/ This is really nice and exactly something we need. Thank you and Jean-Baptiste very much for setting this up! > Build failures: > - folks: this started failing very recently, and thus is a perfect > example why this is useful (unqualified ambiguous usage of > HashTable) I was not aware of this (as it's a recent break due to libxml changes). I'll discuss notifications below. And, at any rate, we've fixed this now. > To make this really useful, we can't rely on developers checking this > every hour or every day, of course; instead we need push notifications > as soon as a module starts failing. That's the bit which needs broader > discussion and consent. > > I see some obvious options here what to do when the status of a module > (OK/fails tests/fails build) changes: > > (1) mail the individual maintainers, as in the DOAP files > (1a) do it for everyone, and let people who don't want this filter > them out on a particular mail header (like "X-GNOME-QA:") > (1b) do this as opt-in > > This most often reaches the people who can do something about the > failure. Of course there are cases where it's not the module's fault, but a > dependency changed/got broken. There is no way we can automatically > determine whether it was e. g. a deliberate API break which modules > need to adjust to, or indeed a bug in the depending library, so we > might actually need to mail both the maintainers of the module that > triggered the rebuild, and the maintainers of the module which now > broke. > > (2) one big mailing list with all failures, and machine parseable > headers for module/test > > This might be more interesting for e. g. the release team (we can > CC: the release team in (1) as well, of course), but will be rather > high-volume, and pretty much forces maintainers to carefully set up > filters. > > My gut feeling is that we might start with (2) for a while, see how it > goes, and later switch to (1) when we got some confidence in this? > > Opinions most welcome! I'd like to offer: (0) auto-file an urgent/critical bug against the module in the case of build breaks (and maybe high/major for test breaks?) Buildability is incredibly important, and I, for one, would be perfectly happy to get such high-priority bugs if my module fails to build for anyone. And it's even more critical if we expect people to use a tool like jhbuild, where any build break lower in the stack wastes other developers' time. Getting everyones' tests to run reliably will be a challenge (there are a couple tests in Folks that I'm trying to fix currently), but it's again very important to be (and stay) functional if we want our stack to work consistently. > Also, I'll gladly work with the developers of the currently failing > modules to get them succeeding. I have full access to the build > machine in case errors aren't reproducible. Thanks again. I'm really excited to have a continuous build and testing system to keep GNOME in good shape. -Travis
Attachment:
smime.p7s
Description: S/MIME cryptographic signature