DPDK community structure changes
 help / color / mirror / Atom feed
* [dpdk-moving] Proposal a Committer model
@ 2016-11-15 23:35 Mcnamara, John
  2016-11-16 10:45 ` Thomas Monjalon
  2016-11-16 20:16 ` Dave Neary
  0 siblings, 2 replies; 14+ messages in thread
From: Mcnamara, John @ 2016-11-15 23:35 UTC (permalink / raw)
  To: moving

Hi,

I'd like to propose a change to the DPDK committer model. Currently we have one committer for the master branch of the DPDK project. 

One committer to master represents a single point of failure and at times can be inefficient. There is also no agreed cover for times when the committer is unavailable such as vacation, public holidays, etc. I propose that we change to a multi-committer model for the DPDK project. We should have three committers for each release that can commit changes to the master branch.
 
There are a number of benefits:
 
1. Greater capacity to commit patches.
2. No single points of failure - a committer should always be available if we have three.
3. A more timely committing of patches. More committers should equal a faster turnaround - ideally, maintainers should also provide feedback on patches submitted within a 2-3 day period, as much as possible, to facilitate this. 
4. It follows best practice in creating a successful multi-vendor community - to achieve this we must ensure there is a level playing field for all participants, no single person should be required to make all of the decisions on patches to be included in the release.  

Having multiple committers will require some degree of co-ordination but there are a number of other communities successfully following this model such as Apache, OVS, FD.io, OpenStack etc. so the approach is workable.

John

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [dpdk-moving] Proposal a Committer model
  2016-11-15 23:35 [dpdk-moving] Proposal a Committer model Mcnamara, John
@ 2016-11-16 10:45 ` Thomas Monjalon
  2016-11-16 15:13   ` Bruce Richardson
  2016-11-16 20:16 ` Dave Neary
  1 sibling, 1 reply; 14+ messages in thread
From: Thomas Monjalon @ 2016-11-16 10:45 UTC (permalink / raw)
  To: Mcnamara, John; +Cc: moving, ferruh.yigit, yuanhan.liu, pablo.de.lara.guarch

Hi,

2016-11-15 23:35, Mcnamara, John:
> Hi,
> 
> I'd like to propose a change to the DPDK committer model.
> Currently we have one committer for the master branch of the DPDK project.

Yes it's me. And we have three other committers (CC'ed) for the sub-trees
dpdk-next-net, dpdk-next-virtio and dpdk-next-crypto.

> One committer to master represents a single point of failure

For the release 16.11, 49% of the patches were committed by me.
Other patches came from sub-trees.

> and at times can be inefficient.
> There is also no agreed cover for times when the committer is
> unavailable such as vacation, public holidays, etc.
> I propose that we change to a multi-committer model for the DPDK
> project. We should have three committers for each release that can
> commit changes to the master branch.

Most of the critical work is done in the sub-trees which cover every drivers.
However I feel we could add more sub-trees and especially for EAL.
Ideally, the master branch should just gather commits from the sub-trees.
About long vacation, we may find backup committers for each git tree if
it's really needed.

> There are a number of benefits:
>  
> 1. Greater capacity to commit patches.
> 2. No single points of failure - a committer should always be
> available if we have three.
> 3. A more timely committing of patches. More committers should equal a
> faster turnaround - ideally, maintainers should also provide feedback
> on patches submitted within a 2-3 day period, as much as possible,
> to facilitate this. 
> 4. It follows best practice in creating a successful multi-vendor
> community - to achieve this we must ensure there is a level playing
> field for all participants, no single person should be required to
> make all of the decisions on patches to be included in the release.

Committing faster means making patches disappear from the radar faster.
It does improve neither the quality nor the multi-vendor cooperation.

DPDK is mainly a community of hardware vendors. At the beginning, there
was only one vendor (Intel). After being open on dpdk.org, more vendors
joined. Nowadays we are still working to be more and more vendor neutral.
Examples of current work: bus abstraction, filter API, event model, etc.

I think there are two major issues when working on neutrality in DPDK:

1/ The first challenge and priority for a developer/vendor is to
push access to new hardware features and achieving the best performance.
It is not his priority to think about the genericity of the design
or the API. And he generally doesn't take care of the performance on
other hardware.

2/ There are not enough reviews to challenge genericity of developments.

The only solution to these issues is to give some time for proper reviews.

I would like to highlight again that having more good reviews is a good
way of accelerating pace while improving quality.
It is not so hard or long to commit patches which are ready.
It is longer when the committer must play the reviewer role because of an
obvious lack of review.

About "no single person should be required to make all of the decisions
on patches to be included in the release", I totally agree.
That's why the reviews and discussions must make clear what is the
consensus, the community decision.

> Having multiple committers will require some degree of co-ordination
> but there are a number of other communities successfully following
> this model such as Apache, OVS, FD.io, OpenStack etc. so the approach
> is workable.

I won't play the game of listing and comparing other projects, though
there are a lot (and famous) counter-examples.
The other model is to promote some sub-trees.

The current model pushes people to discuss and decide publicly.
If we had a small committee of 3 persons coordinating to commit, it
means they may are willing to take some decisions privately instead of
relying on community consensus.
And the risk is greater if these people are working for hardware vendors.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [dpdk-moving] Proposal a Committer model
  2016-11-16 10:45 ` Thomas Monjalon
@ 2016-11-16 15:13   ` Bruce Richardson
  2016-11-16 16:23     ` Wiles, Keith
  2016-11-16 19:42     ` Jerin Jacob
  0 siblings, 2 replies; 14+ messages in thread
From: Bruce Richardson @ 2016-11-16 15:13 UTC (permalink / raw)
  To: Thomas Monjalon
  Cc: Mcnamara, John, moving, Yigit, Ferruh, yuanhan.liu,
	De Lara Guarch, Pablo

On Wed, Nov 16, 2016 at 10:45:55AM +0000, Thomas Monjalon wrote:
> Hi,
> 
> 2016-11-15 23:35, Mcnamara, John:
<snip>
> > There are a number of benefits:
> >
> > 1. Greater capacity to commit patches.
> > 2. No single points of failure - a committer should always be
> > available if we have three.
> > 3. A more timely committing of patches. More committers should equal a
> > faster turnaround - ideally, maintainers should also provide feedback
> > on patches submitted within a 2-3 day period, as much as possible,
> > to facilitate this.
> > 4. It follows best practice in creating a successful multi-vendor
> > community - to achieve this we must ensure there is a level playing
> > field for all participants, no single person should be required to
> > make all of the decisions on patches to be included in the release.
> 
> Committing faster means making patches disappear from the radar faster.
> It does improve neither the quality nor the multi-vendor cooperation.
> 
> DPDK is mainly a community of hardware vendors. At the beginning, there
> was only one vendor (Intel). After being open on dpdk.org, more vendors
> joined. Nowadays we are still working to be more and more vendor neutral.
> Examples of current work: bus abstraction, filter API, event model, etc.
> 
> I think there are two major issues when working on neutrality in DPDK:
> 
> 1/ The first challenge and priority for a developer/vendor is to
> push access to new hardware features and achieving the best performance.
> It is not his priority to think about the genericity of the design
> or the API. And he generally doesn't take care of the performance on
> other hardware.
> 
> 2/ There are not enough reviews to challenge genericity of developments.
> 
> The only solution to these issues is to give some time for proper reviews.
> 
> I would like to highlight again that having more good reviews is a good
> way of accelerating pace while improving quality.
> It is not so hard or long to commit patches which are ready.
> It is longer when the committer must play the reviewer role because of an
> obvious lack of review.
> 
> About "no single person should be required to make all of the decisions
> on patches to be included in the release", I totally agree.
> That's why the reviews and discussions must make clear what is the
> consensus, the community decision.
> 

There is one big issue that I see with the current consensus model -
consensus is very slow. There are two ways to get the new features to
the quality we want:
1) we all work together to get the patches to 100% quality and then they
get committed once everyone is happy.
2) a number of the most interested parties work together to get the
patches to the point where they are all happy - where quality may be
only 90% there - and the patches are applied. Anyone who subsequently
has additional comments to improve things supplies patches for the
improvement.

Where this becomes really visible to me is where we have a feature under
discussion for a number of weeks and has reached a consensus among the
few people looking at it. It's been acked and is supposedly ready for
merge. But...then someone new comes and looks at it for the first time,
kicking off a whole new round of discussion that goes on for another number
of weeks.

Personally I'd much rather see a system whereby the first consensus version
gets merged in sooner, so that everyone else can make progress based on
that, rather than having to wait for absolutely everyone to agree. That
way:
a) the improvements can still be made by additional patches,
b) the "shape" of the release becomes clearer sooner as there is less
big bang application of all patches at the end
c) it makes life far easier for people basing patches on other earlier
patches in the same release
d) it makes validation easier since things can be tested earlier as part
of a full tree
AND BEST OF ALL
e) it encourages people to do reviews sooner as they have to catch that
initial review window, or else they are on the hook to do the extra
cleanup patches themselves. [Right now, there is little pressure on
people to do timely reviews - if they review the patch after two days or
two weeks, that patch still has to wait for their agreement to be merged
in.]

Now, I believe multi-committer model is much more conducive to this way
of working (though it does not strictly require multiple committers).
So long as one trusted committer (and all committers need to be trusted)
is happy with a patchset it should go in - provided a reasonable review
period has elapsed. There is too much waiting for everyone to agree
right now.

My 2c.

/Bruce

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [dpdk-moving] Proposal a Committer model
  2016-11-16 15:13   ` Bruce Richardson
