No pull for mtd?

No pull for mtd?

[Ezequiel Garcia]

Hello,

As the merge window close is just around the corner,
I wonder if there will be a MTD git pull for 3.11.

In particular, I'd like to see the pxa-nand patches, if at all possible.

Thanks a lot!
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

Re: No pull for mtd?

[Brian Norris]

On Fri, Jul 12, 2013 at 5:47 AM, Ezequiel Garcia
<ezequiel.garcia@free-electrons.com> wrote:
> As the merge window close is just around the corner,
> I wonder if there will be a MTD git pull for 3.11.

Time has given the (disappointing) answer: apparently no.

Artem/David,

Any reason for this miss? Can we get a guarantee a pull for 3.12 at least?

Brian

Re: No pull for mtd?

[Huang Shijie]

于 2013年07月16日 10:58, Brian Norris 写道:
> On Fri, Jul 12, 2013 at 5:47 AM, Ezequiel Garcia
> <ezequiel.garcia@free-electrons.com>  wrote:
>> As the merge window close is just around the corner,
>> I wonder if there will be a MTD git pull for 3.11.
> Time has given the (disappointing) answer: apparently no.
>
> Artem/David,
>
> Any reason for this miss? Can we get a guarantee a pull for 3.12 at least?
Add more people to this thread.

there are many patches pending in the maillist.

So If Artem/David are too busy to maintain this MTD code, i volunteer to 
maintain it.


thanks
Huang Shijie

Re: No pull for mtd?

[Brian Norris]

On Wed, Jul 17, 2013 at 6:20 AM, Artem Bityutskiy <dedekind1@gmail.com> wrote:
> As of pull requests, dwmw2 sends them, not me. He
> didn't send it this time though.

Hence my questions (now directed entirely at David): "Any reason for
this miss? Can we get a guarantee a pull for 3.12 at least?"

And an added question: if not, shall we move for a change/addition in
maintainership? This is the second merge window missed in the last
year (we missed v3.6-rc1).

Brian

Re: No pull for mtd?

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 975 bytes --]

On Wed, 2013-07-17 at 16:02 -0700, Brian Norris wrote:
> On Wed, Jul 17, 2013 at 6:20 AM, Artem Bityutskiy <dedekind1@gmail.com> wrote:
> > As of pull requests, dwmw2 sends them, not me. He
> > didn't send it this time though.
> 
> Hence my questions (now directed entirely at David): "Any reason for
> this miss? Can we get a guarantee a pull for 3.12 at least?"
> 
> And an added question: if not, shall we move for a change/addition in
> maintainership? This is the second merge window missed in the last
> year (we missed v3.6-rc1).

Apologies. Artem usually does a very good job of lining things up for
me, and I then apply a little more 'editorial control' before sending
the result on to Linus.

This time it fell through the cracks because Artem was away and didn't
hassle me like he usually does, and I've been contending with the
distraction of a 12-week-old baby.

I will definitely make sure we get a merge lined up for 3.12.

-- 
dwmw2


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5745 bytes --]

Re: No pull for mtd?

[Brian Norris]

On Wed, Jul 17, 2013 at 4:13 PM, David Woodhouse <dwmw2@infradead.org> wrote:
> On Wed, 2013-07-17 at 16:02 -0700, Brian Norris wrote:
>> On Wed, Jul 17, 2013 at 6:20 AM, Artem Bityutskiy <dedekind1@gmail.com> wrote:
>> > As of pull requests, dwmw2 sends them, not me. He
>> > didn't send it this time though.
>>
>> Hence my questions (now directed entirely at David): "Any reason for
>> this miss? Can we get a guarantee a pull for 3.12 at least?"
>>
>> And an added question: if not, shall we move for a change/addition in
>> maintainership? This is the second merge window missed in the last
>> year (we missed v3.6-rc1).
>
> Apologies. Artem usually does a very good job of lining things up for
> me, and I then apply a little more 'editorial control' before sending
> the result on to Linus.
>
> This time it fell through the cracks because Artem was away and didn't
> hassle me like he usually does, and I've been contending with the
> distraction of a 12-week-old baby.

Is there any hassling the rest of us can do in the future to avoid
this situation? Ezequiel gave a timely reminder via email (2 or 3 days
left in the merge window). We can shout louder and earlier, but it's
hard to tell if we're shouting into an empty forest sometimes.

Brian

Re: No pull for mtd?

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 3060 bytes --]

