[switch to LKML]
On Fri, Jun 15, 2012 at 06:47:32PM -0700, Greg Kroah-Hartman wrote:
> On Sat, Jun 16, 2012 at 09:16:46AM +0800, Fengguang Wu wrote:
> > Hi list,
> >
> > I'm sorry if this pile of build errors disturbed you too much. If
> > the error notification is too permissive, I can limit it in two ways:
> >
> > 1) only notify build errors on the first kconfig. There may be a few
> > new error messages show up in the other kconfig builds, however
> > mostly are just irritating duplications.
>
> Duplicates should be suppressed, they are just annoying.
OK! I'll suppress noises in four ways:
rule 1: all newly shown-up error messages will be only notified for
the current commit and remembered to be "known bug" thereafter.
rule 2: when one bad commit triggers build errors in multiple kconfigs,
only one of them will be CCed. The patch author will still get
full information in private emails.
rule 3: when one bad commit triggers build errors in the _subsequent_
innocent commits of the same branch, the emails will be sent
to myself for manual check first. This will inevitably lead to
more delays (esp. when I'm sleeping), however 2+ bad commits
should not happen frequently.
rule 4: gcc/sparse warnings will never be CCed. Only private email
notifications will be sent to the author.
The above rules should be able to reduce the noise level close to 0
for maintainers and public mailing lists.
The commit author may still see some noises, however the good thing
is, he should be able to tell signals from noises much easier than
the others.
> > 2) only notify the mailing list directly associated with the git tree.
> > In this particular case, to only CC [email protected], and
> > to avoid the linux-mtd and linuxppc-dev lists.
>
> Yes, that would be the best thing to do to start with, then let the
> developers take it from there.
Good point! The developers knows best who to CC :)
Thanks,
Fengguang
On Sat, Jun 16, 2012 at 10:50:31AM +0800, Fengguang Wu wrote:
> [switch to LKML]
>
> On Fri, Jun 15, 2012 at 06:47:32PM -0700, Greg Kroah-Hartman wrote:
> > On Sat, Jun 16, 2012 at 09:16:46AM +0800, Fengguang Wu wrote:
> > > Hi list,
> > >
> > > I'm sorry if this pile of build errors disturbed you too much. If
> > > the error notification is too permissive, I can limit it in two ways:
> > >
> > > 1) only notify build errors on the first kconfig. There may be a few
> > > new error messages show up in the other kconfig builds, however
> > > mostly are just irritating duplications.
> >
> > Duplicates should be suppressed, they are just annoying.
>
> OK! I'll suppress noises in four ways:
>
> rule 1: all newly shown-up error messages will be only notified for
> the current commit and remembered to be "known bug" thereafter.
>
> rule 2: when one bad commit triggers build errors in multiple kconfigs,
> only one of them will be CCed. The patch author will still get
> full information in private emails.
>
> rule 3: when one bad commit triggers build errors in the _subsequent_
> innocent commits of the same branch, the emails will be sent
> to myself for manual check first. This will inevitably lead to
> more delays (esp. when I'm sleeping), however 2+ bad commits
> should not happen frequently.
>
> rule 4: gcc/sparse warnings will never be CCed. Only private email
> notifications will be sent to the author.
>
> The above rules should be able to reduce the noise level close to 0
> for maintainers and public mailing lists.
>
> The commit author may still see some noises, however the good thing
> is, he should be able to tell signals from noises much easier than
> the others.
How about also cc: not only the author where you mention it above, but
everyone who signed-off on the patch? That would provide a bit of peer
pressure to ensure that the problems get fixed.
Oh, and thanks for working on this, it's much appreciated.
greg k-h
Hi Greg,
On Fri, Jun 15, 2012 at 08:44:20PM -0700, Greg Kroah-Hartman wrote:
> On Sat, Jun 16, 2012 at 10:50:31AM +0800, Fengguang Wu wrote:
> > [switch to LKML]
> >
> > On Fri, Jun 15, 2012 at 06:47:32PM -0700, Greg Kroah-Hartman wrote:
> > > On Sat, Jun 16, 2012 at 09:16:46AM +0800, Fengguang Wu wrote:
> > > > Hi list,
> > > >
> > > > I'm sorry if this pile of build errors disturbed you too much. If
> > > > the error notification is too permissive, I can limit it in two ways:
> > > >
> > > > 1) only notify build errors on the first kconfig. There may be a few
> > > > new error messages show up in the other kconfig builds, however
> > > > mostly are just irritating duplications.
> > >
> > > Duplicates should be suppressed, they are just annoying.
> >
> > OK! I'll suppress noises in four ways:
> >
> > rule 1: all newly shown-up error messages will be only notified for
> > the current commit and remembered to be "known bug" thereafter.
> >
> > rule 2: when one bad commit triggers build errors in multiple kconfigs,
> > only one of them will be CCed. The patch author will still get
> > full information in private emails.
> >
> > rule 3: when one bad commit triggers build errors in the _subsequent_
> > innocent commits of the same branch, the emails will be sent
> > to myself for manual check first. This will inevitably lead to
> > more delays (esp. when I'm sleeping), however 2+ bad commits
> > should not happen frequently.
> >
> > rule 4: gcc/sparse warnings will never be CCed. Only private email
> > notifications will be sent to the author.
> >
> > The above rules should be able to reduce the noise level close to 0
> > for maintainers and public mailing lists.
> >
> > The commit author may still see some noises, however the good thing
> > is, he should be able to tell signals from noises much easier than
> > the others.
>
> How about also cc: not only the author where you mention it above, but
> everyone who signed-off on the patch? That would provide a bit of peer
> pressure to ensure that the problems get fixed.
That's (interesting and) good point. If me understand you right:
- TO: author, CC: Signed-off-by, CC: (sub-)subsystem mailing list
for build errors
- TO: author, CC: Signed-off-by (but sure, remove the top level busy maintainers)
for gcc warnings
- TO: author
for sparse warnings (however I'm still too afraid to enable sparse checks)
> Oh, and thanks for working on this, it's much appreciated.
Thank you :)
Regards,
Fengguang
On Sat, Jun 16, 2012 at 12:11:44PM +0800, Fengguang Wu wrote:
> Hi Greg,
>
> On Fri, Jun 15, 2012 at 08:44:20PM -0700, Greg Kroah-Hartman wrote:
> > On Sat, Jun 16, 2012 at 10:50:31AM +0800, Fengguang Wu wrote:
> > > [switch to LKML]
> > >
> > > On Fri, Jun 15, 2012 at 06:47:32PM -0700, Greg Kroah-Hartman wrote:
> > > > On Sat, Jun 16, 2012 at 09:16:46AM +0800, Fengguang Wu wrote:
> > > > > Hi list,
> > > > >
> > > > > I'm sorry if this pile of build errors disturbed you too much. If
> > > > > the error notification is too permissive, I can limit it in two ways:
> > > > >
> > > > > 1) only notify build errors on the first kconfig. There may be a few
> > > > > new error messages show up in the other kconfig builds, however
> > > > > mostly are just irritating duplications.
> > > >
> > > > Duplicates should be suppressed, they are just annoying.
> > >
> > > OK! I'll suppress noises in four ways:
> > >
> > > rule 1: all newly shown-up error messages will be only notified for
> > > the current commit and remembered to be "known bug" thereafter.
> > >
> > > rule 2: when one bad commit triggers build errors in multiple kconfigs,
> > > only one of them will be CCed. The patch author will still get
> > > full information in private emails.
> > >
> > > rule 3: when one bad commit triggers build errors in the _subsequent_
> > > innocent commits of the same branch, the emails will be sent
> > > to myself for manual check first. This will inevitably lead to
> > > more delays (esp. when I'm sleeping), however 2+ bad commits
> > > should not happen frequently.
> > >
> > > rule 4: gcc/sparse warnings will never be CCed. Only private email
> > > notifications will be sent to the author.
> > >
> > > The above rules should be able to reduce the noise level close to 0
> > > for maintainers and public mailing lists.
> > >
> > > The commit author may still see some noises, however the good thing
> > > is, he should be able to tell signals from noises much easier than
> > > the others.
> >
> > How about also cc: not only the author where you mention it above, but
> > everyone who signed-off on the patch? That would provide a bit of peer
> > pressure to ensure that the problems get fixed.
>
> That's (interesting and) good point. If me understand you right:
>
> - TO: author, CC: Signed-off-by, CC: (sub-)subsystem mailing list
> for build errors
>
> - TO: author, CC: Signed-off-by (but sure, remove the top level busy maintainers)
> for gcc warnings
Or, just remove the committer from CC: and add Reviewed-by to CC:
By reviewing, one should already be familiar with the patch.
Thanks,
Fengguang
> - TO: author
> for sparse warnings (however I'm still too afraid to enable sparse checks)
>
> > Oh, and thanks for working on this, it's much appreciated.
>
> Thank you :)
>
> Regards,
> Fengguang
On Sat, Jun 16, 2012 at 12:20:10PM +0800, Fengguang Wu wrote:
> > > How about also cc: not only the author where you mention it above, but
> > > everyone who signed-off on the patch? That would provide a bit of peer
> > > pressure to ensure that the problems get fixed.
> >
> > That's (interesting and) good point. If me understand you right:
> >
> > - TO: author, CC: Signed-off-by, CC: (sub-)subsystem mailing list
> > for build errors
> >
> > - TO: author, CC: Signed-off-by (but sure, remove the top level busy maintainers)
> > for gcc warnings
Well, if I sign-off on a patch, I want to know about gcc warnings that
were added by it, don't not email me just because you think I'm busy.
> Or, just remove the committer from CC: and add Reviewed-by to CC:
> By reviewing, one should already be familiar with the patch.
I don't think you should drop the committer, but maybe that's just me.
> > - TO: author
> > for sparse warnings (however I'm still too afraid to enable sparse checks)
This might get tougher in some areas of the kernel like the
drivers/staging/ tree where people incrementally fix things up, like fix
trailing space issues on one patch, which doesn't change the rest of the
line that might have had coding style or sparse issues in it. That's
why I can't always run checkpatch.pl on patches sent to me, and why
sparse might not help out.
But, I'd love to see sparse run on other areas of the kernel (i.e.
anything not in drivers/staging/) hopefully it would get those areas
fixed up properly.
thanks,
greg k-h
On Sat, Jun 16, 2012 at 08:27:20AM -0700, Greg Kroah-Hartman wrote:
> On Sat, Jun 16, 2012 at 12:20:10PM +0800, Fengguang Wu wrote:
> > > > How about also cc: not only the author where you mention it above, but
> > > > everyone who signed-off on the patch? That would provide a bit of peer
> > > > pressure to ensure that the problems get fixed.
> > >
> > > That's (interesting and) good point. If me understand you right:
> > >
> > > - TO: author, CC: Signed-off-by, CC: (sub-)subsystem mailing list
> > > for build errors
> > >
> > > - TO: author, CC: Signed-off-by (but sure, remove the top level busy maintainers)
> > > for gcc warnings
>
> Well, if I sign-off on a patch, I want to know about gcc warnings that
> were added by it, don't not email me just because you think I'm busy.
OK :)
> > Or, just remove the committer from CC: and add Reviewed-by to CC:
> > By reviewing, one should already be familiar with the patch.
>
> I don't think you should drop the committer, but maybe that's just me.
Understand. Let's default to CC all signers and committer.
> > > - TO: author
> > > for sparse warnings (however I'm still too afraid to enable sparse checks)
>
> This might get tougher in some areas of the kernel like the
> drivers/staging/ tree where people incrementally fix things up, like fix
> trailing space issues on one patch, which doesn't change the rest of the
> line that might have had coding style or sparse issues in it. That's
> why I can't always run checkpatch.pl on patches sent to me, and why
> sparse might not help out.
Ah got it.
> But, I'd love to see sparse run on other areas of the kernel (i.e.
> anything not in drivers/staging/) hopefully it would get those areas
> fixed up properly.
Sure, I can blacklist the staging tree and still do sparse
notifications for others.
Thanks,
Fengguang