[dpdk-dev] Back-up committers for subtrees

De Lara Guarch, Pablo pablo.de.lara.guarch at intel.com
Wed Feb 21 12:04:51 CET 2018


Hi everyone,

In the last few releases, the DPDK community has experienced a significant growth, specifically in patches submitted and integrated.
Therefore, the number of subtrees has increased, to help maintain the scalability.

Section 5.3 of the Contributor's guide (http://dpdk.org/doc/guides/contributing/patches.html), Maintainers and Sub-trees,
states that there should be a backup maintainer per subtree:

"Ensure that there is a designated back-up maintainer and coordinate a handover for periods where the tree maintainer can't perform their roles."

However, this is not the case for some of the subtrees. This could lead to patch integration delays in case of unavailability (short or long term)
of the subtree committer, especially on busy times, which could lead to a delay in an RC release.

My suggestion is that every primary subtree committer proposes a back-up committer for their subtree.
Once the proposed person agrees on taking this role, they should follow the procedure explained in the documentation:


"Tree maintainers can be added or removed by submitting a patch to the MAINTAINERS file.

The proposer should justify the need for a new sub-tree and should have demonstrated a sufficient level of contributions in the area or to a similar area.

The maintainer should be confirmed by an ack from an existing tree maintainer. Disagreements on trees or maintainers can be brought to the Technical Board.



The backup maintainer for the master tree should be selected from the existing sub-tree maintainers from the project.

The backup maintainer for a sub-tree should be selected from among the component maintainers within that sub-tree."

The patches will be merged mainly by the primary committer, except when this is unavailable, in which case,
the back-up committer will take over, after this unavailability is communicated between the two committers.
This implies that there will be no co-maintainership, to maintain a single point of contact with the mainline tree maintainer.

Any objections?

Thanks,
Pablo




More information about the dev mailing list