On Wed, 2013-07-17 at 16:26 -0700, Brian Norris wrote:
> Is there any hassling the rest of us can do in the future to avoid
> this situation? 

Certainly can't hurt :)

> Ezequiel gave a timely reminder via email (2 or 3 days
> left in the merge window). We can shout louder and earlier, but it's
> hard to tell if we're shouting into an empty forest sometimes.

Earlier is better. If I haven't got a tree lined up in good time
*before* the merge window opens, Linus isn't going to want to know.
So if the merge window is already open and I'm slacking and/or changing
nappies, that's a bit late already.

Occasionally when I've failed to get things together in time for the
merge window, I have handled that by just looking at Artem's "l2-mtd"
tree and submitting what's in there as-is, without making any changes.
Or submitting a strict subset of it, up to the *important* part but
leaving out some of the more dubious later commits which I want to
change or reject.

Normally though, I use Artem's l2-mtd tree a bit like patchwork. He
hoovers up most things from the list and even does some preliminary
fixes on them — so it's *much* more convenient for me than raw patchwork
would be. And it's close *enough* to what I'm actually going to accept,
that it's reasonable for it to be in linux-next as it is.

Artem has historically expressed a reticence to have direct commit
access to the main MTD tree (I think he does actually *have* it, in
fact, but he's never used it). I think he prefers that I continue to
have the final say after he does the first pass, and I think that model
generally works out OK as a division of labour.

So... other than putting a few more hours in my day (and ringfencing
them so they don't get used up by all the *other* things I need a few
more hours each day for, like sleeping as I should be doing right now),
what can we do?

Brian, Huang, thanks for volunteering to help. It's much appreciated.

I think the way forward, if Artem is willing, might be the following:

Turn the l2-mtd tree into a group-access repository, so all of us can
push to it (or rebase/reorder/etc). Try to keep it (as Artem already
does to a certain extent) in order of "good" and then "staging" patches.

It's that sorting that's important; I should be able to just pull the
'good' ones directly into the main tree as a stable commit which *will*
to go Linus. And then after a while, once we're all happy that I never
actually end up rejecting or even tweaking patches in the "good" pile,
we'll just start using the main linux-mtd.git tree as the "good" pile
and you can push there directly. I'll try to be more explicit about what
I change and why, in cases where I would previously have silently fixed
things up.

I'll probably still keep doing a final pass on it for a while even after
that, and constructing the pull request. But I'm not averse to letting
others do that too, once we've reached the point where I'm sure it'd be
as I want it.

How does that sound?

-- 
dwmw2


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5745 bytes --]

Re: No pull for mtd?

[Brian Norris]

On Wed, Jul 17, 2013 at 6:03 PM, David Woodhouse <dwmw2@infradead.org> wrote:
> On Wed, 2013-07-17 at 16:26 -0700, Brian Norris wrote:
>> Is there any hassling the rest of us can do in the future to avoid
>> this situation?
>
> Certainly can't hurt :)

I was kinda wondering about specifics :) Like more email? More capital
letters in our emails? Track down your phone number and call you in
the middle of the night?

>> Ezequiel gave a timely reminder via email (2 or 3 days
>> left in the merge window). We can shout louder and earlier, but it's
>> hard to tell if we're shouting into an empty forest sometimes.
>
> Earlier is better. If I haven't got a tree lined up in good time
> *before* the merge window opens, Linus isn't going to want to know.
> So if the merge window is already open and I'm slacking and/or changing
> nappies, that's a bit late already.

Yeah, I realize now that 3 days is a bit late. And I didn't really
notice our missing the merge window myself until it was nearly too
late :)

> Occasionally when I've failed to get things together in time for the
> merge window, I have handled that by just looking at Artem's "l2-mtd"
> tree and submitting what's in there as-is, without making any changes.
> Or submitting a strict subset of it, up to the *important* part but
> leaving out some of the more dubious later commits which I want to
> change or reject.
>
> Normally though, I use Artem's l2-mtd tree a bit like patchwork. He
> hoovers up most things from the list and even does some preliminary
> fixes on them — so it's *much* more convenient for me than raw patchwork
> would be. And it's close *enough* to what I'm actually going to accept,
> that it's reasonable for it to be in linux-next as it is.

