[xwiki-devs] [VOTE] Build Manager duty
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 * 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 Thanks -Vincent
+1 Thanks, Marius On 06/08/2011 08: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 * 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
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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 * 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.
* 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. -- Sergiu Dumitriu http://purl.org/net/sergiu/
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.
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.
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 ?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
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 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
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
Results: 6 +1, no 0, no -1 The vote is passed and is now documented at: http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HBuildMan... The Roster is here (linked from the page above): http://dev.xwiki.org/xwiki/bin/view/Community/BuildManagerRoster Thanks -Vincent On Jun 8, 2011, at 7: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 * 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
Thanks -Vincent
participants (5)
-
Caleb James DeLisle -
Marius Dumitru Florea -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol