No pull for mtd?
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!
Signature · 3 lines
Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com
Quoted 2 lines · Ezequiel Garcia
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
Quoted 9 lines · Brian Norris
Quoted 2 lines · Ezequiel Garcia
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
A message that is not in the archive (sent off-list or not yet received): CAF4G-tLsOO_F-Mhn=+5vS2kkJuoeLJwrTdCR90DVuQQ+xn40aw@mail.gmail.com
Quoted 2 lines · Artem Bityutskiy
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
Quoted 10 lines · Brian Norris
Quoted 2 lines · Artem Bityutskiy
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.
Signature · 1 line
dwmw2
Quoted 12 lines · David Woodhouse
Quoted 10 lines · Brian Norris
Quoted 2 lines · Artem Bityutskiy
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).
Quoted 7 lines
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
Quoted 2 lines · Brian Norris
Is there any hassling the rest of us can do in the future to avoid this situation?
Certainly can't hurt :)
Quoted 3 lines
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?
Signature · 1 line
dwmw2
Quoted 5 lines · David Woodhouse
Quoted 2 lines · Brian Norris
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?
Quoted 8 lines
Quoted 3 lines
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 :)
Quoted 7 lines
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.
Quoted 5 lines
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.
Quoted 10 lines
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?
Quoted 7 lines
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.
Quoted 3 lines
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.
Quoted 7 lines
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.
Quoted 6 lines
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
Quoted 19 lines · Brian Norris
Quoted 5 lines · David Woodhouse
Quoted 2 lines · Brian Norris
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?
Quoted 8 lines
Quoted 3 lines
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.
Quoted 78 lines
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 :)
Quoted 7 lines
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.
Quoted 5 lines
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.
Quoted 10 lines
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?
Quoted 7 lines
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.
Quoted 3 lines
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.
Quoted 12 lines
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.
Quoted 8 lines
Quoted 1 line
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.
Quoted 2 lines
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
Quoted 4 lines · Huang Shijie
Quoted 2 lines
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
Quoted 1 line
to changes in job situations (where at least you and Artem aren't
Quoted 8 lines
even
Quoted 1 line
employed in MTD-related work anymore), vacations, babies, absences,
or
Quoted 2 lines
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.
Quoted 3 lines
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.
Quoted 4 lines
Quoted 2 lines
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.
Signature · 2 lines
Best Regards, Artem Bityutskiy
Quoted 6 lines · Artem Bityutskiy
Quoted 2 lines · Huang Shijie
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.
Quoted 5 lines
Quoted 3 lines
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.
Quoted 2 lines
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.
Quoted 4 lines
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. :)
Quoted 7 lines
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.
Quoted 10 lines
So there is simply not enough people, thus the slowness.
Quoted 4 lines
Quoted 2 lines
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.
Quoted 8 lines
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.
Quoted 3 lines
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
Quoted 11 lines · Huang Shijie
Quoted 10 lines
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.
Quoted 5 lines
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.
Quoted 5 lines
Quoted 2 lines
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.
Quoted 3 lines
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.
Signature · 2 lines
Best Regards, Artem Bityutskiy
Quoted 4 lines · Artem Bityutskiy
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
Hi Huang,
Quoted 6 lines · Huang Shijie
Quoted 3 lines · Artem Bityutskiy
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
Quoted 3 lines · Artem Bityutskiy
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.
Signature · 2 lines
Best Regards, Artem Bityutskiy
Quoted 11 lines · Artem Bityutskiy
Quoted 3 lines · Artem Bityutskiy
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
Quoted 8 lines · Huang Shijie
Quoted 5 lines · Artem Bityutskiy
Quoted 2 lines · Huang Shijie
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.
Quoted 4 lines
Quoted 3 lines
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
Quoted 5 lines · Brian Norris
Quoted 3 lines
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
Quoted 1 line
would be. And it's close *enough* to what I'm actually going to
Quoted 8 lines
accept,
Quoted 1 line
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.
Signature · 2 lines
Best Regards, Artem Bityutskiy
Quoted 5 lines · David Woodhouse
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.
Quoted 1 line
Brian, Huang, thanks for volunteering to help. It's much appreciated.
Indeed.
Quoted 3 lines
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.
Signature · 2 lines
Best Regards, Artem Bityutskiy