I guess I didn't fully grasp the relation between you and Artem. It
seemed to me like Artem's tree was practically the pull request tree,
that his status as "not the maintainer" simply gave him the luxury to
rebase more freely, and that your sign-off (or sometimes pull request
w/o adding sign-offs) was mostly just a rubber stamp. But I was
slightly off, I suppose. Anyway, I do appreciate the editorial
control, whether it's Artem or you, and I would not be hasty to
discard that.

> Artem has historically expressed a reticence to have direct commit
> access to the main MTD tree (I think he does actually *have* it, in
> fact, but he's never used it). I think he prefers that I continue to
> have the final say after he does the first pass, and I think that model
> generally works out OK as a division of labour.
>
> So... other than putting a few more hours in my day (and ringfencing
> them so they don't get used up by all the *other* things I need a few
> more hours each day for, like sleeping as I should be doing right now),
> what can we do?

Lengthen your day? Maybe a time machine? Hire a body double to go to
your "real" job?

> Brian, Huang, thanks for volunteering to help. It's much appreciated.
>
> I think the way forward, if Artem is willing, might be the following:
>
> Turn the l2-mtd tree into a group-access repository, so all of us can
> push to it (or rebase/reorder/etc). Try to keep it (as Artem already
> does to a certain extent) in order of "good" and then "staging" patches.

I did not realize that there was an order other than chronological in
which Artem kept l2-mtd. This might be a little harder to manage if
the distinction between "good" and "staging" are unclear, and there
are up to 3 people rebasing and pushing. We'll definitely need Artem's
agreement for anything of this sort.

> It's that sorting that's important; I should be able to just pull the
> 'good' ones directly into the main tree as a stable commit which *will*
> to go Linus.

My suggestion, to resolve some of the potential conflicts of too many
writing to the same branch and to make the sorting clear: perhaps a
separate branch that will hold the "good" stuff (named 'for-3.12' for
example) with minimal rebasing. Then l2-mtd's 'master' will rebase on
top of that to include "staging" fixes that are more likely to be
fixed-up, dropped, or delayed.

> And then after a while, once we're all happy that I never
> actually end up rejecting or even tweaking patches in the "good" pile,
> we'll just start using the main linux-mtd.git tree as the "good" pile
> and you can push there directly. I'll try to be more explicit about what
> I change and why, in cases where I would previously have silently fixed
> things up.
>
> I'll probably still keep doing a final pass on it for a while even after
> that, and constructing the pull request. But I'm not averse to letting
> others do that too, once we've reached the point where I'm sure it'd be
> as I want it.
>
> How does that sound?

I think that mostly sounds OK. I can't speak for everyone, but it
seems that for some of us, the process just needs to be able to adapt
to changes in job situations (where at least you and Artem aren't even
employed in MTD-related work anymore), vacations, babies, absences, or
any of the other reasons that MTD participation ebbs and flows. So
bringing others into the process should help.

I guess we'll see what Artem thinks when he's back from vacation and
what Huang thinks. But I'm game to try this out.

Thanks for sacrificing sleep for the response.

Brian

Re: No pull for mtd?

[Huang Shijie]

On Thu, Jul 18, 2013 at 10:33:09PM -0700, Brian Norris wrote:
> On Wed, Jul 17, 2013 at 6:03 PM, David Woodhouse <dwmw2@infradead.org> wrote:
> > On Wed, 2013-07-17 at 16:26 -0700, Brian Norris wrote:
> >> Is there any hassling the rest of us can do in the future to avoid
> >> this situation?
> >
> > Certainly can't hurt :)
> 
> I was kinda wondering about specifics :) Like more email? More capital
> letters in our emails? Track down your phone number and call you in
> the middle of the night?
> 
> >> Ezequiel gave a timely reminder via email (2 or 3 days
> >> left in the merge window). We can shout louder and earlier, but it's
> >> hard to tell if we're shouting into an empty forest sometimes.
> >
> > Earlier is better. If I haven't got a tree lined up in good time
> > *before* the merge window opens, Linus isn't going to want to know.
> > So if the merge window is already open and I'm slacking and/or changing
> > nappies, that's a bit late already.
hi David:

We can hassle you when the merge-window just opens.
I think two weeks is enough for you.