@ 2016-11-16 16:23     ` Wiles, Keith
  2016-11-16 19:42     ` Jerin Jacob
  1 sibling, 0 replies; 14+ messages in thread
From: Wiles, Keith @ 2016-11-16 16:23 UTC (permalink / raw)
  To: Richardson, Bruce
  Cc: Thomas Monjalon, Mcnamara, John, moving, Yigit, Ferruh,
	yuanhan.liu, De Lara Guarch, Pablo


> On Nov 16, 2016, at 9:13 AM, Bruce Richardson <bruce.richardson@intel.com> wrote:
> 
> On Wed, Nov 16, 2016 at 10:45:55AM +0000, Thomas Monjalon wrote:
>> Hi,
>> 
>> 2016-11-15 23:35, Mcnamara, John:
> <snip>
>>> There are a number of benefits:
>>> 
>>> 1. Greater capacity to commit patches.
>>> 2. No single points of failure - a committer should always be
>>> available if we have three.
>>> 3. A more timely committing of patches. More committers should equal a
>>> faster turnaround - ideally, maintainers should also provide feedback
>>> on patches submitted within a 2-3 day period, as much as possible,
>>> to facilitate this.
>>> 4. It follows best practice in creating a successful multi-vendor
>>> community - to achieve this we must ensure there is a level playing
>>> field for all participants, no single person should be required to
>>> make all of the decisions on patches to be included in the release.
>> 
>> Committing faster means making patches disappear from the radar faster.
>> It does improve neither the quality nor the multi-vendor cooperation.
>> 
>> DPDK is mainly a community of hardware vendors. At the beginning, there
>> was only one vendor (Intel). After being open on dpdk.org, more vendors
>> joined. Nowadays we are still working to be more and more vendor neutral.
>> Examples of current work: bus abstraction, filter API, event model, etc.
>> 
>> I think there are two major issues when working on neutrality in DPDK:
>> 
>> 1/ The first challenge and priority for a developer/vendor is to
>> push access to new hardware features and achieving the best performance.
>> It is not his priority to think about the genericity of the design
>> or the API. And he generally doesn't take care of the performance on
>> other hardware.
>> 
>> 2/ There are not enough reviews to challenge genericity of developments.
>> 
>> The only solution to these issues is to give some time for proper reviews.
>> 
>> I would like to highlight again that having more good reviews is a good
>> way of accelerating pace while improving quality.
>> It is not so hard or long to commit patches which are ready.
>> It is longer when the committer must play the reviewer role because of an
>> obvious lack of review.
>> 
>> About "no single person should be required to make all of the decisions
>> on patches to be included in the release", I totally agree.
>> That's why the reviews and discussions must make clear what is the
>> consensus, the community decision.
>> 
> 
> There is one big issue that I see with the current consensus model -
> consensus is very slow. There are two ways to get the new features to
> the quality we want:
> 1) we all work together to get the patches to 100% quality and then they
> get committed once everyone is happy.
> 2) a number of the most interested parties work together to get the
> patches to the point where they are all happy - where quality may be
> only 90% there - and the patches are applied. Anyone who subsequently
> has additional comments to improve things supplies patches for the
> improvement.
> 
> Where this becomes really visible to me is where we have a feature under
> discussion for a number of weeks and has reached a consensus among the
> few people looking at it. It's been acked and is supposedly ready for
> merge. But...then someone new comes and looks at it for the first time,
> kicking off a whole new round of discussion that goes on for another number
> of weeks.
> 
> Personally I'd much rather see a system whereby the first consensus version
> gets merged in sooner, so that everyone else can make progress based on
> that, rather than having to wait for absolutely everyone to agree. That
> way:
> a) the improvements can still be made by additional patches,
> b) the "shape" of the release becomes clearer sooner as there is less
> big bang application of all patches at the end
> c) it makes life far easier for people basing patches on other earlier
> patches in the same release
> d) it makes validation easier since things can be tested earlier as part
> of a full tree
> AND BEST OF ALL
> e) it encourages people to do reviews sooner as they have to catch that
> initial review window, or else they are on the hook to do the extra
> cleanup patches themselves. [Right now, there is little pressure on
> people to do timely reviews - if they review the patch after two days or
> two weeks, that patch still has to wait for their agreement to be merged
> in.]
> 
> Now, I believe multi-committer model is much more conducive to this way
> of working (though it does not strictly require multiple committers).
> So long as one trusted committer (and all committers need to be trusted)
> is happy with a patchset it should go in - provided a reasonable review
> period has elapsed. There is too much waiting for everyone to agree
> right now.
> 

+1 I agree, your suggestion to commit sooner then later is reasonable plus timely for DPDK.

I think the multiple committer model is a requirement to get things done in a quicker manner as this does not place more pressure on a single committer.

> My 2c.
> 
> /Bruce

Regards,
Keith

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [dpdk-moving] Proposal a Committer model
  2016-11-16 15:13   ` Bruce Richardson
  2016-11-16 16:23     ` Wiles, Keith
