9 Jun
2011
9 Jun
'11
8:14 a.m.
On Jun 9, 2011, at 3:40 AM, Caleb James DeLisle wrote:
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.
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.
+1 to the idea, we need another position in change of stability.
On 06/08/2011 06:05 PM, Sergiu Dumitriu wrote:
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
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.
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. 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.