Re: Announcement/RFC: jhbuild continuous integration testing

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:

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

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.


Attachment: smime.p7s
Description: S/MIME cryptographic signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]