@ 2016-11-16 19:42     ` Jerin Jacob
  2016-11-17  9:27       ` Mcnamara, John
  1 sibling, 1 reply; 14+ messages in thread
From: Jerin Jacob @ 2016-11-16 19:42 UTC (permalink / raw)
  To: Bruce Richardson
  Cc: Thomas Monjalon, Mcnamara, John, moving, Yigit, Ferruh,
	yuanhan.liu, De Lara Guarch, Pablo

On Wed, Nov 16, 2016 at 03:13:49PM +0000, Bruce Richardson wrote:
> On Wed, Nov 16, 2016 at 10:45:55AM +0000, Thomas Monjalon wrote:
> > Hi,
> > 
> > 2016-11-15 23:35, Mcnamara, John:
> <snip>
> > > There are a number of benefits:
> > >
> > > 1. Greater capacity to commit patches.
> > > 2. No single points of failure - a committer should always be
> > > available if we have three.
> > > 3. A more timely committing of patches. More committers should equal a
> > > faster turnaround - ideally, maintainers should also provide feedback
> > > on patches submitted within a 2-3 day period, as much as possible,
> > > to facilitate this.
> > > 4. It follows best practice in creating a successful multi-vendor
> > > community - to achieve this we must ensure there is a level playing
> > > field for all participants, no single person should be required to
> > > make all of the decisions on patches to be included in the release.
> > 
> > Committing faster means making patches disappear from the radar faster.
> > It does improve neither the quality nor the multi-vendor cooperation.
> > 
> > DPDK is mainly a community of hardware vendors. At the beginning, there
> > was only one vendor (Intel). After being open on dpdk.org, more vendors
> > joined. Nowadays we are still working to be more and more vendor neutral.
> > Examples of current work: bus abstraction, filter API, event model, etc.
> > 
> > I think there are two major issues when working on neutrality in DPDK:
> > 
> > 1/ The first challenge and priority for a developer/vendor is to
> > push access to new hardware features and achieving the best performance.
> > It is not his priority to think about the genericity of the design
> > or the API. And he generally doesn't take care of the performance on
> > other hardware.
> > 
> > 2/ There are not enough reviews to challenge genericity of developments.
> > 
> > The only solution to these issues is to give some time for proper reviews.
> > 
> > I would like to highlight again that having more good reviews is a good
> > way of accelerating pace while improving quality.
> > It is not so hard or long to commit patches which are ready.
> > It is longer when the committer must play the reviewer role because of an
> > obvious lack of review.
> > 
> > About "no single person should be required to make all of the decisions
> > on patches to be included in the release", I totally agree.
> > That's why the reviews and discussions must make clear what is the
> > consensus, the community decision.
> > 
> 
> There is one big issue that I see with the current consensus model -
> consensus is very slow. There are two ways to get the new features to
> the quality we want:
> 1) we all work together to get the patches to 100% quality and then they
> get committed once everyone is happy.
> 2) a number of the most interested parties work together to get the
> patches to the point where they are all happy - where quality may be
> only 90% there - and the patches are applied. Anyone who subsequently
> has additional comments to improve things supplies patches for the
> improvement.
> 
> Where this becomes really visible to me is where we have a feature under
> discussion for a number of weeks and has reached a consensus among the
> few people looking at it. It's been acked and is supposedly ready for
> merge. But...then someone new comes and looks at it for the first time,
> kicking off a whole new round of discussion that goes on for another number
> of weeks.
> 
> Personally I'd much rather see a system whereby the first consensus version
> gets merged in sooner, so that everyone else can make progress based on
> that, rather than having to wait for absolutely everyone to agree. That
> way:
> a) the improvements can still be made by additional patches,
> b) the "shape" of the release becomes clearer sooner as there is less
> big bang application of all patches at the end
> c) it makes life far easier for people basing patches on other earlier
> patches in the same release
> d) it makes validation easier since things can be tested earlier as part
> of a full tree
> AND BEST OF ALL
> e) it encourages people to do reviews sooner as they have to catch that
> initial review window, or else they are on the hook to do the extra
> cleanup patches themselves. [Right now, there is little pressure on
> people to do timely reviews - if they review the patch after two days or
> two weeks, that patch still has to wait for their agreement to be merged
> in.]
> 
> Now, I believe multi-committer model is much more conducive to this way
> of working (though it does not strictly require multiple committers).
> So long as one trusted committer (and all committers need to be trusted)
> is happy with a patchset it should go in - provided a reasonable review
> period has elapsed. There is too much waiting for everyone to agree
> right now.

The main question would be who will part of committers list?

I believe the multi-committers model may not fix current consensus
slowness issue. Instead, if we are focusing on reducing the workload of
Thomas, then I think git pull request based scheme will reduce the
workload.

