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 18/07/2014 17:38, 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?
You can use `splitpatch` to split a patch into multiple mails with the
correct mailing list and maintainers. It generates a script to
chain-send these emails using `cocci-send-email` (a modified version of
`git-send-email`).
Both are available in the `tools/` directory of coccinelle's
distribution <http://coccinelle.lip6.fr/>.
--
Benoît Taine
Master cycle intern
Regal Team. LIP6
> 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?
Spurious checkpatch.pl changes increasing number of git-blame
"false positives" are more than enough.
Alexey
2014-07-18 17:46 GMT+03:00 Benoit Taine <[email protected]>:
> On 18/07/2014 17:38, 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?
> You can use `splitpatch` to split a patch into multiple mails with the
> correct mailing list and maintainers. It generates a script to
> chain-send these emails using `cocci-send-email` (a modified version of
> `git-send-email`).
>
> Both are available in the `tools/` directory of coccinelle's
> distribution <http://coccinelle.lip6.fr/>.
Thank you for this info, but it doesn't match exactly what i seek for.
I'd like to automate checking and sending exactly of range of git
commits, or of a set of files generated by git-format-patch.
I also cannot use cocci-send-email because it doesn't pick To: and Cc:
lines which i inject into git-format-patch-formatted files. And i
don't know tools to format the patches in "The original format used by
Greg Kroah-Hartman's send_lots_of_email.pl script".
My target should be to
- check all patches,
- find set of email addresses to Cc for each patch,
- send them at once to correct sets of addresses, entering SMTP
password only once if it is not stored in git-config.
2014-07-18 17:55 GMT+03:00 Alexey Dobriyan <[email protected]>:
>> 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?
>
> Spurious checkpatch.pl changes increasing number of git-blame
> "false positives" are more than enough.
Alexey, sorry, I completely don't get you, could you please elaborate
your reply?
--
Andrey Utkin
On Fri, Jul 18, 2014 at 06:24:15PM +0300, Andrey Utkin wrote:
> 2014-07-18 17:46 GMT+03:00 Benoit Taine <[email protected]>:
> > On 18/07/2014 17:38, 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?
>
> > You can use `splitpatch` to split a patch into multiple mails with the
> > correct mailing list and maintainers. It generates a script to
> > chain-send these emails using `cocci-send-email` (a modified version of
> > `git-send-email`).
> >
> > Both are available in the `tools/` directory of coccinelle's
> > distribution <http://coccinelle.lip6.fr/>.
>
> Thank you for this info, but it doesn't match exactly what i seek for.
> I'd like to automate checking and sending exactly of range of git
> commits, or of a set of files generated by git-format-patch.
> I also cannot use cocci-send-email because it doesn't pick To: and Cc:
> lines which i inject into git-format-patch-formatted files. And i
> don't know tools to format the patches in "The original format used by
> Greg Kroah-Hartman's send_lots_of_email.pl script".
> My target should be to
> - check all patches,
> - find set of email addresses to Cc for each patch,
> - send them at once to correct sets of addresses, entering SMTP
> password only once if it is not stored in git-config.
git send-email can do all of the last two things, have you tried it?
As for the format for my old script, I should just delete that logic, I
don't even use it anymore, I just use git send-email.
thanks,m
greg k-h
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, 2014-07-18 at 18:22 -0400, Theodore Ts'o wrote:
> 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
True.
checkpatch should not be used on existing commits.
checkpatch should be used prior to committing.
> and get_maintainers.pl.
I think checkpatch is pretty good about cc'ing mostly the
right folk by default.
Where it's not adequate is when some particular bit of code
was written by someone not the maintainer and that writer
should also be copied on a patch.
Many different command-line options exist for get_maintainer.
Perhaps too many. --git-blame can be used with patches to
also list the author of any modified commit. Using that
option can take a fairly long while to run though.
> Their output is not always correct, and some amount of human common
> sense is required.
True. Experience is more of a benefit than common sense here.
> 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 is no good solution to this problem.
You can't cc the world on patch 1/n (vger rejects emails
with too many recipients) and cc just the maintainers on x/n.
One solution is to send the 0/n and 1/n patches to all the
email lists that are cc'd on any single patch of large patch
series.
A better solution might be to send _only_ the 1/n patch to
lkml and to someone like Andrew Morton with an explanation
as to why it's useful, wait for it to be applied, then send
the large patch series during the next release cycle.
> There's a reason why many developers cordially hate these scripts;
> it's too easy to misuse them,
Yup, though cordial can be a misdescription for some of
those developers...
I hope everyone enjoys their weekends...
On Fri, 2014-07-18 at 15:47 -0700, Joe Perches wrote:
> On Fri, 2014-07-18 at 18:22 -0400, Theodore Ts'o wrote:
> > and get_maintainers.pl.
> I think checkpatch
Umm, make that get_maintainer...
> is pretty good about cc'ing mostly the
> right folk by default.
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 <[email protected]> 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 [email protected]
> 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 <[email protected]> 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
[email protected]