Linux: Using Acked-by Tags

Submitted by Jeremy
on June 7, 2007 - 1:56pm

Andrew Morton submitted some documentation explaining the use of the "Signed-off-by" and "Acked-by" tags added when patches are submitted for conclusion into the Linux kernel. "The Signed-off-by: tag implies that the signer was involved in the development of the patch, or that he/she was in the patch's delivery path," the documentation explains, "if a person was not directly involved in the preparation or handling of a patch but wishes to signify and record their approval of it then they can arrange to have an Acked-by: line added to the patch's changelog." When asked about the possibility of including "Tested-by" tags, Andrew replied, "I think it's very useful information to have. For a start, it tells you who has the hardware and knows how to build a kernel. So if you're making a change to a driver and want it tested, you can troll the file's changelog looking for people who might be able to help."

The thread went on to discuss if Ack and Nack patches were useful from non-maintainers. Andrew suggested that a without additional information they don't offer much, "it's better to just provide constructive, detailed technical comments and from that it becomes pretty obvious to all parties whether or not the patch has a future. If you did properly provide that useful feedback then the 'ack' or 'nack' bit becomes redundant." He went on to stress the need for useful feedback, "frankly, I don't trust a simple 'ack' much at all. It's the kernel equivalent of 'whoa, kewl!'"


From: Andrew Morton [email blocked]
To:  linux-kernel
Subject: [patch 1/1] document Acked-by:
Date:	Thu, 31 May 2007 19:09:10 -0700

From: Andrew Morton [email blocked]

Explain what we use Acked-by: for, and how it differs from Signed-off-by:
Signed-off-by: Andrew Morton [email blocked]
---

 Documentation/SubmittingPatches |   15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff -puN Documentation/SubmittingPatches~document-acked-by Documentation/SubmittingPatches
--- a/Documentation/SubmittingPatches~document-acked-by
+++ a/Documentation/SubmittingPatches
@@ -328,7 +328,20 @@ now, but you can do this to mark interna
 point out some special detail about the sign-off. 
 
 
-12) The canonical patch format
+12) When to use Acked-by:
+
+The Signed-off-by: tag implies that the signer was involved in the development
+of the patch, or that he/she was in the patch's delivery path.
+
+If a person was not directly involved in the preparation or handling of a
+patch but wishes to signify and record their approval of it then they can
+arrange to have an Acked-by: line added to the patch's changelog.
+
+Acked-by: is often used by the maintainer of the affected code when that
+maintainer neither wrote, merged nor forwarded the patch themselves.
+
+
+13) The canonical patch format
 
 The canonical patch subject line is:
 