Jerin

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [dpdk-moving] Proposal a Committer model
  2016-11-15 23:35 [dpdk-moving] Proposal a Committer model Mcnamara, John
  2016-11-16 10:45 ` Thomas Monjalon
@ 2016-11-16 20:16 ` Dave Neary
  2016-11-17  8:14   ` Mcnamara, John
  1 sibling, 1 reply; 14+ messages in thread
From: Dave Neary @ 2016-11-16 20:16 UTC (permalink / raw)
  To: Mcnamara, John, moving

Hi,

Does it make sense to have this discussion on "moving"? I thought this
list was reserved for conversations related to the move to the LF, while
this seems like something which is independent of, and orthogonal to,
the move. Shouldn't this be a topic of discussion for the developer
community, dev@dpdk.org?

Thanks,
Dave.

On 11/15/2016 06:35 PM, Mcnamara, John wrote:
> Hi,
> 
> I'd like to propose a change to the DPDK committer model. Currently we have one committer for the master branch of the DPDK project. 
> 
> One committer to master represents a single point of failure and at times can be inefficient. There is also no agreed cover for times when the committer is unavailable such as vacation, public holidays, etc. I propose that we change to a multi-committer model for the DPDK project. We should have three committers for each release that can commit changes to the master branch.
>  
> There are a number of benefits:
>  
> 1. Greater capacity to commit patches.
> 2. No single points of failure - a committer should always be available if we have three.
> 3. A more timely committing of patches. More committers should equal a faster turnaround - ideally, maintainers should also provide feedback on patches submitted within a 2-3 day period, as much as possible, to facilitate this. 
> 4. It follows best practice in creating a successful multi-vendor community - to achieve this we must ensure there is a level playing field for all participants, no single person should be required to make all of the decisions on patches to be included in the release.  
> 
> Having multiple committers will require some degree of co-ordination but there are a number of other communities successfully following this model such as Apache, OVS, FD.io, OpenStack etc. so the approach is workable.
> 
> John
> 

-- 
Dave Neary - NFV/SDN Community Strategy
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +1-978-399-2182 / Cell: +1-978-799-3338

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [dpdk-moving] Proposal a Committer model
  2016-11-16 20:16 ` Dave Neary
@ 2016-11-17  8:14   ` Mcnamara, John
  0 siblings, 0 replies; 14+ messages in thread
From: Mcnamara, John @ 2016-11-17  8:14 UTC (permalink / raw)
  To: Dave Neary, moving



> -----Original Message-----
> From: Dave Neary [mailto:dneary@redhat.com]
> Sent: Wednesday, November 16, 2016 8:17 PM
> To: Mcnamara, John <john.mcnamara@intel.com>; moving@dpdk.org
> Subject: Re: [dpdk-moving] Proposal a Committer model
> 
> Hi,
> 
> Does it make sense to have this discussion on "moving"? I thought this
> list was reserved for conversations related to the move to the LF, while
> this seems like something which is independent of, and orthogonal to, the
> move. Shouldn't this be a topic of discussion for the developer community,
> dev@dpdk.org?
> 


Hi,

I meant to cross post it between moving@dpdk.org and dev@dpdk.org since, as you say, this affects the developer community as well. I'll repost it to dev@dpdk.org.

John

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [dpdk-moving] Proposal a Committer model
  2016-11-16 19:42     ` Jerin Jacob
@ 2016-11-17  9:27       ` Mcnamara, John
  2016-11-17 13:43         ` Thomas Monjalon
                           ` (2 more replies)
  0 siblings, 3 replies; 14+ messages in thread
From: Mcnamara, John @ 2016-11-17  9:27 UTC (permalink / raw)
  To: Jerin Jacob, Richardson, Bruce
  Cc: Thomas Monjalon, moving, Yigit, Ferruh, yuanhan.liu,
	De Lara Guarch, Pablo



> -----Original Message-----
> From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> Sent: Wednesday, November 16, 2016 7:43 PM
> To: Richardson, Bruce <bruce.richardson@intel.com>
> Cc: Thomas Monjalon <thomas.monjalon@6wind.com>; Mcnamara, John
> <john.mcnamara@intel.com>; moving@dpdk.org; Yigit, Ferruh
> <ferruh.yigit@intel.com>; yuanhan.liu@linux.intel.com; De Lara Guarch,
> Pablo <pablo.de.lara.guarch@intel.com>
> Subject: Re: [dpdk-moving] Proposal a Committer model
> 
> On Wed, Nov 16, 2016 at 03:13:49PM +0000, Bruce Richardson wrote:
> > On Wed, Nov 16, 2016 at 10:45:55AM +0000, Thomas Monjalon wrote:
> > 
> > 
> > ...
> >
> > Now, I believe multi-committer model is much more conducive to this
> > way of working (though it does not strictly require multiple
> committers).
> > So long as one trusted committer (and all committers need to be
> > trusted) is happy with a patchset it should go in - provided a
> > reasonable review period has elapsed. There is too much waiting for
> > everyone to agree right now.
> 
> The main question would be who will part of committers list?

Hi,

The initial list could be made up from someone from 6Wind, Intel and an ARM based company. If it is felt that someone else could be added then that could be proposed.

The OvS community had reasonably good guidelines about adding/removing committers. I'd suggest that we use something similar:

https://github.com/openvswitch/ovs/blob/master/Documentation/committer-grant-revocation.rst


> 
> I believe the multi-committers model may not fix current consensus
> slowness issue. Instead, if we are focusing on reducing the workload of
> Thomas, then I think git pull request based scheme will reduce the
> workload.

So, something like a Gerrit model?

John

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [dpdk-moving] Proposal a Committer model
  2016-11-17  9:27       ` Mcnamara, John
