9:08 p.m.
Please read, we can always vote in updates, so proof it and make sure it
is good enough to get going with.
(URL REDACTED - INFO:
http://lists.ovirt.org/mailman/project-planning/2011-September/000283.html)
Jim, if you also proof, given your experience in this area
I have linked it into the web site layout in the google doc, I'll be
working all the key sections one by one to get us going for launch.
thx
Carl.
9:25 p.m.
Carl,
I'm not an expert in this area, but the voting guidelines and explanations
are clear enough. One edit though - there is one instance of "whey" instead
of "weigh".
Jon
On 9/9/11 2:08 PM, "Carl Trieloff" <cctrieloff(a)redhat.com> wrote:
Please read, we can always vote in updates, so proof it and make sure it
is good enough to get going with.
(URL REDACTED - INFO:
http://lists.ovirt.org/mailman/project-planning/2011-September/000283.html)
Jim, if you also proof, given your experience in this area
I have linked it into the web site layout in the google doc, I'll be
working all the key sections one by one to get us going for launch.
thx
Carl.
_______________________________________________
Project-planning mailing list
Project-planning(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/project-planning
Jon Benedict
Technical Marketing Engineer
Virtualization & Cloud
NetApp
919.476.5093 Direct
919.757.7789 Mobile
Jon.Benedict(a)netapp.com
www.netapp.com
10:10 p.m.
fixed.
On 09/09/2011 02:25 PM, Benedict, Jon wrote:
Carl,
I'm not an expert in this area, but the voting guidelines and explanations
are clear enough. One edit though - there is one instance of "whey" instead
of "weigh".
Jon
On 9/9/11 2:08 PM, "Carl Trieloff" <cctrieloff(a)redhat.com> wrote:
>
> Please read, we can always vote in updates, so proof it and make sure it
> is good enough to get going with.
>
> (URL REDACTED - INFO:
http://lists.ovirt.org/mailman/project-planning/2011-September/000283.html)
>
> Jim, if you also proof, given your experience in this area
>
> I have linked it into the web site layout in the google doc, I'll be
> working all the key sections one by one to get us going for launch.
>
> thx
> Carl.
> _______________________________________________
> Project-planning mailing list
> Project-planning(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/project-planning
Jon Benedict
Technical Marketing Engineer
Virtualization & Cloud
NetApp
919.476.5093 Direct
919.757.7789 Mobile
Jon.Benedict(a)netapp.com
www.netapp.com
9:48 p.m.
On 09/09/2011 01:08 PM, Carl Trieloff wrote:
Please read, we can always vote in updates, so proof it and make sure it
is good enough to get going with.
(URL REDACTED - INFO:
http://lists.ovirt.org/mailman/project-planning/2011-September/000283.html)
Jim, if you also proof, given your experience in this area
I have linked it into the web site layout in the google doc, I'll be
working all the key sections one by one to get us going for launch.
I assume code doesn't mean code as in software, but some sort of
community code?
One concern I have is that this seems to enforce that all projects are
managed via consensus. But many existing (and successful) Open Source
projects don't use an Apache-style consensus model but rather rely on a
benevolent dictatorship or some variation thereof.
I think it's fine to use a consensus model for oVirt business, but I
think it's important to allow sub projects to use other types of
leadership models. Otherwise you're excluding large parts of the
existing community, most notably, libvirt, QEMU, and KVM.
So I think for project specific things (like whether a project is ready
for a release) needs to be completely deferred to the sub project.
If the sub project needs to somehow codify how it makes decisions,
that's fine, but the sub project should ultimately have the say over how
it makes decisions.
Regards,
Anthony Liguori
thx
Carl.
_______________________________________________
Project-planning mailing list
Project-planning(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/project-planning
10:08 p.m.
On 09/09/2011 02:48 PM, Anthony Liguori wrote:
On 09/09/2011 01:08 PM, Carl Trieloff wrote:
>
>
> Please read, we can always vote in updates, so proof it and make sure it
> is good enough to get going with.
>
> (URL REDACTED - INFO:
http://lists.ovirt.org/mailman/project-planning/2011-September/000283.html)
>
>
> Jim, if you also proof, given your experience in this area
>
> I have linked it into the web site layout in the google doc, I'll be
> working all the key sections one by one to get us going for launch.
I assume code doesn't mean code as in software, but some sort of
community code?
One concern I have is that this seems to enforce that all projects are
managed via consensus. But many existing (and successful) Open Source
projects don't use an Apache-style consensus model but rather rely on
a benevolent dictatorship or some variation thereof.
I think it's fine to use a consensus model for oVirt business, but I
think it's important to allow sub projects to use other types of
leadership models. Otherwise you're excluding large parts of the
existing community, most notably, libvirt, QEMU, and KVM.
So I think for project specific things (like whether a project is
ready for a release) needs to be completely deferred to the sub project.
If the sub project needs to somehow codify how it makes decisions,
that's fine, but the sub project should ultimately have the say over
how it makes decisions.
The goal is for each sub-project to get to 3 or more maintainers, which
rules out the benevolent dictatorship model for sub-projects. The goal
here is to build a growing and sustainable community not reliant on
single individuals.
Think of it as at least three benevolent dictators per sub-project, or
if the project has less than three, the board helps provide
accountability. For projects like KVM, QEMU, libvirt, if they joined in
we would encourage them vote on additional maintainers. It is hard to
argue any downside to doing that.
Carl.
10:15 p.m.
project-planning-bounces(a)ovirt.org wrote on 09/09/2011 03:08:17 PM:
> One concern I have is that this seems to enforce that all
projects are
> managed via consensus. But many existing (and successful) Open Source
> projects don't use an Apache-style consensus model but rather rely on
> a benevolent dictatorship or some variation thereof.
>
> I think it's fine to use a consensus model for oVirt business, but I
> think it's important to allow sub projects to use other types of
> leadership models. Otherwise you're excluding large parts of the
> existing community, most notably, libvirt, QEMU, and KVM.
>
> So I think for project specific things (like whether a project is
> ready for a release) needs to be completely deferred to the sub
project.
>
> If the sub project needs to somehow codify how it makes decisions,
> that's fine, but the sub project should ultimately have the say over
> how it makes decisions.
The goal is for each sub-project to get to 3 or more maintainers, which
rules out the benevolent dictatorship model for sub-projects. The goal
here is to build a growing and sustainable community not reliant on
single individuals.
Think of it as at least three benevolent dictators per sub-project, or
if the project has less than three, the board helps provide
accountability. For projects like KVM, QEMU, libvirt, if they joined in
we would encourage them vote on additional maintainers. It is hard to
argue any downside to doing that.
I agree that we need to encourage and require more than one maintainer per
project and I like the rule. I don't think we want to force a change in
existing projects that are successful like KVM & QEMU. In both of these
cases we have projects with a long history of broad contributions. Or we
should recognize that kVM and QEMU have de-facto sub-mainterships due to
the practice of regular almost automatic pulling of source trees published
by key contributors.
Thanks,
Mike
Mike Day
IBM Distinguished Engineer
Chief Virtualization Architect, Open Systems Development
Cell: +1 919 371-8786 | mdday(a)us.ibm.com
http://code.ncultra.org
10:29 p.m.
On 09/09/2011 03:15 PM, Michael D Day wrote:
project-planning-bounces(a)ovirt.org wrote on 09/09/2011 03:08:17 PM:
> > One concern I have is that this seems to enforce that all projects are
> > managed via consensus. But many existing (and successful) Open Source
> > projects don't use an Apache-style consensus model but rather rely on
> > a benevolent dictatorship or some variation thereof.
> >
> > I think it's fine to use a consensus model for oVirt business, but I
> > think it's important to allow sub projects to use other types of
> > leadership models. Otherwise you're excluding large parts of the
> > existing community, most notably, libvirt, QEMU, and KVM.
> >
> > So I think for project specific things (like whether a project is
> > ready for a release) needs to be completely deferred to the sub
project.
> >
> > If the sub project needs to somehow codify how it makes decisions,
> > that's fine, but the sub project should ultimately have the say over
> > how it makes decisions.
>
>
> The goal is for each sub-project to get to 3 or more maintainers, which
> rules out the benevolent dictatorship model for sub-projects. The goal
> here is to build a growing and sustainable community not reliant on
> single individuals.
>
> Think of it as at least three benevolent dictators per sub-project, or
> if the project has less than three, the board helps provide
> accountability. For projects like KVM, QEMU, libvirt, if they joined in
> we would encourage them vote on additional maintainers. It is hard to
> argue any downside to doing that.
I agree that we need to encourage and require more than one maintainer
per project and I like the rule. I don't think we want to force a
change in existing projects that are successful like KVM & QEMU. In
both of these cases we have projects with a long history of broad
contributions. Or we should recognize that kVM and QEMU have de-facto
sub-mainterships due to the practice of regular almost automatic
pulling of source trees published by key contributors.
That seems reasonable. However I think it would be a boost for the
respective communities if they voted those key contributors to
maintainers if they are defacto trusted and making that recognition
public. That in itself is great for all involved, and as from what I
understand these key contributors are 'maintainers' in just about every
regard except in name and recognition. Formalizing and providing that
recognition is never a bad thing.
However, I agree, with these listed projects we can make it happen.
Carl.
10:40 p.m.
On 09/09/2011 02:29 PM, Carl Trieloff wrote:
On 09/09/2011 03:15 PM, Michael D Day wrote:
> project-planning-bounces(a)ovirt.org wrote on 09/09/2011 03:08:17 PM:
>> Think of it as at least three benevolent dictators per sub-project, or
>> if the project has less than three, the board helps provide
>> accountability. For projects like KVM, QEMU, libvirt, if they joined in
>> we would encourage them vote on additional maintainers. It is hard to
>> argue any downside to doing that.
>
> I agree that we need to encourage and require more than one maintainer
> per project and I like the rule. I don't think we want to force a
> change in existing projects that are successful like KVM& QEMU. In
> both of these cases we have projects with a long history of broad
> contributions. Or we should recognize that kVM and QEMU have de-facto
> sub-mainterships due to the practice of regular almost automatic
> pulling of source trees published by key contributors.
That seems reasonable. However I think it would be a boost for the
respective communities if they voted those key contributors to
maintainers if they are defacto trusted and making that recognition
public. That in itself is great for all involved, and as from what I
understand these key contributors are 'maintainers' in just about every
regard except in name and recognition. Formalizing and providing that
recognition is never a bad thing.
No, it's formalized already (via a MAINTAINERS file, just like Linux).
Again, this is very similar to other communities like libvirt. If one
of the Daniels are on the list, they can comment more, but my understand
is that there are many people with commit access, but a very small
number of people that are effectively the benevolent dictators and make
final decisions on releases.
The main point here is not to debate the effectiveness of any given
model but to point out that the stricter you are about requiring
projects to govern themselves in certain ways, the less inclusive the
overall community will be.
Regards,
Anthony Liguori
However, I agree, with these listed projects we can make it happen.
Carl.
10:52 p.m.
On 09/09/2011 03:40 PM, Anthony Liguori wrote:
On 09/09/2011 02:29 PM, Carl Trieloff wrote:
> On 09/09/2011 03:15 PM, Michael D Day wrote:
>> project-planning-bounces(a)ovirt.org wrote on 09/09/2011 03:08:17 PM:
>>> Think of it as at least three benevolent dictators per sub-project, or
>>> if the project has less than three, the board helps provide
>>> accountability. For projects like KVM, QEMU, libvirt, if they
>>> joined in
>>> we would encourage them vote on additional maintainers. It is hard to
>>> argue any downside to doing that.
>>
>> I agree that we need to encourage and require more than one maintainer
>> per project and I like the rule. I don't think we want to force a
>> change in existing projects that are successful like KVM& QEMU. In
>> both of these cases we have projects with a long history of broad
>> contributions. Or we should recognize that kVM and QEMU have de-facto
>> sub-mainterships due to the practice of regular almost automatic
>> pulling of source trees published by key contributors.
>
> That seems reasonable. However I think it would be a boost for the
> respective communities if they voted those key contributors to
> maintainers if they are defacto trusted and making that recognition
> public. That in itself is great for all involved, and as from what I
> understand these key contributors are 'maintainers' in just about every
> regard except in name and recognition. Formalizing and providing that
> recognition is never a bad thing.
No, it's formalized already (via a MAINTAINERS file, just like Linux).
Again, this is very similar to other communities like libvirt. If one
of the Daniels are on the list, they can comment more, but my
understand is that there are many people with commit access, but a
very small number of people that are effectively the benevolent
dictators and make final decisions on releases.
The main point here is not to debate the effectiveness of any given
model but to point out that the stricter you are about requiring
projects to govern themselves in certain ways, the less inclusive the
overall community will be.
apache also has the two levels, they call that the PMC. I stripped the
two levels out to keep it simple and we can update as required. If we
want that we should doc it back in.
goal here is to be transparent and easy for people to join in.
carl
10:37 p.m.
On 09/09/2011 02:08 PM, Carl Trieloff wrote:
On 09/09/2011 02:48 PM, Anthony Liguori wrote:
> On 09/09/2011 01:08 PM, Carl Trieloff wrote:
>>
>>
>> Please read, we can always vote in updates, so proof it and make sure it
>> is good enough to get going with.
>>
>> (URL REDACTED - INFO:
http://lists.ovirt.org/mailman/project-planning/2011-September/000283.html)
>>
>>
>> Jim, if you also proof, given your experience in this area
>>
>> I have linked it into the web site layout in the google doc, I'll be
>> working all the key sections one by one to get us going for launch.
>
> I assume code doesn't mean code as in software, but some sort of
> community code?
>
> One concern I have is that this seems to enforce that all projects are
> managed via consensus. But many existing (and successful) Open Source
> projects don't use an Apache-style consensus model but rather rely on
> a benevolent dictatorship or some variation thereof.
>
> I think it's fine to use a consensus model for oVirt business, but I
> think it's important to allow sub projects to use other types of
> leadership models. Otherwise you're excluding large parts of the
> existing community, most notably, libvirt, QEMU, and KVM.
>
> So I think for project specific things (like whether a project is
> ready for a release) needs to be completely deferred to the sub project.
>
> If the sub project needs to somehow codify how it makes decisions,
> that's fine, but the sub project should ultimately have the say over
> how it makes decisions.
The goal is for each sub-project to get to 3 or more maintainers, which
rules out the benevolent dictatorship model for sub-projects. The goal
here is to build a growing and sustainable community not reliant on
single individuals.
Having 3 maintainers does not mean there isn't an overall project
leader. We have around 30 maintainers in QEMU but only one project
leader. The project leader casts the tie breaking vote.
It's the same model as the kernel and many other communities.
Regards,
Anthony Liguori
10:54 p.m.
On 09/09/2011 03:37 PM, Anthony Liguori wrote:
Having 3 maintainers does not mean there isn't an overall
project
leader. We have around 30 maintainers in QEMU but only one project
leader. The project leader casts the tie breaking vote.
It's the same model as the kernel and many other communities.
how about we state that a sub-project may ellect someone to cast tie
breaking votes if they want to. And then how that loosely works
I think that should resolve your concern. Does that work?
Carl.
11 p.m.
On 09/09/2011 02:54 PM, Carl Trieloff wrote:
On 09/09/2011 03:37 PM, Anthony Liguori wrote:
> Having 3 maintainers does not mean there isn't an overall project
> leader. We have around 30 maintainers in QEMU but only one project
> leader. The project leader casts the tie breaking vote.
>
> It's the same model as the kernel and many other communities.
how about we state that a sub-project may ellect someone to cast tie
breaking votes if they want to. And then how that loosely works
I think that should resolve your concern. Does that work?
I'd prefer something like, communities with greater than 3 (or maybe
10?) maintainers can creator their own voting procedures.
Regards,
Anthony Liguori
Carl.
11:03 p.m.
On 09/09/2011 04:00 PM, Anthony Liguori wrote:
I'd prefer something like, communities with greater than 3 (or maybe
10?) maintainers can creator their own voting procedures.
that is what apache does btw and is fine by me. the goal here is to get
a broad maintainer set and help mew projects grow. once a project has a
good culture, they can evolve it themselves.
Do you want to go ahead and edit that into the google doc?
Carl.
11:25 p.m.
On 09/09/2011 04:03 PM, Carl Trieloff wrote:
On 09/09/2011 04:00 PM, Anthony Liguori wrote:
> I'd prefer something like, communities with greater than 3 (or maybe
> 10?) maintainers can creator their own voting procedures.
that is what apache does btw and is fine by me. the goal here is to get
a broad maintainer set and help mew projects grow. once a project has a
good culture, they can evolve it themselves.
Do you want to go ahead and edit that into the google doc?
Anthony,
I added a section at the bottom, take a look and see if it cuts mustard
for you. edit away as needed.
thx
Carl.
11:46 p.m.
On 09/09/2011 03:25 PM, Carl Trieloff wrote:
On 09/09/2011 04:03 PM, Carl Trieloff wrote:
> On 09/09/2011 04:00 PM, Anthony Liguori wrote:
>> I'd prefer something like, communities with greater than 3 (or maybe
>> 10?) maintainers can creator their own voting procedures.
> that is what apache does btw and is fine by me. the goal here is to get
> a broad maintainer set and help mew projects grow. once a project has a
> good culture, they can evolve it themselves.
>
> Do you want to go ahead and edit that into the google doc?
Anthony,
I added a section at the bottom, take a look and see if it cuts mustard
for you. edit away as needed.
I think that's sufficiently open ended enough that it can be clarified
down the road through board voting.
Thanks!
Regards,
Anthony Liguori
thx
Carl.
_______________________________________________
Project-planning mailing list
Project-planning(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/project-planning
11:38 p.m.
On 09/09/2011 03:03 PM, Carl Trieloff wrote:
On 09/09/2011 04:00 PM, Anthony Liguori wrote:
>
> I'd prefer something like, communities with greater than 3 (or maybe
> 10?) maintainers can creator their own voting procedures.
that is what apache does btw and is fine by me. the goal here is to get
a broad maintainer set and help mew projects grow. once a project has a
good culture, they can evolve it themselves.
Okay, that sounds good. Perhaps we should try to work language like
this into more of these docs? Basically, three tiers of projects:
Tier 0; x < 3 maintainers, oVirt board has ability to make decisions
on behalf of the project.
Tier 1; 3 <= x < 10 maintainers, project is autonomous, but must use
oVirt recommended voting procedures and maintainership model.
Tier 2; x >= 10 maintainers, project is autonomous and writes its own
governance document. Perhaps the document should be voted on by the
oVirt board?
I think that creates a nice incubator model where oVirt helps a project
grow and gets out of the way once it reaches critical mass.
Can anyone give me an idea of where the initial set of seed projects
will fit? How many maintainers is oVirt Server likely to have? (I
assume that's the biggest of the seed projects).
Do you want to go ahead and edit that into the google doc?
Sure.
Regards,
Anthony Liguori
Carl.
11:59 p.m.
On 09/09/2011 04:38 PM, Anthony Liguori wrote:
Okay, that sounds good. Perhaps we should try to work language like
this into more of these docs? Basically, three tiers of projects:
Tier 0; x < 3 maintainers, oVirt board has ability to make decisions
on behalf of the project.
Tier 1; 3 <= x < 10 maintainers, project is autonomous, but must use
oVirt recommended voting procedures and maintainership model.
Tier 2; x >= 10 maintainers, project is autonomous and writes its own
governance document. Perhaps the document should be voted on by the
oVirt board?
I think that creates a nice incubator model where oVirt helps a
project grow and gets out of the way once it reaches critical mass.
Can anyone give me an idea of where the initial set of seed projects
will fit? How many maintainers is oVirt Server likely to have? (I
assume that's the biggest of the seed projects).
That looks nice, I cut and paste this into the doc I working now --
called - becoming an oVirt sub-project
Carl.
12:09 a.m.
On 09/09/2011 04:38 PM, Anthony Liguori wrote:
On 09/09/2011 03:03 PM, Carl Trieloff wrote:
> On 09/09/2011 04:00 PM, Anthony Liguori wrote:
>>
>> I'd prefer something like, communities with greater than 3 (or maybe
>> 10?) maintainers can creator their own voting procedures.
>
> that is what apache does btw and is fine by me. the goal here is to get
> a broad maintainer set and help mew projects grow. once a project has a
> good culture, they can evolve it themselves.
Okay, that sounds good. Perhaps we should try to work language like
this into more of these docs? Basically, three tiers of projects:
Tier 0; x < 3 maintainers, oVirt board has ability to make decisions
on behalf of the project.
Tier 1; 3 <= x < 10 maintainers, project is autonomous, but must use
oVirt recommended voting procedures and maintainership model.
Tier 2; x >= 10 maintainers, project is autonomous and writes its own
governance document. Perhaps the document should be voted on by the
oVirt board?
I think that creates a nice incubator model where oVirt helps a project
grow and gets out of the way once it reaches critical mass.
Can anyone give me an idea of where the initial set of seed projects
will fit? How many maintainers is oVirt Server likely to have? (I
assume that's the biggest of the seed projects).
Do we define a maintainer as anyone with commit access to the main
upstream repo?
If so, oVirt Node project has 3 maintainers presently (not counting
myself, and I don't since I don't code anymore...)
Perry
12:30 a.m.
On 09/09/2011 04:09 PM, Perry Myers wrote:
On 09/09/2011 04:38 PM, Anthony Liguori wrote:
> On 09/09/2011 03:03 PM, Carl Trieloff wrote:
>> On 09/09/2011 04:00 PM, Anthony Liguori wrote:
>>>
>>> I'd prefer something like, communities with greater than 3 (or maybe
>>> 10?) maintainers can creator their own voting procedures.
>>
>> that is what apache does btw and is fine by me. the goal here is to get
>> a broad maintainer set and help mew projects grow. once a project has a
>> good culture, they can evolve it themselves.
>
> Okay, that sounds good. Perhaps we should try to work language like
> this into more of these docs? Basically, three tiers of projects:
>
> Tier 0; x< 3 maintainers, oVirt board has ability to make decisions
> on behalf of the project.
>
> Tier 1; 3<= x< 10 maintainers, project is autonomous, but must use
> oVirt recommended voting procedures and maintainership model.
>
> Tier 2; x>= 10 maintainers, project is autonomous and writes its own
> governance document. Perhaps the document should be voted on by the
> oVirt board?
>
> I think that creates a nice incubator model where oVirt helps a project
> grow and gets out of the way once it reaches critical mass.
>
> Can anyone give me an idea of where the initial set of seed projects
> will fit? How many maintainers is oVirt Server likely to have? (I
> assume that's the biggest of the seed projects).
Do we define a maintainer as anyone with commit access to the main
upstream repo?
If so, oVirt Node project has 3 maintainers presently (not counting
myself, and I don't since I don't code anymore...)
I think anyone with commit access who can commit other people's patches?
I think that fits the categories quite well too. ovirt-node is large
enough that it should be autonomous. I think the overall goal is to
make sure that projects move from Tier 0 -> Tier 1 over time but once at
Tier 1, I'm sure certain projects can last forever at that size.
Regards,
Anthony Liguori
Perry
11:44 p.m.
On 09/09/2011 05:30 PM, Anthony Liguori wrote:
On 09/09/2011 04:09 PM, Perry Myers wrote:
> On 09/09/2011 04:38 PM, Anthony Liguori wrote:
>> On 09/09/2011 03:03 PM, Carl Trieloff wrote:
>>> On 09/09/2011 04:00 PM, Anthony Liguori wrote:
>>>>
>>>> I'd prefer something like, communities with greater than 3 (or maybe
>>>> 10?) maintainers can creator their own voting procedures.
>>>
>>> that is what apache does btw and is fine by me. the goal here is to
>>> get
>>> a broad maintainer set and help mew projects grow. once a project
>>> has a
>>> good culture, they can evolve it themselves.
>>
>> Okay, that sounds good. Perhaps we should try to work language like
>> this into more of these docs? Basically, three tiers of projects:
>>
>> Tier 0; x< 3 maintainers, oVirt board has ability to make decisions
>> on behalf of the project.
>>
>> Tier 1; 3<= x< 10 maintainers, project is autonomous, but must use
>> oVirt recommended voting procedures and maintainership model.
>>
>> Tier 2; x>= 10 maintainers, project is autonomous and writes its own
>> governance document. Perhaps the document should be voted on by the
>> oVirt board?
>>
>> I think that creates a nice incubator model where oVirt helps a project
>> grow and gets out of the way once it reaches critical mass.
>>
>> Can anyone give me an idea of where the initial set of seed projects
>> will fit? How many maintainers is oVirt Server likely to have? (I
>> assume that's the biggest of the seed projects).
They are now listed in the google doc. Itamar is still filling in the
matrix.
>
> Do we define a maintainer as anyone with commit access to the main
> upstream repo?
>
yes.
> If so, oVirt Node project has 3 maintainers presently (not
counting
> myself, and I don't since I don't code anymore...)
I think anyone with commit access who can commit other people's patches?
I think that fits the categories quite well too. ovirt-node is large
enough that it should be autonomous. I think the overall goal is to
make sure that projects move from Tier 0 -> Tier 1 over time but once
at Tier 1, I'm sure certain projects can last forever at that size.
Regards,
Anthony Liguori
>
> Perry
10:57 a.m.
-----Original Message-----
From: project-planning-bounces(a)ovirt.org
[mailto:project-planning-bounces@ovirt.org] On Behalf Of Anthony
Liguori
Sent: Friday, September 09, 2011 23:39 PM
To: cctrieloff(a)redhat.com
Cc: project-planning(a)ovirt.org
Subject: Re: oVirt comminuty voting
On 09/09/2011 03:03 PM, Carl Trieloff wrote:
> On 09/09/2011 04:00 PM, Anthony Liguori wrote:
>>
>> I'd prefer something like, communities with greater than 3 (or maybe
>> 10?) maintainers can creator their own voting procedures.
>
> that is what apache does btw and is fine by me. the goal here is to
get
> a broad maintainer set and help mew projects grow. once a
project has
a
> good culture, they can evolve it themselves.
Okay, that sounds good. Perhaps we should try to work language like
this into more of these docs? Basically, three tiers of projects:
Tier 0; x < 3 maintainers, oVirt board has ability to make decisions
on behalf of the project.
Tier 1; 3 <= x < 10 maintainers, project is autonomous, but must use
oVirt recommended voting procedures and maintainership model.
Tier 2; x >= 10 maintainers, project is autonomous and writes its own
governance document. Perhaps the document should be voted on by the
oVirt board?
I think that creates a nice incubator model where oVirt helps a project
grow and gets out of the way once it reaches critical mass.
Can anyone give me an idea of where the initial set of seed projects
will fit? How many maintainers is oVirt Server likely to have? (I
assume that's the biggest of the seed projects).
I think the comment on a 'leader' and the need for a tie breaker is valid
for projects with less than 10 maintainers as well.
This is also relevant for overruling a nack to avoid stagnation. A
majority of acks, or leader as tie breaker should be able to vote on
overruling a nack.
noon
Looks good.
Could use some editing (lots of small things like s/rewording/rewarding/, s/wsdm/vdsm/)
----- Original Message -----
> -----Original Message-----
> From: project-planning-bounces(a)ovirt.org
[mailto:project-planning-bounces@ovirt.org] On Behalf Of Anthony
> Liguori
> Sent: Friday, September 09, 2011 23:39 PM
> To: cctrieloff(a)redhat.com
> Cc: project-planning(a)ovirt.org
> Subject: Re: oVirt comminuty voting
>
> On 09/09/2011 03:03 PM, Carl Trieloff wrote:
> > On 09/09/2011 04:00 PM, Anthony Liguori wrote:
> >>
> >> I'd prefer something like, communities with greater than 3 (or
> >> maybe
> >> 10?) maintainers can creator their own voting procedures.
> >
> > that is what apache does btw and is fine by me. the goal here is
> > to
get
> > a broad maintainer set and help mew projects grow. once a project
> > has
a
> > good culture, they can evolve it themselves.
>
> Okay, that sounds good. Perhaps we should try to work language like
> this into more of these docs? Basically, three tiers of projects:
>
> Tier 0; x < 3 maintainers, oVirt board has ability to make
> decisions
> on behalf of the project.
>
> Tier 1; 3 <= x < 10 maintainers, project is autonomous, but must
> use
> oVirt recommended voting procedures and maintainership model.
>
> Tier 2; x >= 10 maintainers, project is autonomous and writes its
> own
> governance document. Perhaps the document should be voted on by the
> oVirt board?
>
> I think that creates a nice incubator model where oVirt helps a
> project
> grow and gets out of the way once it reaches critical mass.
>
> Can anyone give me an idea of where the initial set of seed projects
> will fit? How many maintainers is oVirt Server likely to have? (I
> assume that's the biggest of the seed projects).
I think the comment on a 'leader' and the need for a tie breaker is
valid
for projects with less than 10 maintainers as well.
This is also relevant for overruling a nack to avoid stagnation. A
majority of acks, or leader as tie breaker should be able to vote on
overruling a nack.
_______________________________________________
Project-planning mailing list
Project-planning(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/project-planning
--
---------------------------------------------------------------
"We are all on earth to help others. What on earth the others are here for, I
can't imagine."
Reverend Vivian Foster, Vicar of Mirth.
6:25 p.m.
On 09/11/2011 03:57 AM, Itamar Heim wrote:
> -----Original Message-----
> From: project-planning-bounces(a)ovirt.org
[mailto:project-planning-bounces@ovirt.org] On Behalf Of Anthony
> Liguori
> Sent: Friday, September 09, 2011 23:39 PM
> To: cctrieloff(a)redhat.com
> Cc: project-planning(a)ovirt.org
> Subject: Re: oVirt comminuty voting
>
> On 09/09/2011 03:03 PM, Carl Trieloff wrote:
>> On 09/09/2011 04:00 PM, Anthony Liguori wrote:
>>> I'd prefer something like, communities with greater than 3 (or maybe
>>> 10?) maintainers can creator their own voting procedures.
>> that is what apache does btw and is fine by me. the goal here is to
get
>> a broad maintainer set and help mew projects grow. once a project has
a
>> good culture, they can evolve it themselves.
> Okay, that sounds good. Perhaps we should try to work language like
> this into more of these docs? Basically, three tiers of projects:
>
> Tier 0; x < 3 maintainers, oVirt board has ability to make decisions
> on behalf of the project.
>
> Tier 1; 3 <= x < 10 maintainers, project is autonomous, but must use
> oVirt recommended voting procedures and maintainership model.
>
> Tier 2; x >= 10 maintainers, project is autonomous and writes its own
> governance document. Perhaps the document should be voted on by the
> oVirt board?
>
> I think that creates a nice incubator model where oVirt helps a project
> grow and gets out of the way once it reaches critical mass.
>
> Can anyone give me an idea of where the initial set of seed projects
> will fit? How many maintainers is oVirt Server likely to have? (I
> assume that's the biggest of the seed projects).
I think the comment on a 'leader' and the need for a tie breaker is valid
for projects with less than 10 maintainers as well.
This is also relevant for overruling a nack to avoid stagnation. A
majority of acks, or leader as tie breaker should be able to vote on
overruling a nack.
I'll draft a first version of the becoming a sub-project doc, and I'll
try work this feedback into that.
Carl.
4:54 p.m.
A project lead implies that somehow his/her vote is more important
than anyone else's, which is not how the ASF works.
The idea is to build a community that strives for consensus so that
the need for tie-breaking votes isn't required… If half the community
thinks A and the other B, then there is for sure no consensus.
Having 3 maintainers does not mean there isn't an overall project leader. We have
around 30 maintainers in QEMU but only one project leader. The project leader casts the
tie breaking vote.
It's the same model as the kernel and many other communities.
Regards,
Anthony Liguori
--
Jim Jagielski | jimjag(a)redhat.com | 443-324-8390 (cell)
5:01 p.m.
-----Original Message-----
From: project-planning-bounces(a)ovirt.org
[mailto:project-planning-bounces@ovirt.org] On Behalf Of Jim
Jagielski
Sent: Tuesday, September 13, 2011 16:54 PM
To: Anthony Liguori
Cc: project-planning(a)ovirt.org
Subject: Re: oVirt comminuty voting
A project lead implies that somehow his/her vote is more important
than anyone else's, which is not how the ASF works.
The idea is to build a community that strives for consensus so that
the need for tie-breaking votes isn't required. If half the community
thinks A and the other B, then there is for sure no consensus.
How often are these and how do they get resolved?
How is a nack by someone resolved if majority are in agreement (ack it)?
>
> Having 3 maintainers does not mean there isn't an overall project
leader.
We have around 30 maintainers
in QEMU but only one project leader. The project leader casts the
tie
breaking vote.
>
> It's the same model as the kernel and many other communities.
>
> Regards,
>
> Anthony Liguori
--
Jim Jagielski | jimjag(a)redhat.com | 443-324-8390 (cell)
_______________________________________________
Project-planning mailing list
Project-planning(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/project-planning
5:25 p.m.
On 09/13/2011 10:01 AM, Itamar Heim wrote:
How often are these and how do they get resolved?
How is a nack by someone resolved if majority are in agreement (ack it)?
A nack is invalid (an has to be withdrawn) unless solid technical reason
are given and the debate around those reasons hold.
Jim -- want to add?
Carl.
5:27 p.m.
On Sep 13, 2011, at 10:25 AM, Carl Trieloff wrote:
On 09/13/2011 10:01 AM, Itamar Heim wrote:
> How often are these and how do they get resolved?
> How is a nack by someone resolved if majority are in agreement (ack it)?
A nack is invalid (an has to be withdrawn) unless solid technical reason
are given and the debate around those reasons hold.
Jim -- want to add?
Yep, that's right. In Apache-speak, it's called a 'veto'
--
Jim Jagielski | jimjag(a)redhat.com | 443-324-8390 (cell)
1:24 p.m.
-----Original Message-----
From: project-planning-bounces(a)ovirt.org
[mailto:project-planning-bounces@ovirt.org] On Behalf Of Jim
Jagielski
Sent: Tuesday, September 13, 2011 17:27 PM
To: cctrieloff(a)redhat.com
Cc: project-planning(a)ovirt.org
Subject: Re: oVirt comminuty voting
On Sep 13, 2011, at 10:25 AM, Carl Trieloff wrote:
> On 09/13/2011 10:01 AM, Itamar Heim wrote:
>> How often are these and how do they get resolved?
>> How is a nack by someone resolved if majority are in agreement (ack
it)?
>
>
> A nack is invalid (an has to be withdrawn) unless solid technical
reason
> are given and the debate around those reasons hold.
>
> Jim -- want to add?
Yep, that's right. In Apache-speak, it's called a 'veto'
How often do these happen?
4:45 p.m.
On 09/14/2011 06:24 AM, Itamar Heim wrote:
> Yep, that's right. In Apache-speak, it's called a
'veto'
How often do these happe
I see one that results in debate about every 2+ years on the one project
I run. You may see them on a release vote during testing if issues are
found or licenses missing etc, typically the a patch is submitted to
resolve it and the vote goes on.
Most time feedback is taken and code is improved through normal working.
Carl.
5:02 p.m.
On 09/13/2011 09:54 AM, Jim Jagielski wrote:
A project lead implies that somehow his/her vote is more important
than anyone else's, which is not how the ASF works.
The idea is to build a community that strives for consensus so that
the need for tie-breaking votes isn't required… If half the community
thinks A and the other B, then there is for sure no consensus.
I know many of the Linux projects use the concept of a group elected tie
break role. This is different to ASF. Jim brings up a good point and the
question is do we want it, or not?
Might be best to remove it, and then if a project wants it they have to
get to the mature phase of the project where they update their voting
rules if they want to add that role.
thoughts?
Carl.
5:26 p.m.
That's most probably a good path.
If you start off with the expectation that there will be
the need for tie-breaking votes, well… they are bound to
happen. But if the expectation is that there will be no need
for them, and therefore no position that is "empowered" to
break them, then the communities will be "forced" to
collaborate and compromise.
On Sep 13, 2011, at 10:02 AM, Carl Trieloff wrote:
On 09/13/2011 09:54 AM, Jim Jagielski wrote:
> A project lead implies that somehow his/her vote is more important
> than anyone else's, which is not how the ASF works.
>
> The idea is to build a community that strives for consensus so that
> the need for tie-breaking votes isn't required… If half the community
> thinks A and the other B, then there is for sure no consensus.
I know many of the Linux projects use the concept of a group elected tie
break role. This is different to ASF. Jim brings up a good point and the
question is do we want it, or not?
Might be best to remove it, and then if a project wants it they have to
get to the mature phase of the project where they update their voting
rules if they want to add that role.
thoughts?
Carl.
--
Jim Jagielski | jimjag(a)redhat.com | 443-324-8390 (cell)
6:10 p.m.
On 09/13/2011 09:02 AM, Carl Trieloff wrote:
On 09/13/2011 09:54 AM, Jim Jagielski wrote:
> A project lead implies that somehow his/her vote is more important
> than anyone else's, which is not how the ASF works.
>
> The idea is to build a community that strives for consensus so that
> the need for tie-breaking votes isn't required… If half the community
> thinks A and the other B, then there is for sure no consensus.
I know many of the Linux projects use the concept of a group elected tie
break role. This is different to ASF. Jim brings up a good point and the
question is do we want it, or not?
As long as we're preserving autonomy for established projects, I think
any model as long as it's consistent for smaller projects would work.
Regards,
Anthony Liguori
Might be best to remove it, and then if a project wants it they have to
get to the mature phase of the project where they update their voting
rules if they want to add that role.
thoughts?
Carl.
1:24 p.m.
-----Original Message-----
From: project-planning-bounces(a)ovirt.org
[mailto:project-planning-bounces@ovirt.org] On Behalf Of Anthony
Liguori
Sent: Tuesday, September 13, 2011 18:11 PM
To: cctrieloff(a)redhat.com
Cc: project-planning(a)ovirt.org
Subject: Re: oVirt comminuty voting
On 09/13/2011 09:02 AM, Carl Trieloff wrote:
> On 09/13/2011 09:54 AM, Jim Jagielski wrote:
>> A project lead implies that somehow his/her vote is more important
>> than anyone else's, which is not how the ASF works.
>>
>> The idea is to build a community that strives for consensus so that
>> the need for tie-breaking votes isn't required. If half the community
>> thinks A and the other B, then there is for sure no consensus.
>
>
> I know many of the Linux projects use the concept of a group elected
tie
> break role. This is different to ASF. Jim brings up a good point
and
the
> question is do we want it, or not?
As long as we're preserving autonomy for established projects, I think
any model as long as it's consistent for smaller projects would work.
Do we count ovirt engine as an established project :) ?
I think our current model is of a tie breaking vote in case of
disagreement...
4:47 p.m.
On 09/14/2011 06:24 AM, Itamar Heim wrote:
> As long as we're preserving autonomy for established
projects, I think
> > any model as long as it's consistent for smaller projects would work.
Do we count ovirt engine as an established project :) ?
I think our current model is of a tie breaking vote in case of
disagreement...
I think we want board ack one the first few releases of engine so we can
get our community release processes documented.
Carl.
6:06 p.m.
On 09/13/2011 08:54 AM, Jim Jagielski wrote:
A project lead implies that somehow his/her vote is more important
than anyone else's, which is not how the ASF works.
The idea is to build a community that strives for consensus so that
the need for tie-breaking votes isn't required…
That's one model, but it's not the only model. As it happens, there's a
good LWN article right now on this topic.
http://lwn.net/Articles/458094/
The simple fact is, a large part of the ecosystem we're trying to build
is already existing and has a diverse development model. If we don't
accommodate development model diversity, then we're going to exclude
large parts of the ecosystem which is going to result in fragmentation.
Regards,
Anthony Liguori
If half the community
thinks A and the other B, then there is for sure no consensus.
>
> Having 3 maintainers does not mean there isn't an overall project leader. We
have around 30 maintainers in QEMU but only one project leader. The project leader casts
the tie breaking vote.
>
> It's the same model as the kernel and many other communities.
>
> Regards,
>
> Anthony Liguori
--
Jim Jagielski | jimjag(a)redhat.com | 443-324-8390 (cell)
6:12 p.m.
http://webmink.com/2011/03/11/is-apache-open-by-rule/
On Sep 13, 2011, at 11:06 AM, Anthony Liguori wrote:
On 09/13/2011 08:54 AM, Jim Jagielski wrote:
> A project lead implies that somehow his/her vote is more important
> than anyone else's, which is not how the ASF works.
>
> The idea is to build a community that strives for consensus so that
> the need for tie-breaking votes isn't required…
That's one model, but it's not the only model. As it happens, there's a good
LWN article right now on this topic.
http://lwn.net/Articles/458094/
The simple fact is, a large part of the ecosystem we're trying to build is already
existing and has a diverse development model. If we don't accommodate development
model diversity, then we're going to exclude large parts of the ecosystem which is
going to result in fragmentation.
Regards,
Anthony Liguori
> If half the community
> thinks A and the other B, then there is for sure no consensus.
>
>>
>> Having 3 maintainers does not mean there isn't an overall project leader. We
have around 30 maintainers in QEMU but only one project leader. The project leader casts
the tie breaking vote.
>>
>> It's the same model as the kernel and many other communities.
>>
>> Regards,
>>
>> Anthony Liguori
>
> --
> Jim Jagielski | jimjag(a)redhat.com | 443-324-8390 (cell)
>
--
Jim Jagielski | jimjag(a)redhat.com | 443-324-8390 (cell)
4:51 p.m.
++1
On Sep 9, 2011, at 3:08 PM, Carl Trieloff wrote:
On 09/09/2011 02:48 PM, Anthony Liguori wrote:
> On 09/09/2011 01:08 PM, Carl Trieloff wrote:
>>
>>
>> Please read, we can always vote in updates, so proof it and make sure it
>> is good enough to get going with.
>>
>> = (URL REDACTED - INFO:
http://lists.ovirt.org/mailman/project-planning/2011-September/000283.html)
>>
>>
>> Jim, if you also proof, given your experience in this area
>>
>> I have linked it into the web site layout in the google doc, I'll be
>> working all the key sections one by one to get us going for launch.
>
> I assume code doesn't mean code as in software, but some sort of
> community code?
>
> One concern I have is that this seems to enforce that all projects are
> managed via consensus. But many existing (and successful) Open Source
> projects don't use an Apache-style consensus model but rather rely on
> a benevolent dictatorship or some variation thereof.
>
> I think it's fine to use a consensus model for oVirt business, but I
> think it's important to allow sub projects to use other types of
> leadership models. Otherwise you're excluding large parts of the
> existing community, most notably, libvirt, QEMU, and KVM.
>
> So I think for project specific things (like whether a project is
> ready for a release) needs to be completely deferred to the sub project.
>
> If the sub project needs to somehow codify how it makes decisions,
> that's fine, but the sub project should ultimately have the say over
> how it makes decisions.
The goal is for each sub-project to get to 3 or more maintainers, which
rules out the benevolent dictatorship model for sub-projects. The goal
here is to build a growing and sustainable community not reliant on
single individuals.
Think of it as at least three benevolent dictators per sub-project, or
if the project has less than three, the board helps provide
accountability. For projects like KVM, QEMU, libvirt, if they joined in
we would encourage them vote on additional maintainers. It is hard to
argue any downside to doing that.
Carl.
--
Jim Jagielski | jimjag(a)redhat.com | 443-324-8390 (cell)
10:04 p.m.
Will do…
On Sep 9, 2011, at 2:08 PM, Carl Trieloff wrote:
Please read, we can always vote in updates, so proof it and make sure it
is good enough to get going with.
(URL REDACTED - INFO:
http://lists.ovirt.org/mailman/project-planning/2011-September/000283.html)
Jim, if you also proof, given your experience in this area
I have linked it into the web site layout in the google doc, I'll be
working all the key sections one by one to get us going for launch.
thx
Carl.
--
Jim Jagielski | jimjag(a)redhat.com | 443-324-8390 (cell)
12:15 p.m.
cc'ing some existing leads to comment on this one as well.
-----Original Message-----
From: project-planning-bounces(a)ovirt.org
[mailto:project-planning-bounces@ovirt.org] On Behalf Of Carl
Trieloff
Sent: Friday, September 09, 2011 21:08 PM
To: project-planning(a)ovirt.org; Jim Jagielski
Subject: oVirt comminuty voting
Please read, we can always vote in updates, so proof it and make sure it
is good enough to get going with.
(URL REDACTED - INFO:
http://lists.ovirt.org/mailman/project-planning/2011-September/000283.html)
Jim, if you also proof, given your experience in this area
I have linked it into the web site layout in the google doc, I'll be
working all the key sections one by one to get us going for launch.
thx
Carl.
_______________________________________________
Project-planning mailing list
Project-planning(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/project-planning
1:27 p.m.
-----Original Message-----
From: project-planning-bounces(a)ovirt.org
[mailto:project-planning-bounces@ovirt.org] On Behalf Of Carl
Trieloff
Sent: Friday, September 09, 2011 21:08 PM
To: project-planning(a)ovirt.org; Jim Jagielski
Subject: oVirt comminuty voting
Please read, we can always vote in updates, so proof it and make sure it
is good enough to get going with.
(URL REDACTED - INFO:
http://lists.ovirt.org/mailman/project-planning/2011-September/000283.html)
Jim, if you also proof, given your experience in this area
I have linked it into the web site layout in the google doc, I'll be
working all the key sections one by one to get us going for launch.
Another thought/issue:
Currently maintainer == committer.
Ovirt engine has multiple modules in it.
While a lot of people have commit rights, they are not considered
maintainers of the entire project.
However, it makes sense for them to commit the holistic patch across
multiple modules once all acks are given.
So to me, a maintainer is someone who can ack a patch for a certain module
A committer can commit code, but is responsible to not commit without an
ack from the relevant maintainer if the patch encompasses subsystems
outside of his domain expertise (i.e., committer is not maintainer in all
portions the patch set will touch)
Thoughts?
4:33 p.m.
On 09/14/2011 01:27 PM, Itamar Heim wrote:
> -----Original Message-----
> From: project-planning-bounces(a)ovirt.org
>
[mailto:project-planning-bounces@ovirt.org] On Behalf Of Carl
> Trieloff
> Sent: Friday, September 09, 2011 21:08 PM
> To: project-planning(a)ovirt.org; Jim Jagielski
> Subject: oVirt comminuty voting
>
>
>
> Please read, we can always vote in updates, so proof it and make sure it
> is good enough to get going with.
>
>
>
(URL REDACTED - INFO:
http://lists.ovirt.org/mailman/project-planning/2011-September/000283.html)
> Jim, if you also proof, given your experience in this area
>
> I have linked it into the web site layout in the google doc, I'll be
> working all the key sections one by one to get us going for launch.
>
Another thought/issue:
Currently maintainer == committer.
Ovirt engine has multiple modules in it.
While a lot of people have commit rights, they are not considered
maintainers of the entire project.
However, it makes sense for them to commit the holistic patch across
multiple modules once all acks are given.
So to me, a maintainer is someone who can ack a patch for a certain module
A committer can commit code, but is responsible to not commit without an
Another question here -
when you speak of modules - are you referring also for sub modules, for
example - the bll and dal modules in engine core?
ack from the relevant maintainer if the patch encompasses subsystems
outside of his domain expertise (i.e., committer is not maintainer in all
portions the patch set will touch)
Thoughts?
_______________________________________________
Project-planning mailing list
Project-planning(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/project-planning
4:39 p.m.
-----Original Message-----
From: project-planning-bounces(a)ovirt.org
[mailto:project-planning-bounces@ovirt.org] On Behalf Of Yair
Zaslavsky
Sent: Wednesday, September 14, 2011 16:34 PM
To: project-planning(a)ovirt.org
Subject: Re: oVirt comminuty voting
On 09/14/2011 01:27 PM, Itamar Heim wrote:
>
>
>> -----Original Message-----
>> From: project-planning-bounces(a)ovirt.org
>>
> [mailto:project-planning-bounces@ovirt.org] On Behalf Of Carl
>
>> Trieloff
>> Sent: Friday, September 09, 2011 21:08 PM
>> To: project-planning(a)ovirt.org; Jim Jagielski
>> Subject: oVirt comminuty voting
>>
>>
>>
>> Please read, we can always vote in updates, so proof it and make sure
it
>> is good enough to get going with.
>>
>>
>>
> (URL REDACTED - INFO:
http://lists.ovirt.org/mailman/project-planning/2011-September/000283.html)
>
>> Jim, if you also proof, given your experience in this area
>>
>> I have linked it into the web site layout in the google doc, I'll be
>> working all the key sections one by one to get us going for launch.
>>
> Another thought/issue:
> Currently maintainer == committer.
> Ovirt engine has multiple modules in it.
> While a lot of people have commit rights, they are not considered
> maintainers of the entire project.
> However, it makes sense for them to commit the holistic patch across
> multiple modules once all acks are given.
>
> So to me, a maintainer is someone who can ack a patch for a certain
module
> A committer can commit code, but is responsible to not commit
without
an
>
Another question here -
when you speak of modules - are you referring also for sub modules, for
example - the bll and dal modules in engine core?
I was thinking more across what we call projects, but we could define same
level of granularity to regions in the engine core itself as well.
> ack from the relevant maintainer if the patch encompasses subsystems
> outside of his domain expertise (i.e., committer is not maintainer in
all
> portions the patch set will touch)
>
> Thoughts?
>
> _______________________________________________
> Project-planning mailing list
> Project-planning(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/project-planning
>
_______________________________________________
Project-planning mailing list
Project-planning(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/project-planning
4815
days inactive
4820
days old
41 comments
9 participants
participants (9)
-
Anthony Liguori -
Ayal Baron -
Benedict, Jon -
Carl Trieloff -
Itamar Heim -
Jim Jagielski -
Michael D Day -
Perry Myers -
Yair Zaslavsky