* [PATCH] MAINTAINERS: add more people to the MTD maintainer team @ 2016-10-24 12:35 Boris Brezillon 2016-10-24 13:06 ` Cyrille Pitchen ` (2 more replies) 0 siblings, 3 replies; 6+ messages in thread From: Boris Brezillon @ 2016-10-24 12:35 UTC (permalink / raw) To: Boris Brezillon, Marek Vasut, Richard Weinberger, Cyrille Pitchen, David Woodhouse, Brian Norris, linux-mtd Cc: Artem Bityutskiy, linux-kernel, Ezequiel Garcia 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> --- 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. 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. If you have other ideas, or would like to proceed differently, don't hesitate propose them. 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 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] MAINTAINERS: add more people to the MTD maintainer team 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 2 siblings, 1 reply; 6+ messages in thread From: Cyrille Pitchen @ 2016-10-24 13:06 UTC (permalink / raw) To: Boris Brezillon, Marek Vasut, Richard Weinberger, David Woodhouse, Brian Norris, linux-mtd Cc: Artem Bityutskiy, linux-kernel, Ezequiel Garcia Hi Boris, Le 24/10/2016 à 14:35, Boris Brezillon a écrit : > 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> Acked-by: Cyrille Pitchen <cyrille.pitchen@atmel.com> thanks! :) Cyrille > --- > 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. > > 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. > > If you have other ideas, or would like to proceed differently, don't > hesitate propose them. > > 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/ > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] MAINTAINERS: add more people to the MTD maintainer team 2016-10-24 13:06 ` Cyrille Pitchen @ 2016-10-24 13:11 ` Marek Vasut 0 siblings, 0 replies; 6+ messages in thread From: Marek Vasut @ 2016-10-24 13:11 UTC (permalink / raw) To: Cyrille Pitchen, Boris Brezillon, Richard Weinberger, David Woodhouse, Brian Norris, linux-mtd Cc: Artem Bityutskiy, linux-kernel, Ezequiel Garcia On 10/24/2016 03:06 PM, Cyrille Pitchen wrote: > Hi Boris, > > Le 24/10/2016 à 14:35, Boris Brezillon a écrit : >> 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> > Acked-by: Cyrille Pitchen <cyrille.pitchen@atmel.com> > > thanks! :) Acked-by: Marek Vasut <marek.vasut@gmail.com> Thanks -- Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] MAINTAINERS: add more people to the MTD maintainer team 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 14:39 ` Richard Weinberger 2016-10-27 20:57 ` Brian Norris 2 siblings, 0 replies; 6+ messages in thread From: Richard Weinberger @ 2016-10-24 14:39 UTC (permalink / raw) To: Boris Brezillon, Marek Vasut, Cyrille Pitchen, David Woodhouse, Brian Norris, linux-mtd Cc: Artem Bityutskiy, linux-kernel, Ezequiel Garcia Boris, On 24.10.2016 14:35, 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> > --- > 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. > > 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. > > If you have other ideas, or would like to proceed differently, don't > hesitate propose them. Sounds good to me. Acked-by: Richard Weinberger <richard@nod.at> Thanks, //richard ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] MAINTAINERS: add more people to the MTD maintainer team 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 14:39 ` Richard Weinberger @ 2016-10-27 20:57 ` Brian Norris 2016-10-28 9:23 ` Boris Brezillon 2 siblings, 1 reply; 6+ messages in thread From: Brian Norris @ 2016-10-27 20:57 UTC (permalink / raw) To: Boris Brezillon Cc: Marek Vasut, Richard Weinberger, Cyrille Pitchen, David Woodhouse, linux-mtd, Artem Bityutskiy, linux-kernel, Ezequiel Garcia 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 > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] MAINTAINERS: add more people to the MTD maintainer team 2016-10-27 20:57 ` Brian Norris @ 2016-10-28 9:23 ` Boris Brezillon 0 siblings, 0 replies; 6+ messages in thread From: Boris Brezillon @ 2016-10-28 9:23 UTC (permalink / raw) To: Brian Norris Cc: Artem Bityutskiy, Richard Weinberger, linux-kernel, Marek Vasut, linux-mtd, Ezequiel Garcia, Cyrille Pitchen, David Woodhouse Hi Brian, On Thu, 27 Oct 2016 13:57:32 -0700 Brian Norris <computersforpeace@gmail.com> wrote: > 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? Nope, I'm fine with both solutions. > > 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. Agreed. > 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). Cool. > > 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?). I'm perfectly fine with that. > > 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. I use git notes to do that: each time I apply a patch using pwclient, it adds a note containing the patchwork id, then, I have a pre-push hook that scan all the commits that are being pushed on my nand/next branch and mark the new ones as Accepted in patchwork. I can provide those scripts if you want, but this means it has to be done on the client side, because notes are discarded when you push things to a remote. > > > 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. Well, it all depends on the number of fixes we have. But if we all have permissions to push to the mtd tree, then we can just create a fixes branch where the sub-subsystem maintainers can easily push their fixes and the release owner will then send a PR to Linus before the next -rc. > > > If you have other ideas, or would like to proceed differently, don't > > hesitate propose them. > > Good luck, and happy MTD hacking :) Thanks. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-10-28 9:24 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 2016-10-28 9:23 ` Boris Brezillon
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).