On 15/05/2014 10:19, Anil Madhavapeddy wrote:
> On 15 May 2014, at 09:57, Lars Kurth <lars.kurth@xen.org> wrote:
>
>> All the existing committers have voted in favour. So the proposal carries. I will update the XAPI webpage http://www.xenproject.org/developers/teams/xapi.html accordingly
>> Lars
>>
> This isn't intended to affect the voting, but I would note that it's slightly odd for an open-source project to switch its committers in such a big sweep without at least some discussion about how this affects the overall project direction.
Actually, thinking about it *could* affect the direction of the project
for anything that is related to global votes. And we *do* need to have a
discussion about it. And we *may* need a process change or
clarification, but I don't think so as the process was originally
designed to cover a gradual increase in the number of subprojects.
Thanks Anil for pointing this out. I was too overloaded to really spot
this : Apologies.
== Different Expectations when to award maintainer status ==
First there is the observation in that:
* There are significant differences when it comes to when (aka under
which criteria) committer status is awarded between subprojects and
there are also difference in view within subprojects
* XAPI does not have the maintainer role as far as I understand. In
other words in XAPI maintainer=committer. Please correct me if I am wrong.
== Process implications ==
Looking at the governance process:
http://www.xenproject.org/governance.html
Maintainers and committers have the right to vote in some circumstances.
Now we have local (within subproject) and global votes (affecting all
projects). What the process states specifically when it comes to voting is:
* The role of committers in electing other committers and project leads
- this is subproject local. As such, a significant change in the number
of committers only has a local effect.
* The role of maintainers (but not committers) is mentioned specifically
when it comes to "formal votes" such as changes to governance (global)
and other local votes. No mention of committers. In other words, all
maintainers vote in "formal votes".
* Looking at the voting related to the project lify cycle: These are
just "formal votes" which are allowed by maintainers
* Committers are specifically mentioned as "referees" in case there are
conflicts. There we have a hierarchy of conflict resolution and the
proposed xhange to XAPI committers should not affect
== What is the impact of this change (IMPORTANT) ==
As such, the change proposed to XAPI committers is affecting the voting
dynamics for global votes as on the face of it it increases the number
of maintainers (=committers) from 5 to 13. Given the size of XAPI
subproject and the fact that it basically never listed its maintainers
this seems reasonable. Also in light of the number of maintainers in the
Hypervisor project, of which there are 28 if I counted correctly.
But it does raise the question as to whether such a significant change
to maintainers sets a bad precedence and whether we need to look at our
process
So I would argue that, *this ptoposal has* a global impact - even though
unintended - and that for this reason we need to have a discussion and
maybe a formal vote to ratify this proposed change by the XAPI project.
Best Regards
Lars
_______________________________________________
Xen-api mailing list
Xen-api@lists.xen.org
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api
> On 15 May 2014, at 09:57, Lars Kurth <lars.kurth@xen.org> wrote:
>
>> All the existing committers have voted in favour. So the proposal carries. I will update the XAPI webpage http://www.xenproject.org/developers/teams/xapi.html accordingly
>> Lars
>>
> This isn't intended to affect the voting, but I would note that it's slightly odd for an open-source project to switch its committers in such a big sweep without at least some discussion about how this affects the overall project direction.
Actually, thinking about it *could* affect the direction of the project
for anything that is related to global votes. And we *do* need to have a
discussion about it. And we *may* need a process change or
clarification, but I don't think so as the process was originally
designed to cover a gradual increase in the number of subprojects.
Thanks Anil for pointing this out. I was too overloaded to really spot
this : Apologies.
== Different Expectations when to award maintainer status ==
First there is the observation in that:
* There are significant differences when it comes to when (aka under
which criteria) committer status is awarded between subprojects and
there are also difference in view within subprojects
* XAPI does not have the maintainer role as far as I understand. In
other words in XAPI maintainer=committer. Please correct me if I am wrong.
== Process implications ==
Looking at the governance process:
http://www.xenproject.org/governance.html
Maintainers and committers have the right to vote in some circumstances.
Now we have local (within subproject) and global votes (affecting all
projects). What the process states specifically when it comes to voting is:
* The role of committers in electing other committers and project leads
- this is subproject local. As such, a significant change in the number
of committers only has a local effect.
* The role of maintainers (but not committers) is mentioned specifically
when it comes to "formal votes" such as changes to governance (global)
and other local votes. No mention of committers. In other words, all
maintainers vote in "formal votes".
* Looking at the voting related to the project lify cycle: These are
just "formal votes" which are allowed by maintainers
* Committers are specifically mentioned as "referees" in case there are
conflicts. There we have a hierarchy of conflict resolution and the
proposed xhange to XAPI committers should not affect
== What is the impact of this change (IMPORTANT) ==
As such, the change proposed to XAPI committers is affecting the voting
dynamics for global votes as on the face of it it increases the number
of maintainers (=committers) from 5 to 13. Given the size of XAPI
subproject and the fact that it basically never listed its maintainers
this seems reasonable. Also in light of the number of maintainers in the
Hypervisor project, of which there are 28 if I counted correctly.
But it does raise the question as to whether such a significant change
to maintainers sets a bad precedence and whether we need to look at our
process
So I would argue that, *this ptoposal has* a global impact - even though
unintended - and that for this reason we need to have a discussion and
maybe a formal vote to ratify this proposed change by the XAPI project.
Best Regards
Lars
_______________________________________________
Xen-api mailing list
Xen-api@lists.xen.org
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api