> 
> Yeah, I realize now that 3 days is a bit late. And I didn't really
> notice our missing the merge window myself until it was nearly too
> late :)
> 
> > Occasionally when I've failed to get things together in time for the
> > merge window, I have handled that by just looking at Artem's "l2-mtd"
> > tree and submitting what's in there as-is, without making any changes.
> > Or submitting a strict subset of it, up to the *important* part but
> > leaving out some of the more dubious later commits which I want to
> > change or reject.
> >
> > Normally though, I use Artem's l2-mtd tree a bit like patchwork. He
> > hoovers up most things from the list and even does some preliminary
> > fixes on them — so it's *much* more convenient for me than raw patchwork
> > would be. And it's close *enough* to what I'm actually going to accept,
> > that it's reasonable for it to be in linux-next as it is.
> 
> I guess I didn't fully grasp the relation between you and Artem. It
> seemed to me like Artem's tree was practically the pull request tree,
> that his status as "not the maintainer" simply gave him the luxury to
> rebase more freely, and that your sign-off (or sometimes pull request
> w/o adding sign-offs) was mostly just a rubber stamp. But I was
> slightly off, I suppose. Anyway, I do appreciate the editorial
> control, whether it's Artem or you, and I would not be hasty to
> discard that.
> 
> > Artem has historically expressed a reticence to have direct commit
> > access to the main MTD tree (I think he does actually *have* it, in
> > fact, but he's never used it). I think he prefers that I continue to
> > have the final say after he does the first pass, and I think that model
> > generally works out OK as a division of labour.
> >
> > So... other than putting a few more hours in my day (and ringfencing
> > them so they don't get used up by all the *other* things I need a few
> > more hours each day for, like sleeping as I should be doing right now),
> > what can we do?
> 
> Lengthen your day? Maybe a time machine? Hire a body double to go to
> your "real" job?
> 
> > Brian, Huang, thanks for volunteering to help. It's much appreciated.
> >
> > I think the way forward, if Artem is willing, might be the following:
> >
> > Turn the l2-mtd tree into a group-access repository, so all of us can
> > push to it (or rebase/reorder/etc). Try to keep it (as Artem already
> > does to a certain extent) in order of "good" and then "staging" patches.
> 
> I did not realize that there was an order other than chronological in
> which Artem kept l2-mtd. This might be a little harder to manage if
> the distinction between "good" and "staging" are unclear, and there
> are up to 3 people rebasing and pushing. We'll definitely need Artem's
> agreement for anything of this sort.
> 
> > It's that sorting that's important; I should be able to just pull the
> > 'good' ones directly into the main tree as a stable commit which *will*
> > to go Linus.
> 
> My suggestion, to resolve some of the potential conflicts of too many
> writing to the same branch and to make the sorting clear: perhaps a
> separate branch that will hold the "good" stuff (named 'for-3.12' for
> example) with minimal rebasing. Then l2-mtd's 'master' will rebase on
> top of that to include "staging" fixes that are more likely to be
> fixed-up, dropped, or delayed.
> 
> > And then after a while, once we're all happy that I never
> > actually end up rejecting or even tweaking patches in the "good" pile,
> > we'll just start using the main linux-mtd.git tree as the "good" pile
> > and you can push there directly. I'll try to be more explicit about what
> > I change and why, in cases where I would previously have silently fixed
> > things up.
> >
> > I'll probably still keep doing a final pass on it for a while even after
> > that, and constructing the pull request. But I'm not averse to letting
> > others do that too, once we've reached the point where I'm sure it'd be
> > as I want it.
> >
> > How does that sound?
> 
> I think that mostly sounds OK. I can't speak for everyone, but it
> seems that for some of us, the process just needs to be able to adapt
> to changes in job situations (where at least you and Artem aren't even
> employed in MTD-related work anymore), vacations, babies, absences, or
> any of the other reasons that MTD participation ebbs and flows. So
> bringing others into the process should help.
yes.

If more people can ack and merge the patches, we can speed up the mtd.

I really envy the other maillist, you can get response in several days.
but if i send patches to mtd, i maybe should wait for a month or more.

> 
> I guess we'll see what Artem thinks when he's back from vacation and
Waiting for Artem's solution too. He becomes much busy this year, and
can not review the patches as he did last year.

thanks
Huang Shijie

Re: No pull for mtd?

[Artem Bityutskiy]

On Thu, 2013-07-18 at 02:03 +0100, David Woodhouse wrote:
> Artem has historically expressed a reticence to have direct commit
> access to the main MTD tree (I think he does actually *have* it, in
> fact, but he's never used it). I think he prefers that I continue to
> have the final say after he does the first pass, and I think that model
> generally works out OK as a division of labour.

Whenever you know that you are going to miss the merge window, let me
know, and I will prepare a pull request.

This merge window I was not able to process all incoming patches, but I
did process a big part of them, so I could send a pull request to Linus
with your blessing.

But yes, knowing you for many years I know you are technically
excellent, so I would like you to have a final word, and this is why I
resisted to touch your tree directly.

However, I am fine to temporarily play your role whenever you know you
are going to be late.

> Brian, Huang, thanks for volunteering to help. It's much appreciated.

Indeed.

> Turn the l2-mtd tree into a group-access repository, so all of us can
> push to it (or rebase/reorder/etc). Try to keep it (as Artem already
> does to a certain extent) in order of "good" and then "staging" patches.

Fine with me. Huang, Brian, how do you see your role? What can you do
and how will it help fixing the problem? Do you want to take care about
a small part of MTD (e.g., only gpmi driver) or the MTD overall?

Depending on what you are willing to do, we can figure how we can work
together.

-- 
Best Regards,
Artem Bityutskiy

Re: No pull for mtd?

[Artem Bityutskiy]

On Thu, 2013-07-18 at 22:33 -0700, Brian Norris wrote:
> > Normally though, I use Artem's l2-mtd tree a bit like patchwork. He
> > hoovers up most things from the list and even does some preliminary
> > fixes on them — so it's *much* more convenient for me than raw
> patchwork
> > would be. And it's close *enough* to what I'm actually going to
> accept,
> > that it's reasonable for it to be in linux-next as it is.
> 
> I guess I didn't fully grasp the relation between you and Artem. It
> seemed to me like Artem's tree was practically the pull request tree,
> that his status as "not the maintainer" simply gave him the luxury to
> rebase more freely, and that your sign-off (or sometimes pull request
> w/o adding sign-offs) was mostly just a rubber stamp.

Well, something like this. Depending on the load, David either sends my
tree to Linus almost intact, or goes through it patch-by-patch and does
real review: amends some, rejects some, etc.

-- 
Best Regards,
Artem Bityutskiy

Re: No pull for mtd?

[Artem Bityutskiy]

On Sat, 2013-07-20 at 08:22 -0400, Huang Shijie wrote:
> > I think that mostly sounds OK. I can't speak for everyone, but it
> > seems that for some of us, the process just needs to be able to
> adapt
> > to changes in job situations (where at least you and Artem aren't
> even
> > employed in MTD-related work anymore), vacations, babies, absences,
> or
> > any of the other reasons that MTD participation ebbs and flows. So
> > bringing others into the process should help.
> yes.
> 
> If more people can ack and merge the patches, we can speed up the mtd.

Sure. Go ahead and review things which are outside of your gpmi driver.
Ack them, nack them, review them, etc. This will be a real help.
> 
> I really envy the other maillist, you can get response in several
> days.

Well, yes. MTD is a small and (IMHO) a veeery slowly dying subsystem.
People mostly care about their own little things. Few people are
interested in improving it in general. Such is life.

Brian was one of those who did great job in MTD overall, especially in
the NAND framework. He reviewed others patches. But even Brian got
silent lately.

Shmulik comes to mind - he reviewed things all over MTD.

You mostly contribute to your own driver. And I think there were times
when I had to ask you to do an infrastructure rework instead of working
around MTD infrastructure problems with in-driver hacks. No one is
perfect :-)

So there is simply not enough people, thus the slowness.

> > 
> > I guess we'll see what Artem thinks when he's back from vacation and
> Waiting for Artem's solution too. He becomes much busy this year, and
> can not review the patches as he did last year.

Well, just go ahead and help.

This is also how the l2 tree appeared. I noticed that dwmw2 is becoming
slow, and I just went ahead and created this tree without asking him,
and told him that now he does not have to go through the mailing list -
all the "sane" (from my POW) patches are in the l2 tree.

But please, do not create another tree now :-) Either start reviewing
others' patches, or declare ownership for some part of MTD and let's
create a corresponding branch in my tree for you. E.g., gpmi.