@ 2016-11-17 13:43         ` Thomas Monjalon
  2016-11-17 14:05           ` Wiles, Keith
  2016-11-17 22:57         ` Ed Warnicke
  2016-11-18 10:45         ` Hemant Agrawal
  2 siblings, 1 reply; 14+ messages in thread
From: Thomas Monjalon @ 2016-11-17 13:43 UTC (permalink / raw)
  To: Mcnamara, John, Jerin Jacob
  Cc: Richardson, Bruce, moving, Yigit, Ferruh, yuanhan.liu,
	De Lara Guarch, Pablo

2016-11-17 09:27, Mcnamara, John:
> From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> > I believe the multi-committers model may not fix current consensus
> > slowness issue. Instead, if we are focusing on reducing the workload of
> > Thomas, then I think git pull request based scheme will reduce the
> > workload.
> 
> So, something like a Gerrit model?

No, the mechanics of committing is not time consuming.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [dpdk-moving] Proposal a Committer model
  2016-11-17 13:43         ` Thomas Monjalon
@ 2016-11-17 14:05           ` Wiles, Keith
  2016-11-18 10:45             ` Hemant Agrawal
  0 siblings, 1 reply; 14+ messages in thread
From: Wiles, Keith @ 2016-11-17 14:05 UTC (permalink / raw)
  To: Thomas Monjalon
  Cc: Mcnamara, John, Jerin Jacob, Richardson, Bruce, moving, Yigit,
	Ferruh, yuanhan.liu, De Lara Guarch, Pablo


> On Nov 17, 2016, at 7:43 AM, Thomas Monjalon <thomas.monjalon@6wind.com> wrote:
> 
> 2016-11-17 09:27, Mcnamara, John:
>> From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
>>> I believe the multi-committers model may not fix current consensus
>>> slowness issue. Instead, if we are focusing on reducing the workload of
>>> Thomas, then I think git pull request based scheme will reduce the
>>> workload.
>> 
>> So, something like a Gerrit model?
> 
> No, the mechanics of committing is not time consuming.

The time consuming part is the reviewing the patch and using Gerrit does attempt to make sure the reviewers are emailed directly. This to me helps to require reviews as sometimes the huge email volume on the list is difficult to see patches someone needs to review.

I would much more prefer one email (from Gerrit) per patch set instead of 10 or 30 emails in some cases for a single email. Using gerrit also combines the patch review comments, patchwork and email list into one tool plus it can kick off the build and checkpatch processes.

Having a Gerrit model is not a bad process model and allows for multiple committers. I know it is a new tool and it is pretty simple to use. 

> 

Regards,
Keith

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [dpdk-moving] Proposal a Committer model
  2016-11-17  9:27       ` Mcnamara, John
  2016-11-17 13:43         ` Thomas Monjalon
@ 2016-11-17 22:57         ` Ed Warnicke
  2016-11-18 10:45         ` Hemant Agrawal
  2 siblings, 0 replies; 14+ messages in thread
From: Ed Warnicke @ 2016-11-17 22:57 UTC (permalink / raw)
  To: Mcnamara, John
  Cc: Jerin Jacob, Richardson, Bruce, Thomas Monjalon, moving, Yigit,
	Ferruh, yuanhan.liu, De Lara Guarch, Pablo

[-- Attachment #1: Type: text/plain, Size: 2579 bytes --]

My recommendation would be this:

1)  Start with a list of folks who've made significant contributions to the
tree in question
2)  Potentially winnow it from there

For existing code bases, its important to start with folks who have a
meritocratic history of contribution.
Its important to note that is not necessarily the only criteria, there are
a lot of intangibles as well.  Not everybody who writes a lot of code wants
to be a committer or would be good at being a committer.  But if there is
code to have history with, and you don't have history of contributing to
it, it probably doesn't make sense for you to be a committer.

Ed

On Thu, Nov 17, 2016 at 1:27 AM, Mcnamara, John <john.mcnamara@intel.com>
wrote:

>
>
> > -----Original Message-----
> > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> > Sent: Wednesday, November 16, 2016 7:43 PM
> > To: Richardson, Bruce <bruce.richardson@intel.com>
> > Cc: Thomas Monjalon <thomas.monjalon@6wind.com>; Mcnamara, John
> > <john.mcnamara@intel.com>; moving@dpdk.org; Yigit, Ferruh
> > <ferruh.yigit@intel.com>; yuanhan.liu@linux.intel.com; De Lara Guarch,
> > Pablo <pablo.de.lara.guarch@intel.com>
> > Subject: Re: [dpdk-moving] Proposal a Committer model
> >
> > On Wed, Nov 16, 2016 at 03:13:49PM +0000, Bruce Richardson wrote:
> > > On Wed, Nov 16, 2016 at 10:45:55AM +0000, Thomas Monjalon wrote:
> > >
> > >
> > > ...
> > >
> > > Now, I believe multi-committer model is much more conducive to this
> > > way of working (though it does not strictly require multiple
> > committers).
> > > So long as one trusted committer (and all committers need to be
> > > trusted) is happy with a patchset it should go in - provided a
> > > reasonable review period has elapsed. There is too much waiting for
> > > everyone to agree right now.
> >
> > The main question would be who will part of committers list?
>
> Hi,
>
> The initial list could be made up from someone from 6Wind, Intel and an
> ARM based company. If it is felt that someone else could be added then that
> could be proposed.
>
> The OvS community had reasonably good guidelines about adding/removing
> committers. I'd suggest that we use something similar:
>
> https://github.com/openvswitch/ovs/blob/master/
> Documentation/committer-grant-revocation.rst
>
>
> >
> > I believe the multi-committers model may not fix current consensus
> > slowness issue. Instead, if we are focusing on reducing the workload of
> > Thomas, then I think git pull request based scheme will reduce the
> > workload.
>
> So, something like a Gerrit model?
>
> John
>
>

[-- Attachment #2: Type: text/html, Size: 3944 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [dpdk-moving] Proposal a Committer model
  2016-11-17 14:05           ` Wiles, Keith
