On Jun 9, 2011, at 3:40 AM, Caleb James DeLisle wrote: > > > 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.
I don't like this idea of having the same person because it's already hard enough to be a Release Manager and the point is exactly to lighten the load of the Release Manager. And being a Build Manager for 3 months in a row is way too hard IMO. Thanks -Vincent >>> * 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
