![]() | |||||||||||
Messages in this thread Complete thread (EXPERIMENTAL) |
On Sat, Apr 26, 2008 at 07:51:32AM -0700, Andrew Morton wrote:
On Sat, 26 Apr 2008 14:00:44 +0300 Adrian Bunk <bunk@kernel.org> wrote:
Why do other people get over 100 checkpatch fixes into the tree at once
or Linus applies patches directly bypassing the maintainers (like the
one you sent just before [3], which I've also already sent before [4])
but my patches bitrot forever?
If I am not cc'ed on a patch and have to resort to plucking it off the mailing list it ends up being significantly more work and more error-prone for me to process it. I used to merge your patches but then you chose to stop ccing me on them so I stopped applying them. The increased hassle just isn't worth it for some random make-foo-static patch. I do try to keep an eye out for more significant changes but hey, stuff happens. You chose to disrupt the workflow and now you're here complaining and blaming others for the consequences of your own action. Why didn't you tell me an explicit Cc is important for you? Don't know, really. Something in me resiles from going and doing things which increase the patch volume, perhaps. I'll resend my pending batch with a Cc to you.
OK. Many of your make-static-foo-etc patches are in fact fixes against recently-merged changes, I think. It's better to get those fixes folded into the errant patch before things go into mainline: we get one correct commit in the permanent record rather than one dodgy commit followed by a later oh-let's-fix-that-up commit. So I'd encourage you to try to catch these things in -mm or linux-next and, if poss (and I know it's a bit of work), identify the offending commit. git-tree owners might need, umm, some encouragement here. It's much easier for them to slap the oh-let's-fix-that-up commit at the tail of their queue, which leaves us with the straggly commit record. | ||||||||||
![]() | |||||||||||
| Last update: 2008-04-26 17:47 [W:0.254 / U:0.210 seconds] ©2003-2005 Jasper Spaans | |||||||||||