@ 2016-11-18 10:45             ` Hemant Agrawal
  2016-11-18 17:14               ` Stephen Hemminger
  0 siblings, 1 reply; 14+ messages in thread
From: Hemant Agrawal @ 2016-11-18 10:45 UTC (permalink / raw)
  To: Wiles, Keith, Thomas Monjalon
  Cc: Mcnamara, John, Jerin Jacob, Richardson, Bruce, moving, Yigit,
	Ferruh, yuanhan.liu, De Lara Guarch, Pablo



> Sent: Thursday, November 17, 2016 7:36 PM
> > On Nov 17, 2016, at 7:43 AM, Thomas Monjalon
> <thomas.monjalon@6wind.com> wrote:
> >
> > 2016-11-17 09:27, Mcnamara, John:
> >> From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> >>> I believe the multi-committers model may not fix current consensus
> >>> slowness issue. Instead, if we are focusing on reducing the workload
> >>> of Thomas, then I think git pull request based scheme will reduce
> >>> the workload.
> >>
> >> So, something like a Gerrit model?
> >
> > No, the mechanics of committing is not time consuming.
> 
> The time consuming part is the reviewing the patch and using Gerrit does
> attempt to make sure the reviewers are emailed directly. This to me helps to
> require reviews as sometimes the huge email volume on the list is difficult to see
> patches someone needs to review.
> 
> I would much more prefer one email (from Gerrit) per patch set instead of 10 or
> 30 emails in some cases for a single email. Using gerrit also combines the patch
> review comments, patchwork and email list into one tool plus it can kick off the
> build and checkpatch processes.
> 
> Having a Gerrit model is not a bad process model and allows for multiple
> committers. I know it is a new tool and it is pretty simple to use.

[Hemant] I also agree that Gerrit is much better from committer, reviewer and submitter prospective. 

Why are we having reservations in moving to Gerrit? 


> 
> >
> 
> Regards,
> Keith

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [dpdk-moving] Proposal a Committer model
  2016-11-17  9:27       ` Mcnamara, John
  2016-11-17 13:43         ` Thomas Monjalon
  2016-11-17 22:57         ` Ed Warnicke
@ 2016-11-18 10:45         ` Hemant Agrawal
  2 siblings, 0 replies; 14+ messages in thread
From: Hemant Agrawal @ 2016-11-18 10:45 UTC (permalink / raw)
  To: Mcnamara, John, Jerin Jacob, Richardson, Bruce
  Cc: Thomas Monjalon, moving, Yigit, Ferruh, yuanhan.liu,
	De Lara Guarch,  Pablo

