Thank you Emmanuele, this will really help with keeping GNOME building. I strongly support this change.
On Thu, 2016-01-21 at 14:54 +0000, Emmanuele Bassi wrote: > This effort led to various benefits, including JHBuild not constantly > being in a broken state, and most projects hosted on git.gnome.org > finally building when builddir != srcdir, which should improve the > ability of maintainers to do `make distcheck` on release days. The next step is to convert either jhbuild or gnome-continuous to use the others' modulesets. Currently the jhbuild modulesets are the official "what we release," and they are more important because they affect the ability of new contributors to build GNOME, so that's what I focus on maintaining. Continuous is useful to catch many build failures, but it misses many, many more failures than could only be detected were it to use the official modulesets. Continuous is a great first step (the response time is *stunningly* good) and we're better off now that we have it, but it's not good enough as it's not testing the build tool we use for development, it's not testing what we release. We need to test that each module builds with 'jhbuild build' with a completely empty install prefix, else there's no way to find and fix the bajillions of dependency errors in our modulesets. This is why new contributors say it is so hard to use jhbuild, so hard to get started. > What we need now, though, are "build sheriffs", i.e. people that > watch > the build process and ensure that it continues smoothly. Ideally, > every maintainer would be on IRC, and would join the #testable > channel; sadly, that's not the case. Anecdote: Because Empathy uses a crummy notebook for tabs, opening more rooms makes it much harder to switch between rooms and see which important once have changes, hence I minimize the number of rooms I join, hence I'm not going to join #testable as I am already in too many rooms. I bet I'm not the only one. If anyone wants to fix Empathy to have a saner view of rooms -- to use a sidebar like Polari, for example -- I would be willing to join way more rooms. > Many are not even on > #gnome-hackers, which means they miss the notification that the > something broke the build. Anecdote: I am on #gnome-hackers so you can ping me, but I don't turn on notifications for every message in the room (too many!), so it's rare that I notice a failure in one of my modules unless I happen to be looking at #gnome-hackers at the time, or someone else pings me. It would be really awesome if Continuous could learn to guess who to blame for breakage and include the IRC name in the channel; I know it's hard to decide who *actually* broke the build considering it could be due to a change in a dependency, but even a dumb guess like the people in the doap file for the broken project would be better than nothing, so at least the maintainer knows and can investigate. (This would also be incentive for past maintainers to remove their names from the doap file. :) It's not necessary -- Bugzilla works just as well, if slower -- but an enhancement to consider if someone has time to spare to implement it.... > - if nothing happens for a reasonable amount of time (I'd give one > to three hours) I would support even less time: five minutes (if the maintainer cannot be immediately contacted on IRC). Build breakage is a tremendous obstacle to new contributors. In contrast, once I've found the problem with a commit that got reverted, un-reverting it requires almost zero effort. So if I'm not immediately available to look at my broken commit, just revert it... no worries. Michael _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list