DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Neil Horman <nhorman@tuxdriver.com>,
	Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: dev@dpdk.org, "Mcnamara, John" <john.mcnamara@intel.com>
Subject: Re: [dpdk-dev] Proposal for a new Committer model
Date: Tue, 22 Nov 2016 20:56:23 +0000	[thread overview]
Message-ID: <52ed2fa2-da41-1301-2d56-0fec05b79ce5@intel.com> (raw)
In-Reply-To: <20161122195215.GA4463@hmsreliant.think-freely.org>

On 11/22/2016 7:52 PM, Neil Horman wrote:
> On Mon, Nov 21, 2016 at 09:52:41AM +0100, Thomas Monjalon wrote:
>> 2016-11-18 13:09, Neil Horman:
>>> A) Further promote subtree maintainership.  This was a conversation that I
>>> proposed some time ago, but my proposed granularity was discarded in favor
>>> of something that hasn't worked as well (in my opinion).  That is to say a
>>> few driver pmds (i40e and fm10k come to mind) have their own tree that
>>> send pull requests to Thomas.
>>
>> Yes we tried this fine granularity and stated that it was not working well.
>> We are now using the bigger granularity that you describe below.
>>
> Ok, thats good, but that must be _very_ new.  Looking at your git tree, I see no
> merge commits.  How are you pulling from those subtrees?

next-net tree is active for last three releases.

I guess following is the first commit to the sub-tree:
http://dpdk.org/ml/archives/dev/2016-February/032580.html

sub-trees rebase on top of main tree regularly, that is why there is no
merge commit.

> 
> 
>>> We should be sharding that at a much higher
>>> granularity and using it much more consistently.  That is to say, that we
>>> should have a maintainer for all the ethernet pmds, and another for the
>>> crypto pmds, another for the core eal layer, another for misc libraries
>>> that have low patch volumes, etc.
>>
>> Yes we could open a tree for EAL and another one for the core libraries.
>>
> That could be worthwhile.  Lets see how the net and crypto subtrees work out
> (assuming again that these trees are newly founded)
> 
> 
>>> Each of those subdivisions should have
>>> their own list to communicate on, and each should have a tree that
>>> integrates patches for their own subsystem, and they should on a regular
>>> cycle send pull requests to Thomas.
>>
>> Yes I think it is now a good idea to split the mailing list traffic,
>> at least for netdev and cryptodev.
>>
> Agreed, that serves two purposes, it lowers the volume for people with a
> specific interest (i.e. its a rudimentary filter), and it avoids confusion
> between you and the subtree maintainer (that is to say, you don't have to even
> consider pulling patches that go to the crypo and net lists, you just have to
> trust that they pull those patches in and send you appropriate pull requests).

I still find single mail list more useful.
Also with current process, after -rc2 release, patches directly merged
into main tree instead of sub-trees...

> 
>>> Thomas in turn should by and large,
>>> only be integrating pull requests.  This should address our high-
>>> throughput issue, in that it will allow multiple maintainers to share the
>>> workload, and integration should be relatively easy.
>>
>> Yes in an ideal organization, the last committer does only a last check
>> that technical plan and fairness are respected.
>> So it gives more time to coordinate the plans :)
>>
> Correct.  Thats never 100% accurate of course, some things will still have to
> come to you directly, simply by virtue of the fact that they don't completely
> fit anywhere else, but thats ok, the goal is really just to get your total patch
> volume lower, and replace it with pull requests that you can either trivialy
> mere or figure out with the help of the subtree maintainer.
> 
>>> B) Designate alternates to serve as backups for the maintainer when they
>>> are unavailable.  This provides high-availablility, and sounds very much
>>> like your proposal, but in the interests of clarity, there is still a
>>> single maintainer at any one time, it just may change to ensure the
>>> continued merging of patches, if the primary maintainer isn't available.
>>> Ideally however, those backup alternates arent needed, because most of the
>>> primary maintainers work in merging pull requests, which are done based on
>>> the trust of the submaintainer, and done during a very limited window of
>>> time.  This also partially addreses multi-vendor fairness if your subtree
>>> maintainers come from multiple participating companies.
>>
>> About the merge window, I do not have a strong opinion about how it can be
>> improved. However, I know that closing the window too early makes developer
>> unhappy because it makes wait - between development start and its release -
>> longer.
> 
> This is a fair point, but I'm not talking about closing it early here, all
> I'm suggesting is that, if you do proper pull requests from subtrees, your tree
> Thomas will only need a reasonably small window of time to accept new features,
> because you'll just merge the subtrees, rather than integrating individual
> patches.  E.g. you won't be constantly merging patches over the course of a
> development cycle, your tree's HEAD will mostly consist of merge commits as
> subtree maintainers send you pull requests, and ideally they will send those
> near the start of a window.  How long you keep your merge window open after that
> is up to you.
> 
> Neil
> 
> 
>  
>>

  reply	other threads:[~2016-11-22 20:56 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-17  9:20 Mcnamara, John
2016-11-18  6:00 ` Matthew Hall
2016-11-18 18:09 ` Neil Horman
2016-11-18 19:06   ` Jerin Jacob
2016-11-20  4:17     ` Stephen Hemminger
2016-11-21  8:52   ` Thomas Monjalon
2016-11-22 19:52     ` Neil Horman
2016-11-22 20:56       ` Ferruh Yigit [this message]
2016-11-23 13:48         ` Neil Horman
2016-11-23 14:01           ` Ferruh Yigit
2016-11-23 15:33             ` Neil Horman
2016-11-23 16:21               ` Ferruh Yigit
2016-11-23 20:13                 ` Neil Horman
2016-11-24  9:17                   ` Thomas Monjalon
2016-11-25 19:55                     ` Neil Horman
2016-11-23  8:21       ` Mcnamara, John
2016-11-23 14:11         ` Neil Horman
2016-11-23 15:41           ` Yuanhan Liu
2016-11-23 20:19             ` Neil Horman
2016-11-24  5:53               ` Yuanhan Liu
2016-11-25 20:05                 ` Neil Horman
2016-11-29 19:12   ` Neil Horman
2016-11-30  9:58     ` Mcnamara, John
2016-12-02 16:41       ` Mcnamara, John

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52ed2fa2-da41-1301-2d56-0fec05b79ce5@intel.com \
    --to=ferruh.yigit@intel.com \
    --cc=dev@dpdk.org \
    --cc=john.mcnamara@intel.com \
    --cc=nhorman@tuxdriver.com \
    --cc=thomas.monjalon@6wind.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).