> -----Original Message-----
> From: moving [mailto:moving-bounces@dpdk.org] On Behalf Of Mcnamara,
> John
> Sent: Thursday, November 17, 2016 2:57 PM
> > -----Original Message-----
> > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> > Sent: Wednesday, November 16, 2016 7:43 PM
> > To: Richardson, Bruce <bruce.richardson@intel.com>
> > Cc: Thomas Monjalon <thomas.monjalon@6wind.com>; Mcnamara, John
> > <john.mcnamara@intel.com>; moving@dpdk.org; Yigit, Ferruh
> > <ferruh.yigit@intel.com>; yuanhan.liu@linux.intel.com; De Lara Guarch,
> > Pablo <pablo.de.lara.guarch@intel.com>
> > Subject: Re: [dpdk-moving] Proposal a Committer model
> >
> > On Wed, Nov 16, 2016 at 03:13:49PM +0000, Bruce Richardson wrote:
> > > On Wed, Nov 16, 2016 at 10:45:55AM +0000, Thomas Monjalon wrote:
> > >
> > >
> > > ...
> > >
> > > Now, I believe multi-committer model is much more conducive to this
> > > way of working (though it does not strictly require multiple
> > committers).
> > > So long as one trusted committer (and all committers need to be
> > > trusted) is happy with a patchset it should go in - provided a
> > > reasonable review period has elapsed. There is too much waiting for
> > > everyone to agree right now.
> >
> > The main question would be who will part of committers list?
> 
> Hi,
> 
> The initial list could be made up from someone from 6Wind, Intel and an ARM
> based company. If it is felt that someone else could be added then that could be
> proposed.
> 
> The OvS community had reasonably good guidelines about adding/removing
> committers. I'd suggest that we use something similar:
> 
> https://github.com/openvswitch/ovs/blob/master/Documentation/committer-
> grant-revocation.rst
> 
> 
[Hemant]  The OVS guidelines are good one. 

Again,  there should be a cap on numbers of committers from a single organization. 

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [dpdk-moving] Proposal a Committer model
  2016-11-18 10:45             ` Hemant Agrawal
@ 2016-11-18 17:14               ` Stephen Hemminger
  0 siblings, 0 replies; 14+ messages in thread
From: Stephen Hemminger @ 2016-11-18 17:14 UTC (permalink / raw)
  To: Hemant Agrawal
  Cc: Wiles, Keith, Thomas Monjalon, Mcnamara, John, Jerin Jacob,
	Richardson, Bruce, moving, Yigit, Ferruh, yuanhan.liu,
	De Lara Guarch, Pablo

On Fri, 18 Nov 2016 10:45:39 +0000
Hemant Agrawal <hemant.agrawal@nxp.com> wrote:

> > Sent: Thursday, November 17, 2016 7:36 PM  
> > > On Nov 17, 2016, at 7:43 AM, Thomas Monjalon  
> > <thomas.monjalon@6wind.com> wrote:  
> > >
> > > 2016-11-17 09:27, Mcnamara, John:  
> > >> From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]  
> > >>> I believe the multi-committers model may not fix current consensus
> > >>> slowness issue. Instead, if we are focusing on reducing the workload
> > >>> of Thomas, then I think git pull request based scheme will reduce
> > >>> the workload.  
> > >>
> > >> So, something like a Gerrit model?  
> > >
> > > No, the mechanics of committing is not time consuming.  
> > 
> > The time consuming part is the reviewing the patch and using Gerrit does
> > attempt to make sure the reviewers are emailed directly. This to me helps to
> > require reviews as sometimes the huge email volume on the list is difficult to see
> > patches someone needs to review.
> > 
> > I would much more prefer one email (from Gerrit) per patch set instead of 10 or
> > 30 emails in some cases for a single email. Using gerrit also combines the patch
> > review comments, patchwork and email list into one tool plus it can kick off the
> > build and checkpatch processes.
> > 
> > Having a Gerrit model is not a bad process model and allows for multiple
> > committers. I know it is a new tool and it is pretty simple to use.  
> 
> [Hemant] I also agree that Gerrit is much better from committer, reviewer and submitter prospective. 
> 
> Why are we having reservations in moving to Gerrit? 

Because Gerrit has many flaws:

https://kernel-recipes.org/en/2016/talks/patches-carved-into-stone-tablets/

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2016-11-18 17:14 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-11-15 23:35 [dpdk-moving] Proposal a Committer model Mcnamara, John
2016-11-16 10:45 ` Thomas Monjalon
2016-11-16 15:13   ` Bruce Richardson
2016-11-16 16:23     ` Wiles, Keith
2016-11-16 19:42     ` Jerin Jacob
2016-11-17  9:27       ` Mcnamara, John
2016-11-17 13:43         ` Thomas Monjalon
2016-11-17 14:05           ` Wiles, Keith
2016-11-18 10:45             ` Hemant Agrawal
2016-11-18 17:14               ` Stephen Hemminger
2016-11-17 22:57         ` Ed Warnicke
2016-11-18 10:45         ` Hemant Agrawal
2016-11-16 20:16 ` Dave Neary
2016-11-17  8:14   ` Mcnamara, John

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).