From: Valdis.Kletnieks [email blocked] Subject: Re: [patch 1/1] document Acked-by: Date: Fri, 01 Jun 2007 01:32:03 -0400 On Thu, 31 May 2007 19:09:10 PDT, [email blocked] said: > +If a person was not directly involved in the preparation or handling of a > +patch but wishes to signify and record their approval of it then they can > +arrange to have an Acked-by: line added to the patch's changelog. > + > +Acked-by: is often used by the maintainer of the affected code when that > +maintainer neither wrote, merged nor forwarded the patch themselves. Do we want to add verbiage saying that an Acked-By: is also useful when it comes from somebody (likely the original reporter) who has actually tested the patch?
From: "H. Peter Anvin" [email blocked] Subject: Re: [patch 1/1] document Acked-by: Date: Thu, 31 May 2007 23:10:42 -0700 [email blocked] wrote: > On Thu, 31 May 2007 19:09:10 PDT, [email blocked] said: > >> +If a person was not directly involved in the preparation or handling of a >> +patch but wishes to signify and record their approval of it then they can >> +arrange to have an Acked-by: line added to the patch's changelog. >> + >> +Acked-by: is often used by the maintainer of the affected code when that >> +maintainer neither wrote, merged nor forwarded the patch themselves. > > Do we want to add verbiage saying that an Acked-By: is also useful when it > comes from somebody (likely the original reporter) who has actually tested the > patch? I'd rather see a Tested-By: for that. There is a difference between a maintainer ack and a tester ok. -hpa
From: Valdis.Kletnieks [email blocked] Subject: Re: [patch 1/1] document Acked-by: Date: Fri, 01 Jun 2007 13:27:25 -0400 On Thu, 31 May 2007 23:10:42 PDT, "H. Peter Anvin" said: > Valdis.Kletnieks wrote: > > On Thu, 31 May 2007 19:09:10 PDT, [email blocked] said: > > > >> +If a person was not directly involved in the preparation or handling of a > >> +patch but wishes to signify and record their approval of it then they can > >> +arrange to have an Acked-by: line added to the patch's changelog. > >> + > >> +Acked-by: is often used by the maintainer of the affected code when that > >> +maintainer neither wrote, merged nor forwarded the patch themselves. > > > > Do we want to add verbiage saying that an Acked-By: is also useful when it > > comes from somebody (likely the original reporter) who has actually tested the > > patch? > > I'd rather see a Tested-By: for that. > > There is a difference between a maintainer ack and a tester ok. OK by me. Half the time when a -mm breaks for me, it's an obvious one-liner I can S-o-b: myself, the other half the time somebody else has a fix that I keep thinking I should stick *something* on once I confirm it's fixed. Do Linus/Andrew/major maintainers want Tested-By:'s for patches?
From: Andrew Morton [email blocked] Subject: Re: [patch 1/1] document Acked-by: Date: Fri, 1 Jun 2007 10:35:43 -0700 On Fri, 01 Jun 2007 13:27:25 -0400 [email blocked] wrote: > Do Linus/Andrew/major maintainers want Tested-By:'s for patches? I think it's very useful information to have. For a start, it tells you who has the hardware and knows how to build a kernel. So if you're making a change to a driver and want it tested, you can troll the file's changelog looking for people who might be able to help. A similar argument would apply to Reported-by:, which we possibly also need. But it's all perhaps a bit much for poor kernel developers to keep track of ;)
From: "Scott Preece" [email blocked] Subject: Re: [patch 1/1] document Acked-by: Date: Fri, 1 Jun 2007 14:37:54 -0500 On 6/1/07, Krzysztof Halasa [email blocked] wrote: > "John Anthony Kazos Jr." [email blocked] writes: > > > Indeed. Acked-by: implies authority, and only very few people should be > > able to do it. Namely, the only person who can ACK a patch is a person who > > could also NACK a patch and expect it to actually be dropped. If I think a > > patch is bad, I can say so, but as I have no authority, my statement would > > be taken on merit alone, whereas Linus or Andrew or such could just NACK > > it and move on without having to spew a blurb every time. > > Everyone always has some authority so everyone can ack or nack any > patch and I hope the action taken will always depend on merit > rather than person, especially if it's a technical issue and not > some style etc. thing. > -- > Krzysztof Halasa --- This is a question worth answering - is it rude to ack/nak a patch if you're not a maintainer or otherwise known-to-be-trusted, or is it OK for anyone to express an opinion? Andrew's patch text seems to imply that it's generally OK. scott
From: Andrew Morton [email blocked] Subject: Re: [patch 1/1] document Acked-by: Date: Fri, 1 Jun 2007 13:00:24 -0700 On Fri, 1 Jun 2007 14:37:54 -0500 "Scott Preece" [email blocked] wrote: > On 6/1/07, Krzysztof Halasa [email blocked] wrote: > > "John Anthony Kazos Jr." [email blocked] writes: > > > > > Indeed. Acked-by: implies authority, and only very few people should be > > > able to do it. Namely, the only person who can ACK a patch is a person who > > > could also NACK a patch and expect it to actually be dropped. If I think a > > > patch is bad, I can say so, but as I have no authority, my statement would > > > be taken on merit alone, whereas Linus or Andrew or such could just NACK > > > it and move on without having to spew a blurb every time. > > > > Everyone always has some authority so everyone can ack or nack any > > patch and I hope the action taken will always depend on merit > > rather than person, especially if it's a technical issue and not > > some style etc. thing. > > -- > > Krzysztof Halasa > --- > > This is a question worth answering - is it rude to ack/nak a patch if > you're not a maintainer or otherwise known-to-be-trusted, or is it OK > for anyone to express an opinion? Andrew's patch text seems to imply > that it's generally OK. > I think saying "ack" or "nack" is generally a bit rude, and not very useful. It's better to just provide constructive, detailed technical comments and from that it becomes pretty obvious to all parties whether or not the patch has a future. If you did properly provide that useful feedback then the "ack" or "nack" bit becomes redundant.
From: Andrew Morton [email blocked] Subject: Re: [patch 1/1] document Acked-by: Date: Fri, 1 Jun 2007 13:04:11 -0700 On Fri, 1 Jun 2007 13:00:24 -0700 Andrew Morton [email blocked] wrote: > On Fri, 1 Jun 2007 14:37:54 -0500 > "Scott Preece" [email blocked] wrote: > > > On 6/1/07, Krzysztof Halasa [email blocked] wrote: > > > "John Anthony Kazos Jr." [email blocked] writes: > > > > > > > Indeed. Acked-by: implies authority, and only very few people should be > > > > able to do it. Namely, the only person who can ACK a patch is a person who > > > > could also NACK a patch and expect it to actually be dropped. If I think a > > > > patch is bad, I can say so, but as I have no authority, my statement would > > > > be taken on merit alone, whereas Linus or Andrew or such could just NACK > > > > it and move on without having to spew a blurb every time. > > > > > > Everyone always has some authority so everyone can ack or nack any > > > patch and I hope the action taken will always depend on merit > > > rather than person, especially if it's a technical issue and not > > > some style etc. thing. > > > -- > > > Krzysztof Halasa > > --- > > > > This is a question worth answering - is it rude to ack/nak a patch if > > you're not a maintainer or otherwise known-to-be-trusted, or is it OK > > for anyone to express an opinion? Andrew's patch text seems to imply > > that it's generally OK. > > > > I think saying "ack" or "nack" is generally a bit rude, and not very > useful. err, make that "I think saying "nack" is generally a bit rude". An "ack" is inoffensive and useful. But frankly, I don't trust a simple "ack" much at all. It's the kernel equivalent of "whoa, kewl!" > It's better to just provide constructive, detailed technical comments and > from that it becomes pretty obvious to all parties whether or not the patch > has a future. If the ack comes with some material of this nature then it becomes more believeable that the Acker actually spent some time reading the code, and the ack becomes more interesting. It's quite common for experienced kernel developers to ack completely broken patches.

Related Links: