On Wed, 2013-02-13 at 23:08 +0000, Emmanuele Bassi wrote:
hi; On 13 February 2013 22:11, Colin Walters <walters verbum org> wrote:On Thu, 2013-02-14 at 06:42 +0900, Tristan Van Berkom wrote:I know, it sounds like some CPU will be melting quickly at the rate gnome-wide commits are made... but it would be simply awesome, if we could automatically pull out the exact commit which introduced exactly which failed build report in which module (and then as you mentioned, we probably need to notify both the author of the commit, and the maintainer of the effected module).If basically you want to ensure that each commit is buildable, the best way to do that is to have builders try *queued patches*, not just master.this is what the try server at Mozilla does: https://wiki.mozilla.org/ReleaseEngineering/TryServer the try server is a *great* tool (even if, sadly, is affected by Mercurial being arse) and it makes contributing code much, much safer. the try server can also be told to send the result of a patch set straight to a bug, so that the build status and the test suite result is recorded along with the bug.
I think gated commits like this could be a huge benefit to GNOME by automating basic checks (eg, coding style) and build/testing checks before maintainers review the patches and approve them (at which point, they should be automatically pushed to the real master repos). Contributors would get immediate or fairly quick feedback for their code passing or failing these checks and they wouldn't have to worry about breaking the upstream code (which I think would be a non-trivial gain for some new contributors). And maintainers would save some time on (inconsistently) enforcing basic checks, waiting on builds while reviewing, etc. And the whole stack would be more stable in terms of buildability and functionality. -Travis
Attachment:
smime.p7s
Description: S/MIME cryptographic signature