Hi, > -----Original Message----- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of De Lara Guarch, > Pablo > Sent: Wednesday, February 21, 2018 11:05 AM > To: dev@dpdk.org > Subject: [dpdk-dev] Back-up committers for subtrees > > 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?
CC'ing Tech board. Could this be discussed in the next meeting? Thanks, Pablo > > Thanks, > Pablo >
