[dpdk-dev] Proposal for a new Committer model

[Thomas Monjalon]

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.

> 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.

> 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.

> 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 :)

> 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.