In case of Brian, I'd fully trust the entire NAND subsystem to him, he
demonstrated that he is capable of taking care of it.

-- 
Best Regards,
Artem Bityutskiy

Re: No pull for mtd?

[Artem Bityutskiy]

On Tue, 2013-07-30 at 21:53 -0400, Huang Shijie wrote:
> > Well, just go ahead and help.
> > 
> > This is also how the l2 tree appeared. I noticed that dwmw2 is becoming
> > slow, and I just went ahead and created this tree without asking him,
> > and told him that now he does not have to go through the mailing list -
> > all the "sane" (from my POW) patches are in the l2 tree.
> > 
> > But please, do not create another tree now :-) Either start reviewing
> > others' patches, or declare ownership for some part of MTD and let's
> > create a corresponding branch in my tree for you. E.g., gpmi.
> 
> thanks.
> 
> But it is no need to create a branch for gpmi. The purely gpmi patches
> are very few. Most of time, the gpmi drives the mtd code to change.
> And the patch set is for both the mtd and the gpmi.

I will start looking at MTD mailing list patches soon and start picking
them. Just back from vacation.

> > In case of Brian, I'd fully trust the entire NAND subsystem to him, he
> > demonstrated that he is capable of taking care of it.
> If Brian acks a patch, and there is no more comment for this patch,
> and you are too busy to review this patch and accept this patch.
> How can this patch be pushed to l2-mtd ? 

