| Message ID | 0a3eaa21fb0f38743308c9cc9fc5d2373f4877de.1476802288.git.cyrille.pitchen@atmel.com |
|---|---|
| State | Superseded |
| Headers | show |
On 10/18/2016 04:58 PM, Cyrille Pitchen wrote: > I would like to volunteer as a maintainer for the SPI NOR part of the MTD > subsystem. > > Over the last months, a significant number of SPI NOR related patches have > been submitted, some of them have been reviewed, but very few have finally > been merged. Hence, the number of pending SPI NOR related patches continues > to increase over the time. > > Through my work on SPI NOR memories from many manufacturers over the last > two years, I've gained a solid understanding of this technology. > I've already helped by reviewing patches from other contributors on the > mailing list, and would like to help getting those patches integrated by > volunteering as a maintainer for this specific area. > > Boris Brezillon has already stepped up as a maintainer for the NAND > sub-subsystem in MTD, and the SPI NOR sub-subsystem could be handled in > the same way: I would be reviewing patches touching this area, collecting > them and sending pull requests to Brian Norris. > > Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com> Let me know if you need co-maintainer. > --- > MAINTAINERS | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 757f9c4b388d..73e9319b3f9f 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -11390,6 +11390,16 @@ W: http://www.st.com/spear > S: Maintained > F: drivers/clk/spear/ > > +SPI NOR SUBSYSTEM > +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/ > +T: git git://github.com/spi-nor/linux.git > +S: Maintained > +F: drivers/mtd/spi-nor/ > +F: include/linux/mtd/spi-nor.h > + > SPI SUBSYSTEM > M: Mark Brown <broonie@kernel.org> > L: linux-spi@vger.kernel.org >
On Tue, Oct 18, 2016 at 5:17 PM, Marek Vasut <marex@denx.de> wrote: > On 10/18/2016 04:58 PM, Cyrille Pitchen wrote: >> I would like to volunteer as a maintainer for the SPI NOR part of the MTD >> subsystem. >> >> Over the last months, a significant number of SPI NOR related patches have >> been submitted, some of them have been reviewed, but very few have finally >> been merged. Hence, the number of pending SPI NOR related patches continues >> to increase over the time. >> >> Through my work on SPI NOR memories from many manufacturers over the last >> two years, I've gained a solid understanding of this technology. >> I've already helped by reviewing patches from other contributors on the >> mailing list, and would like to help getting those patches integrated by >> volunteering as a maintainer for this specific area. >> >> Boris Brezillon has already stepped up as a maintainer for the NAND >> sub-subsystem in MTD, and the SPI NOR sub-subsystem could be handled in >> the same way: I would be reviewing patches touching this area, collecting >> them and sending pull requests to Brian Norris. I'd suggest you send pull requests directly to Linus. Same for NAND. >> Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com> > > Let me know if you need co-maintainer. +1 While we are here, what about forming a MTD maintainer team? This concept works very well for other subsystems.
Le 18/10/2016 à 17:30, Richard Weinberger a écrit : > On Tue, Oct 18, 2016 at 5:17 PM, Marek Vasut <marex@denx.de> wrote: >> On 10/18/2016 04:58 PM, Cyrille Pitchen wrote: >>> I would like to volunteer as a maintainer for the SPI NOR part of the MTD >>> subsystem. >>> >>> Over the last months, a significant number of SPI NOR related patches have >>> been submitted, some of them have been reviewed, but very few have finally >>> been merged. Hence, the number of pending SPI NOR related patches continues >>> to increase over the time. >>> >>> Through my work on SPI NOR memories from many manufacturers over the last >>> two years, I've gained a solid understanding of this technology. >>> I've already helped by reviewing patches from other contributors on the >>> mailing list, and would like to help getting those patches integrated by >>> volunteering as a maintainer for this specific area. >>> >>> Boris Brezillon has already stepped up as a maintainer for the NAND >>> sub-subsystem in MTD, and the SPI NOR sub-subsystem could be handled in >>> the same way: I would be reviewing patches touching this area, collecting >>> them and sending pull requests to Brian Norris. > > I'd suggest you send pull requests directly to Linus. > Same for NAND. > >>> Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com> >> >> Let me know if you need co-maintainer. > > +1 > > While we are here, what about forming a MTD maintainer team? > This concept works very well for other subsystems. > I totally agree with you so if Marek and you volunteer as well, your help will be precious!
On 18.10.2016 17:55, Cyrille Pitchen wrote: > Le 18/10/2016 à 17:30, Richard Weinberger a écrit : >> On Tue, Oct 18, 2016 at 5:17 PM, Marek Vasut <marex@denx.de> wrote: >>> On 10/18/2016 04:58 PM, Cyrille Pitchen wrote: >>>> I would like to volunteer as a maintainer for the SPI NOR part of the MTD >>>> subsystem. >>>> >>>> Over the last months, a significant number of SPI NOR related patches have >>>> been submitted, some of them have been reviewed, but very few have finally >>>> been merged. Hence, the number of pending SPI NOR related patches continues >>>> to increase over the time. >>>> >>>> Through my work on SPI NOR memories from many manufacturers over the last >>>> two years, I've gained a solid understanding of this technology. >>>> I've already helped by reviewing patches from other contributors on the >>>> mailing list, and would like to help getting those patches integrated by >>>> volunteering as a maintainer for this specific area. >>>> >>>> Boris Brezillon has already stepped up as a maintainer for the NAND >>>> sub-subsystem in MTD, and the SPI NOR sub-subsystem could be handled in >>>> the same way: I would be reviewing patches touching this area, collecting >>>> them and sending pull requests to Brian Norris. >> >> I'd suggest you send pull requests directly to Linus. >> Same for NAND. >> >>>> Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com> >>> >>> Let me know if you need co-maintainer. >> >> +1 >> >> While we are here, what about forming a MTD maintainer team? >> This concept works very well for other subsystems. >> > > I totally agree with you so if Marek and you volunteer as well, your help > will be precious! Well, my SPI-NOR fu is not strong. And UBI/UBIFS keeps me busy. But if Brian likes the idea of having a MTD maintainer team I'll offer my help. Thanks, //richard
On 10/18/2016 06:15 PM, Richard Weinberger wrote: > On 18.10.2016 17:55, Cyrille Pitchen wrote: >> Le 18/10/2016 à 17:30, Richard Weinberger a écrit : >>> On Tue, Oct 18, 2016 at 5:17 PM, Marek Vasut <marex@denx.de> wrote: >>>> On 10/18/2016 04:58 PM, Cyrille Pitchen wrote: >>>>> I would like to volunteer as a maintainer for the SPI NOR part of the MTD >>>>> subsystem. >>>>> >>>>> Over the last months, a significant number of SPI NOR related patches have >>>>> been submitted, some of them have been reviewed, but very few have finally >>>>> been merged. Hence, the number of pending SPI NOR related patches continues >>>>> to increase over the time. >>>>> >>>>> Through my work on SPI NOR memories from many manufacturers over the last >>>>> two years, I've gained a solid understanding of this technology. >>>>> I've already helped by reviewing patches from other contributors on the >>>>> mailing list, and would like to help getting those patches integrated by >>>>> volunteering as a maintainer for this specific area. >>>>> >>>>> Boris Brezillon has already stepped up as a maintainer for the NAND >>>>> sub-subsystem in MTD, and the SPI NOR sub-subsystem could be handled in >>>>> the same way: I would be reviewing patches touching this area, collecting >>>>> them and sending pull requests to Brian Norris. >>> >>> I'd suggest you send pull requests directly to Linus. >>> Same for NAND. >>> >>>>> Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com> >>>> >>>> Let me know if you need co-maintainer. >>> >>> +1 >>> >>> While we are here, what about forming a MTD maintainer team? >>> This concept works very well for other subsystems. >>> >> >> I totally agree with you so if Marek and you volunteer as well, your help >> will be precious! > > Well, my SPI-NOR fu is not strong. And UBI/UBIFS keeps me busy. > But if Brian likes the idea of having a MTD maintainer team I'll offer my help. After talking to Wolfram Sang a bit about the maintainer overload at ELCE, I think the least I can do here is help reviewing patches. The CQSPI upstreaming experience was real crap, it took a long time, so we should certainly do something about it.
+ others On Tue, Oct 18, 2016 at 06:15:23PM +0200, Richard Weinberger wrote: > On 18.10.2016 17:55, Cyrille Pitchen wrote: > > Le 18/10/2016 à 17:30, Richard Weinberger a écrit : > >> On Tue, Oct 18, 2016 at 5:17 PM, Marek Vasut <marex@denx.de> wrote: > >>> On 10/18/2016 04:58 PM, Cyrille Pitchen wrote: > >>>> I would like to volunteer as a maintainer for the SPI NOR part of the MTD > >>>> subsystem. Awesome! > >>>> Over the last months, a significant number of SPI NOR related patches have > >>>> been submitted, some of them have been reviewed, but very few have finally > >>>> been merged. Hence, the number of pending SPI NOR related patches continues > >>>> to increase over the time. Agreed, and sorry. But I guess the delays had the side effect of forcing peoples hands, instead of delaying the inevitable. > >>>> Through my work on SPI NOR memories from many manufacturers over the last > >>>> two years, I've gained a solid understanding of this technology. > >>>> I've already helped by reviewing patches from other contributors on the > >>>> mailing list, and would like to help getting those patches integrated by > >>>> volunteering as a maintainer for this specific area. Agreed. > >>>> Boris Brezillon has already stepped up as a maintainer for the NAND > >>>> sub-subsystem in MTD, and the SPI NOR sub-subsystem could be handled in > >>>> the same way: I would be reviewing patches touching this area, collecting > >>>> them and sending pull requests to Brian Norris. > >> > >> I'd suggest you send pull requests directly to Linus. > >> Same for NAND. I could go with either method I suppose, but I don't personally like the idea of splitting out the various bits of MTD into *completely* independent lines of development. As long as someone (not necessarily me) can manage pulling the sub-subsystems together, I think it would make sense to have 1 PR for Linus for non-UBI/FS MTD changes. > >>>> Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com> > >>> > >>> Let me know if you need co-maintainer. > >> > >> +1 +1, I think I've not-so-subtly suggested this to Marek previously. > >> While we are here, what about forming a MTD maintainer team? > >> This concept works very well for other subsystems. > >> > > > > I totally agree with you so if Marek and you volunteer as well, your help > > will be precious! > > Well, my SPI-NOR fu is not strong. And UBI/UBIFS keeps me busy. > But if Brian likes the idea of having a MTD maintainer team I'll offer my help. I think a MTD maintainer team would be good to try, and I think it might help to resolve my above complaint; a maintainer team could help to make sure that everything can be coordinated in one tree + pull request, without adding too many extra points of failure (e.g., so we don't have awesome SPI NOR and NAND trees get bogged down by a slow MTD pull). Random thoughts: Does it make sense to still use infradead.org? We'd need to add a few users there. Trust? I have met most of you in person, but not all, and I don't have signed keys from all of you. I don't know what the best way to get a group-writeable repo with credentials for all of you that we can trust. (FWIW, neither Artem nor David met me, but they saw it fit to grant me infradead.org access ;) ) Coordination: how do we avoid stepping on each other's toes? We'd have to definitely 100% kill 'git push -f' and 'git rebase'. Also, would patchwork help or hurt us here? I think Boris and I have been sort of using it, but it's still got a pretty good backlog (partly real -- i.e., the cause for this thread; and partly artificial, due to accounting). What to do about mtd-utils.git? That's been languishing a bit, and it has no release schedule. Maybe we want a plan for that too. BTW, will anybody be at Linux Plumbers? I plan to be there in a few weeks. And something tells me dwmw2 will be there. Brian
Brian, On 18.10.2016 20:46, Brian Norris wrote: >>> I totally agree with you so if Marek and you volunteer as well, your help >>> will be precious! >> >> Well, my SPI-NOR fu is not strong. And UBI/UBIFS keeps me busy. >> But if Brian likes the idea of having a MTD maintainer team I'll offer my help. > > I think a MTD maintainer team would be good to try, and I think it might > help to resolve my above complaint; a maintainer team could help to make > sure that everything can be coordinated in one tree + pull request, > without adding too many extra points of failure (e.g., so we don't have > awesome SPI NOR and NAND trees get bogged down by a slow MTD pull). > > Random thoughts: > > Does it make sense to still use infradead.org? We'd need to add a few > users there. What else do you have in mind? kernel.org? As long all users with commit access are member of the kernel.org web of trust any host should be fine. > Trust? I have met most of you in person, but not all, and I don't have > signed keys from all of you. I don't know what the best way to get a > group-writeable repo with credentials for all of you that we can trust. > (FWIW, neither Artem nor David met me, but they saw it fit to grant me > infradead.org access ;) ) I'd go with the kernel.org web of trust. > Coordination: how do we avoid stepping on each other's toes? We'd have > to definitely 100% kill 'git push -f' and 'git rebase'. Also, would > patchwork help or hurt us here? I think Boris and I have been sort of > using it, but it's still got a pretty good backlog (partly real -- > i.e., the cause for this thread; and partly artificial, due to > accounting). patchwork should be a good start. We could also try the tip scripts used by the x86 maintainer team. https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/tree/.tip?h=tip > What to do about mtd-utils.git? That's been languishing a bit, and it > has no release schedule. Maybe we want a plan for that too. I'd volunteer to nurse it together with David Oberhollenzer. In fact, David is currently preparing a v2 pre-release of mtd-utils. https://github.com/sigma-star/mtd-utils/commits/wip_v2-rc1 We reworked a lot of code and added new tools. Thanks, //richard
On Tue, 18 Oct 2016 11:46:51 -0700 Brian Norris <computersforpeace@gmail.com> wrote: > + others > > On Tue, Oct 18, 2016 at 06:15:23PM +0200, Richard Weinberger wrote: > > On 18.10.2016 17:55, Cyrille Pitchen wrote: > > > Le 18/10/2016 à 17:30, Richard Weinberger a écrit : > > >> On Tue, Oct 18, 2016 at 5:17 PM, Marek Vasut <marex@denx.de> wrote: > > >>> On 10/18/2016 04:58 PM, Cyrille Pitchen wrote: > > >>>> I would like to volunteer as a maintainer for the SPI NOR part of the MTD > > >>>> subsystem. > > Awesome! > > > >>>> Over the last months, a significant number of SPI NOR related patches have > > >>>> been submitted, some of them have been reviewed, but very few have finally > > >>>> been merged. Hence, the number of pending SPI NOR related patches continues > > >>>> to increase over the time. > > Agreed, and sorry. But I guess the delays had the side effect of forcing > peoples hands, instead of delaying the inevitable. > > > >>>> Through my work on SPI NOR memories from many manufacturers over the last > > >>>> two years, I've gained a solid understanding of this technology. > > >>>> I've already helped by reviewing patches from other contributors on the > > >>>> mailing list, and would like to help getting those patches integrated by > > >>>> volunteering as a maintainer for this specific area. > > Agreed. > > > >>>> Boris Brezillon has already stepped up as a maintainer for the NAND > > >>>> sub-subsystem in MTD, and the SPI NOR sub-subsystem could be handled in > > >>>> the same way: I would be reviewing patches touching this area, collecting > > >>>> them and sending pull requests to Brian Norris. > > >> > > >> I'd suggest you send pull requests directly to Linus. > > >> Same for NAND. > > I could go with either method I suppose, but I don't personally like the > idea of splitting out the various bits of MTD into *completely* > independent lines of development. As long as someone (not necessarily > me) can manage pulling the sub-subsystems together, I think it would > make sense to have 1 PR for Linus for non-UBI/FS MTD changes. > > > >>>> Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com> > > >>> > > >>> Let me know if you need co-maintainer. > > >> > > >> +1 > > +1, I think I've not-so-subtly suggested this to Marek previously. Okay, that's all great news! You can add my ack after adding Marek as a co-maintainer. > > > >> While we are here, what about forming a MTD maintainer team? > > >> This concept works very well for other subsystems. > > >> > > > > > > I totally agree with you so if Marek and you volunteer as well, your help > > > will be precious! > > > > Well, my SPI-NOR fu is not strong. And UBI/UBIFS keeps me busy. > > But if Brian likes the idea of having a MTD maintainer team I'll offer my help. > > I think a MTD maintainer team would be good to try, and I think it might > help to resolve my above complaint; a maintainer team could help to make > sure that everything can be coordinated in one tree + pull request, > without adding too many extra points of failure (e.g., so we don't have > awesome SPI NOR and NAND trees get bogged down by a slow MTD pull). > > Random thoughts: > > Does it make sense to still use infradead.org? We'd need to add a few > users there. > > Trust? I have met most of you in person, but not all, and I don't have > signed keys from all of you. I don't know what the best way to get a > group-writeable repo with credentials for all of you that we can trust. > (FWIW, neither Artem nor David met me, but they saw it fit to grant me > infradead.org access ;) ) > > Coordination: how do we avoid stepping on each other's toes? We'd have > to definitely 100% kill 'git push -f' and 'git rebase'. Also, would > patchwork help or hurt us here? I think Boris and I have been sort of > using it, but it's still got a pretty good backlog (partly real -- > i.e., the cause for this thread; and partly artificial, due to > accounting). I really think we should keep separate trees for the spi-nor and nand sub-subsystems, and then do PRs. The question is, how do we agree that a PR should be pulled in the MTD tree. I guess we could have a simple rule like, if it's been reviewed by at least X person (I guess 2 is acceptable), then we can merge it. > > What to do about mtd-utils.git? That's been languishing a bit, and it > has no release schedule. Maybe we want a plan for that too. Richard and David had some plans for the mtd-utils repo, and I think they already have the permissions to push things to this repo, so the best solution is probably to officially promote them maintainers of mtd-utils. > > BTW, will anybody be at Linux Plumbers? I plan to be there in a few > weeks. And something tells me dwmw2 will be there. Unfortunately I won't attend plumbers :-(.
On 10/18/2016 08:46 PM, Brian Norris wrote: [...] >>>>>> Boris Brezillon has already stepped up as a maintainer for the NAND >>>>>> sub-subsystem in MTD, and the SPI NOR sub-subsystem could be handled in >>>>>> the same way: I would be reviewing patches touching this area, collecting >>>>>> them and sending pull requests to Brian Norris. >>>> >>>> I'd suggest you send pull requests directly to Linus. >>>> Same for NAND. > > I could go with either method I suppose, but I don't personally like the > idea of splitting out the various bits of MTD into *completely* > independent lines of development. As long as someone (not necessarily > me) can manage pulling the sub-subsystems together, I think it would > make sense to have 1 PR for Linus for non-UBI/FS MTD changes. Yes please, agreed. This looks far more systematic and it's what other subsystems do. [...] > Random thoughts: [...] > Coordination: how do we avoid stepping on each other's toes? We'd have > to definitely 100% kill 'git push -f' and 'git rebase'. Also, would > patchwork help or hurt us here? Patchwork is nice, it helps keeping track of the patch status real well. But there is always the problem of keeping the patchwork up-to-date when the status of patch changes, esp. if one is offline (or maybe I didn't look hard enough). > I think Boris and I have been sort of > using it, but it's still got a pretty good backlog (partly real -- > i.e., the cause for this thread; and partly artificial, due to > accounting). > > What to do about mtd-utils.git? That's been languishing a bit, and it > has no release schedule. Maybe we want a plan for that too. > > BTW, will anybody be at Linux Plumbers? I plan to be there in a few > weeks. And something tells me dwmw2 will be there. > > Brian >
On Tue, 18 Oct 2016 21:31:06 +0200 Marek Vasut <marex@denx.de> wrote: > On 10/18/2016 08:46 PM, Brian Norris wrote: > > [...] > > >>>>>> Boris Brezillon has already stepped up as a maintainer for the NAND > >>>>>> sub-subsystem in MTD, and the SPI NOR sub-subsystem could be handled in > >>>>>> the same way: I would be reviewing patches touching this area, collecting > >>>>>> them and sending pull requests to Brian Norris. > >>>> > >>>> I'd suggest you send pull requests directly to Linus. > >>>> Same for NAND. > > > > I could go with either method I suppose, but I don't personally like the > > idea of splitting out the various bits of MTD into *completely* > > independent lines of development. As long as someone (not necessarily > > me) can manage pulling the sub-subsystems together, I think it would > > make sense to have 1 PR for Linus for non-UBI/FS MTD changes. > > Yes please, agreed. This looks far more systematic and it's what other > subsystems do. > > [...] > > > Random thoughts: > > [...] > > > Coordination: how do we avoid stepping on each other's toes? We'd have > > to definitely 100% kill 'git push -f' and 'git rebase'. Also, would > > patchwork help or hurt us here? > > Patchwork is nice, it helps keeping track of the patch status real well. > But there is always the problem of keeping the patchwork up-to-date when > the status of patch changes, esp. if one is offline (or maybe I didn't > look hard enough). I use git notes + a pre-push hook to help mark a patch as 'Accepted' in patchwork, but still, it does not automate moving patches to the 'Superseeded' state (which IMO should be directly handled in patchwork) and those who are rejected. This is why the backlog tend to grow until I decide to do some cleanup. We also have all those patches which are over 1 year old, but that we keep just in case someone wants to revive them. Anyway, I think patchwork is very useful if it's well maintained, so maybe we should cleanup things after each release. > > > I think Boris and I have been sort of > > using it, but it's still got a pretty good backlog (partly real -- > > i.e., the cause for this thread; and partly artificial, due to > > accounting). > > > > What to do about mtd-utils.git? That's been languishing a bit, and it > > has no release schedule. Maybe we want a plan for that too. > > > > BTW, will anybody be at Linux Plumbers? I plan to be there in a few > > weeks. And something tells me dwmw2 will be there. > > > > Brian > > > >
On 10/18/2016 09:41 PM, Boris Brezillon wrote: [...] >> Patchwork is nice, it helps keeping track of the patch status real well. >> But there is always the problem of keeping the patchwork up-to-date when >> the status of patch changes, esp. if one is offline (or maybe I didn't >> look hard enough). > > I use git notes + a pre-push hook to help mark a patch as 'Accepted' in > patchwork, but still, it does not automate moving patches to the > 'Superseeded' state (which IMO should be directly handled in patchwork) > and those who are rejected. This is why the backlog tend to grow until > I decide to do some cleanup. > > We also have all those patches which are over 1 year old, but that we > keep just in case someone wants to revive them. > > Anyway, I think patchwork is very useful if it's well maintained, so > maybe we should cleanup things after each release. You've very much nailed it. Those are all my complaints about patchwork and problems we had in U-Boot. Cleaning it up took a while. One just has to keep an eye on patchwork so it doesn't get out of control, otherwise the mountain of patches you have no clue about anymore becomes the source of utter frustration. >>> I think Boris and I have been sort of >>> using it, but it's still got a pretty good backlog (partly real -- >>> i.e., the cause for this thread; and partly artificial, due to >>> accounting). >>> >>> What to do about mtd-utils.git? That's been languishing a bit, and it >>> has no release schedule. Maybe we want a plan for that too. >>> >>> BTW, will anybody be at Linux Plumbers? I plan to be there in a few >>> weeks. And something tells me dwmw2 will be there. >>> >>> Brian >>> >> >> >
Hi all, On Tue, Oct 18, 2016 at 6:15 PM, Richard Weinberger <richard@nod.at> wrote: >> I totally agree with you so if Marek and you volunteer as well, your help >> will be precious! I had talked to Richard about helping out during ELCE, but tbh I think Marek is the better choice ;-) He has way more experience in that area. Happy to see things moving in the right direction! If you feel you need more help one day, don't hesitate to ping me. Moritz
On 18.10.2016 21:59, Moritz Fischer wrote: > Hi all, > > On Tue, Oct 18, 2016 at 6:15 PM, Richard Weinberger <richard@nod.at> wrote: > >>> I totally agree with you so if Marek and you volunteer as well, your help >>> will be precious! > > I had talked to Richard about helping out during ELCE, but tbh I think > Marek is the better choice ;-) > He has way more experience in that area. > Happy to see things moving in the right direction! If you feel you > need more help one day, > don't hesitate to ping me. This does not mean that you can't help. Please have a look at incoming patches and review them. Thanks, //richard
On 10/18/2016 09:15 PM, Boris Brezillon wrote: > On Tue, 18 Oct 2016 11:46:51 -0700 > Brian Norris <computersforpeace@gmail.com> wrote: > >> + others >> >> On Tue, Oct 18, 2016 at 06:15:23PM +0200, Richard Weinberger wrote: >>> On 18.10.2016 17:55, Cyrille Pitchen wrote: >>>> Le 18/10/2016 à 17:30, Richard Weinberger a écrit : >>>>> On Tue, Oct 18, 2016 at 5:17 PM, Marek Vasut <marex@denx.de> wrote: >>>>>> On 10/18/2016 04:58 PM, Cyrille Pitchen wrote: >>>>>>> I would like to volunteer as a maintainer for the SPI NOR part of the MTD >>>>>>> subsystem. >> >> Awesome! >> >>>>>>> Over the last months, a significant number of SPI NOR related patches have >>>>>>> been submitted, some of them have been reviewed, but very few have finally >>>>>>> been merged. Hence, the number of pending SPI NOR related patches continues >>>>>>> to increase over the time. >> >> Agreed, and sorry. But I guess the delays had the side effect of forcing >> peoples hands, instead of delaying the inevitable. >> >>>>>>> Through my work on SPI NOR memories from many manufacturers over the last >>>>>>> two years, I've gained a solid understanding of this technology. >>>>>>> I've already helped by reviewing patches from other contributors on the >>>>>>> mailing list, and would like to help getting those patches integrated by >>>>>>> volunteering as a maintainer for this specific area. >> >> Agreed. >> >>>>>>> Boris Brezillon has already stepped up as a maintainer for the NAND >>>>>>> sub-subsystem in MTD, and the SPI NOR sub-subsystem could be handled in >>>>>>> the same way: I would be reviewing patches touching this area, collecting >>>>>>> them and sending pull requests to Brian Norris. >>>>> >>>>> I'd suggest you send pull requests directly to Linus. >>>>> Same for NAND. >> >> I could go with either method I suppose, but I don't personally like the >> idea of splitting out the various bits of MTD into *completely* >> independent lines of development. As long as someone (not necessarily >> me) can manage pulling the sub-subsystems together, I think it would >> make sense to have 1 PR for Linus for non-UBI/FS MTD changes. >> >>>>>>> Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com> >>>>>> >>>>>> Let me know if you need co-maintainer. >>>>> >>>>> +1 >> >> +1, I think I've not-so-subtly suggested this to Marek previously. > > Okay, that's all great news! > You can add my ack after adding Marek as a co-maintainer. > >> >>>>> While we are here, what about forming a MTD maintainer team? >>>>> This concept works very well for other subsystems. >>>>> >>>> >>>> I totally agree with you so if Marek and you volunteer as well, your help >>>> will be precious! >>> >>> Well, my SPI-NOR fu is not strong. And UBI/UBIFS keeps me busy. >>> But if Brian likes the idea of having a MTD maintainer team I'll offer my help. >> >> I think a MTD maintainer team would be good to try, and I think it might >> help to resolve my above complaint; a maintainer team could help to make >> sure that everything can be coordinated in one tree + pull request, >> without adding too many extra points of failure (e.g., so we don't have >> awesome SPI NOR and NAND trees get bogged down by a slow MTD pull). >> >> Random thoughts: >> >> Does it make sense to still use infradead.org? We'd need to add a few >> users there. >> >> Trust? I have met most of you in person, but not all, and I don't have >> signed keys from all of you. I don't know what the best way to get a >> group-writeable repo with credentials for all of you that we can trust. >> (FWIW, neither Artem nor David met me, but they saw it fit to grant me >> infradead.org access ;) ) >> >> Coordination: how do we avoid stepping on each other's toes? We'd have >> to definitely 100% kill 'git push -f' and 'git rebase'. Also, would >> patchwork help or hurt us here? I think Boris and I have been sort of >> using it, but it's still got a pretty good backlog (partly real -- >> i.e., the cause for this thread; and partly artificial, due to >> accounting). > > I really think we should keep separate trees for the spi-nor and nand > sub-subsystems, and then do PRs. The question is, how do we agree that > a PR should be pulled in the MTD tree. > > I guess we could have a simple rule like, if it's been reviewed by at > least X person (I guess 2 is acceptable), then we can merge it. > >> >> What to do about mtd-utils.git? That's been languishing a bit, and it >> has no release schedule. Maybe we want a plan for that too. > > Richard and David had some plans for the mtd-utils repo, and I think > they already have the permissions to push things to this repo, so the > best solution is probably to officially promote them maintainers of > mtd-utils. I would volunteer to maintain it together with Richard. As has been previously mentioned, we did a major overhaul and merged lots of fixes locally. AFAIK Richard already has push permissions for the mtd-utils tree on infradead.org, so it should be just a matter of making it official? David
On 10/18/2016 11:10 PM, David Oberhollenzer wrote: > On 10/18/2016 09:15 PM, Boris Brezillon wrote: >> On Tue, 18 Oct 2016 11:46:51 -0700 >> Brian Norris <computersforpeace@gmail.com> wrote: >> >>> + others >>> >>> On Tue, Oct 18, 2016 at 06:15:23PM +0200, Richard Weinberger wrote: >>>> On 18.10.2016 17:55, Cyrille Pitchen wrote: >>>>> Le 18/10/2016 à 17:30, Richard Weinberger a écrit : >>>>>> On Tue, Oct 18, 2016 at 5:17 PM, Marek Vasut <marex@denx.de> wrote: >>>>>>> On 10/18/2016 04:58 PM, Cyrille Pitchen wrote: >>>>>>>> I would like to volunteer as a maintainer for the SPI NOR part of the MTD >>>>>>>> subsystem. >>> >>> Awesome! >>> >>>>>>>> Over the last months, a significant number of SPI NOR related patches have >>>>>>>> been submitted, some of them have been reviewed, but very few have finally >>>>>>>> been merged. Hence, the number of pending SPI NOR related patches continues >>>>>>>> to increase over the time. >>> >>> Agreed, and sorry. But I guess the delays had the side effect of forcing >>> peoples hands, instead of delaying the inevitable. >>> >>>>>>>> Through my work on SPI NOR memories from many manufacturers over the last >>>>>>>> two years, I've gained a solid understanding of this technology. >>>>>>>> I've already helped by reviewing patches from other contributors on the >>>>>>>> mailing list, and would like to help getting those patches integrated by >>>>>>>> volunteering as a maintainer for this specific area. >>> >>> Agreed. >>> >>>>>>>> Boris Brezillon has already stepped up as a maintainer for the NAND >>>>>>>> sub-subsystem in MTD, and the SPI NOR sub-subsystem could be handled in >>>>>>>> the same way: I would be reviewing patches touching this area, collecting >>>>>>>> them and sending pull requests to Brian Norris. >>>>>> >>>>>> I'd suggest you send pull requests directly to Linus. >>>>>> Same for NAND. >>> >>> I could go with either method I suppose, but I don't personally like the >>> idea of splitting out the various bits of MTD into *completely* >>> independent lines of development. As long as someone (not necessarily >>> me) can manage pulling the sub-subsystems together, I think it would >>> make sense to have 1 PR for Linus for non-UBI/FS MTD changes. >>> >>>>>>>> Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com> >>>>>>> >>>>>>> Let me know if you need co-maintainer. >>>>>> >>>>>> +1 >>> >>> +1, I think I've not-so-subtly suggested this to Marek previously. >> >> Okay, that's all great news! >> You can add my ack after adding Marek as a co-maintainer. >> >>> >>>>>> While we are here, what about forming a MTD maintainer team? >>>>>> This concept works very well for other subsystems. >>>>>> >>>>> >>>>> I totally agree with you so if Marek and you volunteer as well, your help >>>>> will be precious! >>>> >>>> Well, my SPI-NOR fu is not strong. And UBI/UBIFS keeps me busy. >>>> But if Brian likes the idea of having a MTD maintainer team I'll offer my help. >>> >>> I think a MTD maintainer team would be good to try, and I think it might >>> help to resolve my above complaint; a maintainer team could help to make >>> sure that everything can be coordinated in one tree + pull request, >>> without adding too many extra points of failure (e.g., so we don't have >>> awesome SPI NOR and NAND trees get bogged down by a slow MTD pull). >>> >>> Random thoughts: >>> >>> Does it make sense to still use infradead.org? We'd need to add a few >>> users there. >>> >>> Trust? I have met most of you in person, but not all, and I don't have >>> signed keys from all of you. I don't know what the best way to get a >>> group-writeable repo with credentials for all of you that we can trust. >>> (FWIW, neither Artem nor David met me, but they saw it fit to grant me >>> infradead.org access ;) ) >>> >>> Coordination: how do we avoid stepping on each other's toes? We'd have >>> to definitely 100% kill 'git push -f' and 'git rebase'. Also, would >>> patchwork help or hurt us here? I think Boris and I have been sort of >>> using it, but it's still got a pretty good backlog (partly real -- >>> i.e., the cause for this thread; and partly artificial, due to >>> accounting). >> >> I really think we should keep separate trees for the spi-nor and nand >> sub-subsystems, and then do PRs. The question is, how do we agree that >> a PR should be pulled in the MTD tree. >> >> I guess we could have a simple rule like, if it's been reviewed by at >> least X person (I guess 2 is acceptable), then we can merge it. >> >>> >>> What to do about mtd-utils.git? That's been languishing a bit, and it >>> has no release schedule. Maybe we want a plan for that too. >> >> Richard and David had some plans for the mtd-utils repo, and I think >> they already have the permissions to push things to this repo, so the >> best solution is probably to officially promote them maintainers of >> mtd-utils. > I would volunteer to maintain it together with Richard. > > As has been previously mentioned, we did a major overhaul and merged lots > of fixes locally. AFAIK Richard already has push permissions for the mtd-utils > tree on infradead.org, so it should be just a matter of making it official? > Yes please, I saw some of your patches via Richard and they were nice.
On Tue, 2016-10-18 at 11:46 -0700, Brian Norris wrote: > I could go with either method I suppose, but I don't personally like > the > idea of splitting out the various bits of MTD into *completely* > independent lines of development. As long as someone (not necessarily > me) can manage pulling the sub-subsystems together, I think it would > make sense to have 1 PR for Linus for non-UBI/FS MTD changes. I think this is a good point. MTD is pretty much a "don't care" subsystem for Linus, an I do not think he'll appreciate 2 or more micro MTD pull requests. It makes a lot more sense to consolidate all this under a single tree MTD tree and make a single pull request.
diff --git a/MAINTAINERS b/MAINTAINERS index 757f9c4b388d..73e9319b3f9f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -11390,6 +11390,16 @@ W: http://www.st.com/spear S: Maintained F: drivers/clk/spear/ +SPI NOR SUBSYSTEM +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/ +T: git git://github.com/spi-nor/linux.git +S: Maintained +F: drivers/mtd/spi-nor/ +F: include/linux/mtd/spi-nor.h + SPI SUBSYSTEM M: Mark Brown <broonie@kernel.org> L: linux-spi@vger.kernel.org
I would like to volunteer as a maintainer for the SPI NOR part of the MTD subsystem. Over the last months, a significant number of SPI NOR related patches have been submitted, some of them have been reviewed, but very few have finally been merged. Hence, the number of pending SPI NOR related patches continues to increase over the time. Through my work on SPI NOR memories from many manufacturers over the last two years, I've gained a solid understanding of this technology. I've already helped by reviewing patches from other contributors on the mailing list, and would like to help getting those patches integrated by volunteering as a maintainer for this specific area. Boris Brezillon has already stepped up as a maintainer for the NAND sub-subsystem in MTD, and the SPI NOR sub-subsystem could be handled in the same way: I would be reviewing patches touching this area, collecting them and sending pull requests to Brian Norris. Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com> --- MAINTAINERS | 10 ++++++++++ 1 file changed, 10 insertions(+)