[PATCH 1/1] MAINTAINERS: add a maintainer for the SPI NOR subsystem

[PATCH 1/1] MAINTAINERS: add a maintainer for the SPI NOR subsystem

[Cyrille Pitchen]

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(+)

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
-- 
2.7.4

Re: [PATCH 1/1] MAINTAINERS: add a maintainer for the SPI NOR subsystem

[Marek Vasut]

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
> 


-- 
Best regards,
Marek Vasut

Re: [PATCH 1/1] MAINTAINERS: add a maintainer for the SPI NOR subsystem

[Richard Weinberger]

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.

-- 
Thanks,
//richard

Re: [PATCH 1/1] MAINTAINERS: add a maintainer for the SPI NOR subsystem

[Cyrille Pitchen]

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!

Re: [PATCH 1/1] MAINTAINERS: add a maintainer for the SPI NOR subsystem

[Richard Weinberger]

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

Re: [PATCH 1/1] MAINTAINERS: add a maintainer for the SPI NOR subsystem

[Marek Vasut]

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.

-- 
Best regards,
Marek Vasut

Re: [PATCH 1/1] MAINTAINERS: add a maintainer for the SPI NOR subsystem

[Brian Norris]

+ 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

Re: [PATCH 1/1] MAINTAINERS: add a maintainer for the SPI NOR subsystem

[Richard Weinberger]

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

Re: [PATCH 1/1] MAINTAINERS: add a maintainer for the SPI NOR subsystem

[Boris Brezillon]

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 :-(.

Re: [PATCH 1/1] MAINTAINERS: add a maintainer for the SPI NOR subsystem

[David Oberhollenzer]

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

Re: [PATCH 1/1] MAINTAINERS: add a maintainer for the SPI NOR subsystem

[Marek Vasut]

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.

-- 
Best regards,
Marek Vasut

Re: [PATCH 1/1] MAINTAINERS: add a maintainer for the SPI NOR subsystem

[Marek Vasut]

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
> 


-- 
Best regards,
Marek Vasut

Re: [PATCH 1/1] MAINTAINERS: add a maintainer for the SPI NOR subsystem

[Boris Brezillon]

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
> >   
> 
> 

Re: [PATCH 1/1] MAINTAINERS: add a maintainer for the SPI NOR subsystem

[Marek Vasut]

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
>>>   
>>
>>
> 


-- 
Best regards,
Marek Vasut

Re: [PATCH 1/1] MAINTAINERS: add a maintainer for the SPI NOR subsystem

[Artem Bityutskiy]

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.

Re: [PATCH 1/1] MAINTAINERS: add a maintainer for the SPI NOR subsystem

[Moritz Fischer]

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

Re: [PATCH 1/1] MAINTAINERS: add a maintainer for the SPI NOR subsystem

[Richard Weinberger]

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