On Wed, Jun 8, 2011 at 19:40, Vincent Massol
<vincent(a)massol.net> 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
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