DPDK patches and discussions
 help / color / mirror / Atom feed
From: "De Lara Guarch, Pablo" <pablo.de.lara.guarch@intel.com>
To: "dev@dpdk.org" <dev@dpdk.org>
Subject: [dpdk-dev] Back-up committers for subtrees
Date: Wed, 21 Feb 2018 11:04:51 +0000	[thread overview]
Message-ID: <E115CCD9D858EF4F90C690B0DCB4D8976CC9D109@IRSMSX108.ger.corp.intel.com> (raw)

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

             reply	other threads:[~2018-02-21 11:04 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-21 11:04 De Lara Guarch, Pablo [this message]
2018-02-27  8:59 ` De Lara Guarch, Pablo

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=E115CCD9D858EF4F90C690B0DCB4D8976CC9D109@IRSMSX108.ger.corp.intel.com \
    --to=pablo.de.lara.guarch@intel.com \
    --cc=dev@dpdk.org \
    /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).