I'll change my practice and will start processing patches which have
acks from others first.

> This is the exactly situation we are facing now.
> 
> If he has the right to push to the l2-mtd tree, i think we can speed up the mtd.

I am fine with giving Brian Norris write rights to the. I trust his
expertise and I like the way communicates and works in the MTD mailing
list.

-- 
Best Regards,
Artem Bityutskiy

Re: No pull for mtd?

[Artem Bityutskiy]

On Tue, 2013-07-30 at 17:03 +0300, Artem Bityutskiy wrote:
> I am fine with giving Brian Norris write rights to the. I trust his
> expertise and I like the way communicates and works in the MTD mailing
> list.

Sorry, I was typing while being in a meeting. Here is the corrected
version.

I am fine with giving Brian Norris write access rights to the l2 tree. I
trust his expertise and I like the way he communicates and works on the
MTD mailing list.

-- 
Best Regards,
Artem Bityutskiy

Re: No pull for mtd?

[Brian Norris]

On Tue, Jul 30, 2013 at 6:53 PM, Huang Shijie <shijie8@gmail.com> wrote:
> On Tue, Jul 30, 2013 at 02:04:08PM +0300, Artem Bityutskiy wrote:
>> On Sat, 2013-07-20 at 08:22 -0400, Huang Shijie wrote:
>> > I really envy the other maillist, you can get response in several
>> > days.
>>
>> Well, yes. MTD is a small and (IMHO) a veeery slowly dying subsystem.
> I am not sure it is dying, but there are still so many patches pending
> in the maillist.

Dying or not (it certainly doesn't have its youthful vigor ATM), I
agree with Huang that the current response time is not sufficient for
the current level of contribution.

>> Brian was one of those who did great job in MTD overall, especially in
>> the NAND framework. He reviewed others patches. But even Brian got
>> silent lately.
> I think he feels frastrated too. :)

Slowness certainly helps divert my attention to other things (for
instance, I'll send a patch series, then forget about it for a while,
due to no review/response). But on the flipside, I will admit that I
have not always been proactive on reviewing others' work. But that can
change, especially if there's an incentive that my review will
actually mean quicker acceptance and progress.

Brian

Re: No pull for mtd?

[Brian Norris]

Hi Huang,

On Tue, Jul 30, 2013 at 7:24 PM, Huang Shijie <shijie8@gmail.com> wrote:
> On Tue, Jul 30, 2013 at 05:03:54PM +0300, Artem Bityutskiy wrote:
>> I'll change my practice and will start processing patches which have
>> acks from others first.
>>
> For the common code, such as mtd/bbt code, we can give the acks.
> But for the specific drivers, it's better that you merge them yourself.

I have the same issue sometimes (regarding "specific drivers"); it's
actually easier for me (and more rewarding) to review work on the
common subsystem portions than it is to understand (and review) the
exact behavior of a particular driver/hardware. But then again, I
don't expect that Artem has much more hands-on experience with, say, a
pxa3xx or a TI OMAP NAND than you or I do. So we can give general
design and code quality recommendations/reviews even for drivers that
are not "our own."

(At the same time, it's possible I will do some work to get myself
more variety of test boards so I can test a broader range of the
MTD/NAND subsystem.)

Brian

Re: No pull for mtd?

[Brian Norris]

