9 Jun
2011
9 Jun
'11
2:11 p.m.
Hi committers,
Even if I completely understand and agree with the goal pursued, I
really dislike this way of solving it. It is the responsability of all
of us to keep the build stable at all time. It should be the concerns
of all recent committers to check if their recent commit breaks the
CI, and to fix it ASAP when needed. If someone is not ready to do so
in the upcomming hours following its commit, he should simply refrain
to do that commit until he can follow it into the CI. I always follow
these rules (even if most of the time, I commit only stuff that I have
in production on my side), and I should admit that I would have commit
more without them. But this is the necessary trade-off between
evolutivity and stability.
Having someone to enforce such rules is admitting that some of us
needs another one to remind them the best practices. This is not for
me the philosophy behind Open-Source project, where everyone should do
their best for the wellness of the project. So I could not admit there
is a real need for this, and I really hope that everyone of us will
understand the needs to move their cursor towards the stability of the
build.
So please guys, takes your responsibility without a need for a build
policeman.
Sorry, but I am -1 to do the policeman (but if I need to, I will do my
duty), and I vote -0, just because I do not consider myself active
enough to veto.
Denis
On Thursday, June 9, 2011, Thomas Mortagne <thomas.mortagne(a)xwiki.com>
wrote:
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
On Thu, Jun 9, 2011 at 09:20, Vincent Massol
<vincent(a)massol.net> wrote:
>
> On Jun 9, 2011, at 9:08 AM, Thomas Mortagne wrote:
>
>> 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
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs