How to automate checkpatch && get_maintainers && git send-email of commits range?
Is there script for automated checkpatch.pl && get_maintainers.pl && git send-email for range of commits? I see none. Would it be welcome to submit such one to kernel tree? -- Andrey Utkin
On Fri, Jul 18, 2014 at 05:38:30PM +0300, Andrey Utkin wrote:
Is there script for automated checkpatch.pl && get_maintainers.pl && git send-email for range of commits? I see none. Would it be welcome to submit such one to kernel tree?
Too much automation can be a really bad thing. You **really** want to sanity check the output of checkpatch.pl and get_maintainers.pl. Their output is not always correct, and some amount of human common sense is required. (Granted Nick Krause hasn't shown much in the way of common sense, but some human intervention --- assuming he is human and not an badly written, automated troll program --- is better than none.) The other thing is that I strongly recommend that people use git format-patch first, to make sure that what you will be blasting out to thousands of peoples' mail boxes is in fact sane. And then think very hard about which patches people need to see in order to be able to evaluate a patch. For example, if you have patch 1 out of a series which adds a new function, and then patches 2 through 1000 modify a thousand different drivers to use that new function, if you use an automated get_maintainers.pl script to send each patch to just the maintainer, then the device driver maintainer might not see patch #1 which is critical context to understanding the patch that you want to make to his driver. And then you will have several hundred very angry and annoyed developers wondering why you sent them patch 345/1000, with no other context, and wondering what the heck they are supposed to do with the email that you have just launched into their inbox. There's a reason why many developers cordially hate these scripts; it's too easy to misuse them, and unfortunately, there are too many Nick Krause like idiots out there who mindlessly use such scripts and cause pain to maintainers. The critical step is to force such idiots to stop and ***think*** and unfortunately, automation seems to encourage the opposite behaviour. Regards, - Ted
On Fri, Jul 18, 2014 at 06:22:15PM -0400, Theodore Ts'o wrote:
And then think very hard about which patches people need to see in order to be able to evaluate a patch. For example, if you have patch 1 out of a series which adds a new function, and then patches 2 through 1000 modify a thousand different drivers to use that new function, if you use an automated get_maintainers.pl script to send each patch to just the maintainer, then the device driver maintainer might not see patch #1 which is critical context to understanding the patch that you want to make to his driver. And then you will have several hundred very angry and annoyed developers wondering why you sent them patch 345/1000, with no other context, and wondering what the heck they are supposed to do with the email that you have just launched into their inbox.
I'm still stuck in the old stone/quilt age, where I use quilt mail to send my patch bombs. Although, I have scripts that pulls my patches out from git with format-patch, and then creates a quilt queue from them. I do this for that very reason that I want to review all patches before I hit send, and quilt mail is very basic and sends what I tell it. I still a bit gun shy from using git sendmail as I never got that to work (note, the last time I tried, it was still doing the staircase threads with patches by default). I'm still content with quilt, but the one thing I don't care about it is that all Cc'd on the 0/1000 patch gets Cc'd on all patches. I wish there was a way to tell quilt that they should only get Cc'd on the cover patch and no more, unless the patch has them Cc'd. The reason this bothers me is that I tend to do exactly what you stated above. I will just Cc patch 345/1000 to someone with no context of what that patch is. I figured people would do the same thing that I do when I get that 345th patch. As I'm subscribed to LKML, I will just go into my lkml folder and search for that patch and see how that thread applies to me with full context. I'm assuming that's what others may do too. -- Steve
On Sat, Jul 19, 2014 at 9:31 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
On Fri, Jul 18, 2014 at 06:22:15PM -0400, Theodore Ts'o wrote:
And then think very hard about which patches people need to see in order to be able to evaluate a patch. For example, if you have patch 1 out of a series which adds a new function, and then patches 2 through 1000 modify a thousand different drivers to use that new function, if you use an automated get_maintainers.pl script to send each patch to just the maintainer, then the device driver maintainer might not see patch #1 which is critical context to understanding the patch that you want to make to his driver. And then you will have several hundred very angry and annoyed developers wondering why you sent them patch 345/1000, with no other context, and wondering what the heck they are supposed to do with the email that you have just launched into their inbox.
I'm still stuck in the old stone/quilt age, where I use quilt mail to send my patch bombs. Although, I have scripts that pulls my patches out from git with format-patch, and then creates a quilt queue from them. I do this for that very reason that I want to review all patches before I hit send, and quilt mail is very basic and sends what I tell it. I still a bit gun shy from using git sendmail as I never got that to work (note, the last time I tried, it was still doing the staircase threads with patches by default).
I'm still content with quilt, but the one thing I don't care about it is that all Cc'd on the 0/1000 patch gets Cc'd on all patches. I wish there was a way to tell quilt that they should only get Cc'd on the cover patch and no more, unless the patch has them Cc'd. The reason this bothers me is that I tend to do exactly what you stated above. I will just Cc patch 345/1000 to someone with no context of what that patch is.
I figured people would do the same thing that I do when I get that 345th patch. As I'm subscribed to LKML, I will just go into my lkml folder and search for that patch and see how that thread applies to me with full context. I'm assuming that's what others may do too.
Hi Steve Why not share your quilt skills, say by adding a file in the Document directory? Hillf
Hi Steve
Why not share your quilt skills, say by adding a file in the Document directory?
Hillf -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
I agree with hillf here this may be of use to other developers on the lkml and you should write a file in the Document dictionary. Nick
On Sat, Jul 19, 2014 at 11:35:45AM +0800, Hillf Danton wrote:
On Sat, Jul 19, 2014 at 9:31 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
On Fri, Jul 18, 2014 at 06:22:15PM -0400, Theodore Ts'o wrote:
And then think very hard about which patches people need to see in order to be able to evaluate a patch. For example, if you have patch 1 out of a series which adds a new function, and then patches 2 through 1000 modify a thousand different drivers to use that new function, if you use an automated get_maintainers.pl script to send each patch to just the maintainer, then the device driver maintainer might not see patch #1 which is critical context to understanding the patch that you want to make to his driver. And then you will have several hundred very angry and annoyed developers wondering why you sent them patch 345/1000, with no other context, and wondering what the heck they are supposed to do with the email that you have just launched into their inbox.
I'm still stuck in the old stone/quilt age, where I use quilt mail to send my patch bombs. Although, I have scripts that pulls my patches out from git with format-patch, and then creates a quilt queue from them. I do this for that very reason that I want to review all patches before I hit send, and quilt mail is very basic and sends what I tell it. I still a bit gun shy from using git sendmail as I never got that to work (note, the last time I tried, it was still doing the staircase threads with patches by default).
I'm still content with quilt, but the one thing I don't care about it is that all Cc'd on the 0/1000 patch gets Cc'd on all patches. I wish there was a way to tell quilt that they should only get Cc'd on the cover patch and no more, unless the patch has them Cc'd. The reason this bothers me is that I tend to do exactly what you stated above. I will just Cc patch 345/1000 to someone with no context of what that patch is.
I figured people would do the same thing that I do when I get that 345th patch. As I'm subscribed to LKML, I will just go into my lkml folder and search for that patch and see how that thread applies to me with full context. I'm assuming that's what others may do too.
Hi Steve
Why not share your quilt skills, say by adding a file in the Document directory?
guilt (quilt for git) already does all this scripting for you. Cheers, Dave. -- Dave Chinner david@fromorbit.com
participants (6)
-
Andrey Utkin -
Dave Chinner -
Hillf Danton -
Nick Krause -
Steven Rostedt -
Theodore Ts'o