Hi committers, Even if I completely understand and agree with the goal pursued, I really dislike this way of solving it. It is the responsability of all of us to keep the build stable at all time. It should be the concerns of all recent committers to check if their recent commit breaks the CI, and to fix it ASAP when needed. If someone is not ready to do so in the upcomming hours following its commit, he should simply refrain to do that commit until he can follow it into the CI. I always follow these rules (even if most of the time, I commit only stuff that I have in production on my side), and I should admit that I would have commit more without them. But this is the necessary trade-off between evolutivity and stability.
Having someone to enforce such rules is admitting that some of us needs another one to remind them the best practices. This is not for me the philosophy behind Open-Source project, where everyone should do their best for the wellness of the project. So I could not admit there is a real need for this, and I really hope that everyone of us will understand the needs to move their cursor towards the stability of the build. So please guys, takes your responsibility without a need for a build policeman. Sorry, but I am -1 to do the policeman (but if I need to, I will do my duty), and I vote -0, just because I do not consider myself active enough to veto. Denis On Thursday, June 9, 2011, Thomas Mortagne <[email protected]> wrote: > On Thu, Jun 9, 2011 at 09:20, Vincent Massol <[email protected]> wrote: >> >> On Jun 9, 2011, at 9:08 AM, Thomas Mortagne wrote: >> >>> On Wed, Jun 8, 2011 at 19:40, Vincent Massol <[email protected]> wrote: >>>> Hi committers, >>>> >>>> We're having a hard time stabilizing our build (especially the functional test part, see my previous mail entitled "[VOTE] Important: Strategy to fix failing tests and stability"). Now I believe that it's going to be hard to enforce it and thus I'd like to propose a variation: >>>> >>>> * The Build Manager has the *responsibility* to get the build fixed ASAP whenever it's failing. His priority #1 during the week becomes monitoring the Build >>>> * By "Build" we mean the CI Build on ci.xwiki.org and by "failing" we mean anything that makes the build fail: tests, compilation, clirr, etc. >>>> * Every week we have a different Build Manager chosen amongst the Committers >>> >>> A week seems a bit short but in the other hand it will seems pretty >>> long for the Build Manager itself I'm sure ;) >>> >>>> * In order to fix build issues the Build Manager has several possibilities: >>>> - find out who caused the build to break and ask that person to fix it. That person cannot refuse that and must consider it his/her priority to fix it (or rollback the change that caused the build to fail) >>>> - rollback the issue that caused the build to fail >>>> - fix it himself/herself >>>> - find someone knowledgable in the failing domain and get him/her to fix the build. >>>> * At the end of the Week the Build Manager hands over his duty to the next Build Manager by contacting him/her. >>>> * We create a Build Manager Roster page on dev.xwiki.org to log past Build Managers (and possibly future ones if some have expressed the wish to be the Build Manager for a specific week). >>>> * All committers must perform this duty and take turns >>>> >>>> Since I've started doing this this week, I propose to take this role for the current week. I'm also proposing to log Caleb has having been the Build Manager for the past week since he's done a lot to stabilize the build. >>>> >>>> If the vote is passed I'll log this on the Committership page as a Committer duty (I'll also cross reference it from the Build page). >>>> >>>> Here's my +1 >>> >>> +1 >>> >>> What don't you think about designed people who broke the build the >>> most for the following week ? >> >> An interesting idea... >> >> However: >> 1) it's hard for flickering tests to find out the culprit >> 2) it's not so much a problem of breaking the build often, it's more a problem of not fixing it immediately when broken > > Sure, my really proposal was actually "design the most painful people > for Build Manager as build manager" but I wanted to find a better > metric :) > >> >> However I agree that in the Roster we could log information for the past week about who broke the build, how many flicker fixed, etc >> >> Thanks >> -Vincent >> >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > > > > -- > Thomas Mortagne > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
