On Sun, 2012-12-30 at 19:43 +0100, Cosimo Cecchi wrote: > Exactly, often a module was "red" because it needed a "git clean",
See https://bugzilla.gnome.org/show_bug.cgi?id=656081 I wrote that patch specifically for use in autobuilders. A lot of the reliability of the gnome-ostree build system versus jhbuild comes from *always* starting from a git clean -dfx tree; by using the --distclean option, jhbuild too can be a lot more reliable. (At a cost of some compilation speed, but if you're worried about that, first install and configure ccache) > for a missing dependency, or because the moduleset wasn't updated to > include a newer version of a dependency. Both of these are blocked on a sustainable way for multiple people to control the base set of packages installed on the build servers; see my other mail. > Finally, when a new module was added to the moduleset (usually a new > dependency), the build.gnome.org master instance itself needed a > manual restart to get the change propagated to the build slaves, and > this required pinging people with a SSH access to the server to do it. Honestly, the jhbuild-buildbot integration is well intentioned, but not worth the pain. It'd be *significantly* simpler and more reliable if a jhbuild-based build bot was effectively: while true; do sleep 1m; jhbuild build || post-irc-message; done Basically all of the jhbuild-buildbot glue work is so that modules can be in a build-or-not-building state *independently*, but that doesn't make any sense because we want to act aggressively on any failures - we don't want to let e.g. at-spi2-atk be in a failing state but still build gtk+. _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
