From: Brian Norris <computersforpeace@gmail.com>
To: Boris Brezillon <boris.brezillon@free-electrons.com>
Cc: Marek Vasut <marek.vasut@gmail.com>,
Richard Weinberger <richard@nod.at>,
Cyrille Pitchen <cyrille.pitchen@atmel.com>,
David Woodhouse <dwmw2@infradead.org>,
linux-mtd@lists.infradead.org,
Artem Bityutskiy <dedekind1@gmail.com>,
linux-kernel@vger.kernel.org,
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Subject: Re: [PATCH] MAINTAINERS: add more people to the MTD maintainer team
Date: Thu, 27 Oct 2016 13:57:32 -0700 [thread overview]
Message-ID: <20161027205732.GB1582@localhost> (raw)
In-Reply-To: <1477312526-7563-1-git-send-email-boris.brezillon@free-electrons.com>
On Mon, Oct 24, 2016 at 02:35:26PM +0200, Boris Brezillon wrote:
> Brian has been maintaining the MTD subsystem alone for several years
> now, and maintaining such a subsystem can really be time consuming.
>
> Create a maintainer team formed of the most active MTD contributors
> to help Brian with this task, which will hopefully improve the
> subsystem reactivity.
>
> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Thanks to all the volunteers! Applied to linux-mtd.git. Will send to
Linus once we can collect other outstanding fixes.
> ---
> Hi all,
>
> I'm just trying to summarize what I understood the process would be,
> don't hesitate to correct me if I'm wrong.
>
> For each release we will assign a specific MTD maintainer which will be
> responsible for taking MTD core patches and pulling spi-nor and nand PRs
> into the MTD tree and eventually send one or several PRs to Linus.
I had imagined that the "release owner" role wouldn't necessarily imply
exclusive commit rights, but that they'd just the primary one
responsible. I don't see a problem with other maintainer(s) applying
patches as long as they've gotten the proper review. Or would that be
too confusing?
But that's something not discussed here so far: review requirements. I
expect we need a minimum of 1 reviewer (where reviewer may be the one
applying it) that isn't the author. And for bigger things (i.e., not
trivial and not just a leaf driver) maybe 2. Hopefully in the form of
explicit Reviewed-by or Acked-by. And that means that for NAND or
SPI-NOR PRs, that may require preempting the "release owner" (e.g., if
Boris is supposed to be the "owner" for a release, he'll have to find
someone else to review his NAND PR -- I'm still happy to do so for now,
but others are welcome).
And for PRs to Linus: if y'all don't mind, I'd still like to have a
last look at things from the brand new maintainers, at least for now.
(Boris and Richard would probably also be good candidates for the last
review / PR, as they've proven to maintain things well already.) I'm
sure that can be relaxed after a release or so (say, after 4.10?).
Thoughts?
Also, everyone should make their attempts to get their PGP keys into the
web-of-trust. And we need David to get people infradead.org permissions.
One other point of order: if it isn't clear, I've been using
l2-mtd.git/master as the -next "branch" and linux-mtd.git/master as the
-current-release "branch." We should work extra hard to avoid rebasing
in either of those trees now. In fact, I'll go disable non-ff pushes
now...
I also currently have a server-side post-receive git hook installed in
l2-mtd.git that tries to update patchwork. It's not 100% accurate
because it matches contents (which might be the same across multiple
revisions of a series). I should probably remove or modify that before
others start pushing there.
> For fixes that are submitted after -rc1, I usually ask Brian to apply
> them directly into the MTD tree (I don't think there's a real need to
> prepare spi-nor and nand PRs for fixes), so we can proceed the same
> way: ask the maintainer assigned to this release to also take care of
> applying fixes and sending PRs to Linus before each -rc.
I'm flexible on this. If the "release owner" is attentive enough,
applying them to the MTD tree works just fine. But if a PR helps (as
Boris is planning to do right now for 4.9-rc) I don't see a problem with
that either.
> If you have other ideas, or would like to proceed differently, don't
> hesitate propose them.
Good luck, and happy MTD hacking :)
Brian
> Thanks,
>
> Boris
> ---
> MAINTAINERS | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1cd38a7e0064..cbf9583fdbe7 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7912,6 +7912,10 @@ F: mm/
> MEMORY TECHNOLOGY DEVICES (MTD)
> M: David Woodhouse <dwmw2@infradead.org>
> M: Brian Norris <computersforpeace@gmail.com>
> +M: Boris Brezillon <boris.brezillon@free-electrons.com>
> +M: Marek Vasut <marek.vasut@gmail.com>
> +M: Richard Weinberger <richard@nod.at>
> +M: Cyrille Pitchen <cyrille.pitchen@atmel.com>
> L: linux-mtd@lists.infradead.org
> W: http://www.linux-mtd.infradead.org/
> Q: http://patchwork.ozlabs.org/project/linux-mtd/list/
> --
> 2.7.4
>
next prev parent reply other threads:[~2016-10-27 20:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-24 12:35 [PATCH] MAINTAINERS: add more people to the MTD maintainer team Boris Brezillon
2016-10-24 13:06 ` Cyrille Pitchen
2016-10-24 13:11 ` Marek Vasut
2016-10-24 14:39 ` Richard Weinberger
2016-10-27 20:57 ` Brian Norris [this message]
2016-10-28 9:23 ` Boris Brezillon
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=20161027205732.GB1582@localhost \
--to=computersforpeace@gmail.com \
--cc=boris.brezillon@free-electrons.com \
--cc=cyrille.pitchen@atmel.com \
--cc=dedekind1@gmail.com \
--cc=dwmw2@infradead.org \
--cc=ezequiel@vanguardiasur.com.ar \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marek.vasut@gmail.com \
--cc=richard@nod.at \
/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