On Tue, Jul 30, 2013 at 8:26 AM, Artem Bityutskiy <dedekind1@gmail.com> wrote:
> On Tue, 2013-07-30 at 17:03 +0300, Artem Bityutskiy wrote:
>> I am fine with giving Brian Norris write rights to the. I trust his
>> expertise and I like the way communicates and works in the MTD mailing
>> list.
>
> Sorry, I was typing while being in a meeting. Here is the corrected
> version.
>
> I am fine with giving Brian Norris write access rights to the l2 tree. I
> trust his expertise and I like the way he communicates and works on the
> MTD mailing list.

Thanks for the confidence. I am willing to accept responsibility for
NAND and am open to assisting on other parts of MTD as well. I'll need
an infradead account, of course.

There may still be kinks to work out; e.g., how do we coordinate
rebasing and patch ordering of l2-mtd -- I commented on this earlier,
in response to David. I would prefer to minimize rebasing, but mainly,
I just want to be on the same page as you, Artem, so that we don't
duplicate or conflict in our patch integration efforts.

Brian

Re: No pull for mtd?

[Huang Shijie]

On Tue, Jul 30, 2013 at 02:04:08PM +0300, Artem Bityutskiy wrote:
> On Sat, 2013-07-20 at 08:22 -0400, Huang Shijie wrote:
> > 
> > If more people can ack and merge the patches, we can speed up the mtd.
> 
> Sure. Go ahead and review things which are outside of your gpmi driver.
> Ack them, nack them, review them, etc. This will be a real help.
ok.
i will spend more time to review the patches.

> > 
> > I really envy the other maillist, you can get response in several
> > days.
> 
> Well, yes. MTD is a small and (IMHO) a veeery slowly dying subsystem.
I am not sure it is dying, but there are still so many patches pending
in the maillist.

> People mostly care about their own little things. Few people are
> interested in improving it in general. Such is life.

I am interested in improve the general code. But my patch set is
pending so long to accept. I feel frastrated. I still have some other
patch set queued in my hand, and do not be sent out.  
The patch sets have dependency. If the patch set A is not merged,
i can not send out the patch set B.    

And i still want to some more features to the mtd, such as cache read,
multi-lun read.    

> 
> Brian was one of those who did great job in MTD overall, especially in
> the NAND framework. He reviewed others patches. But even Brian got
> silent lately.
I think he feels frastrated too. :)

> 
> Shmulik comes to mind - he reviewed things all over MTD.
> 
> You mostly contribute to your own driver. And I think there were times
> when I had to ask you to do an infrastructure rework instead of working
> around MTD infrastructure problems with in-driver hacks. No one is
> perfect :-)
sorry. I was too busy in the past. But i have more time in the future.

> 
> So there is simply not enough people, thus the slowness.
> 
> > > 
> > > I guess we'll see what Artem thinks when he's back from vacation and
> > Waiting for Artem's solution too. He becomes much busy this year, and
> > can not review the patches as he did last year.
> 
> Well, just go ahead and help.
> 
> This is also how the l2 tree appeared. I noticed that dwmw2 is becoming
> slow, and I just went ahead and created this tree without asking him,
> and told him that now he does not have to go through the mailing list -
> all the "sane" (from my POW) patches are in the l2 tree.
> 
> But please, do not create another tree now :-) Either start reviewing
> others' patches, or declare ownership for some part of MTD and let's
> create a corresponding branch in my tree for you. E.g., gpmi.

thanks.

But it is no need to create a branch for gpmi. The purely gpmi patches
are very few. Most of time, the gpmi drives the mtd code to change.
And the patch set is for both the mtd and the gpmi.


> 
> In case of Brian, I'd fully trust the entire NAND subsystem to him, he
> demonstrated that he is capable of taking care of it.
If Brian acks a patch, and there is no more comment for this patch,
and you are too busy to review this patch and accept this patch.
How can this patch be pushed to l2-mtd ? 

This is the exactly situation we are facing now.

If he has the right to push to the l2-mtd tree, i think we can speed up the mtd.

thanks
Huang Shijie

Re: No pull for mtd?

[Huang Shijie]

On Tue, Jul 30, 2013 at 05:03:54PM +0300, Artem Bityutskiy wrote:
> 
> I'll change my practice and will start processing patches which have
> acks from others first.
> 
For the common code, such as mtd/bbt code, we can give the acks.
But for the specific drivers, it's better that you merge them yourself.

Best Regards
Huang Shijie