* [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-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 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-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
* 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 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-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
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).