On 06/08/2011 06:05 PM, Sergiu Dumitriu wrote: > On 06/08/2011 07:40 PM, Vincent Massol 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 I'm not sure about this. I think having the build manager be the same as the release manager for the entire release cycle would do more to foster responsibility since it is the developer who signs off on the build. On the other hand this is we would have to accept that the Release Manager is unavailable to do really anything else throughout the release cycle. >> * 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. > > In case of build agent problems, like broken metadata in the local > repository, build managers must have access to the machine. We need to > set up some secure way of providing that access. Having too many > accepted keys out in the open is dangerous. Having an account for each committer would go a long way toward security but instead of worrying about that I would be much more concerned with the iptables rules on the build engines. > > One option is to have only a few devs with access to the machines, and > the build manager can ask one of them to fix the problem. > > Another option is to let all the managers have access, but monitor the > access to the machine, or only allow certain IPs for each key. IP address based ACLs are broken by design. They rely on the integrity of a massively complex routing infrastructure which was never designed to be used as an authentication system. Besides that I have a dynamic IP addr. > >> * 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 > > Unless they have a valid reason to refuse for one week. Then we need to make sure that there is no way for a committer to escape the duty entirely by organizing their schedule so that they always have a valid reason when the time comes. > >> 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 as well. > +1 to the idea, we need another position in change of stability. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
