[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20070601130411.218009d5.akpm@linux-foundation.org>
Date: Fri, 1 Jun 2007 13:04:11 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: "Scott Preece" <sepreece@...il.com>,
"Krzysztof Halasa" <khc@...waw.pl>,
"John Anthony Kazos Jr." <jakj@...-k-j.com>,
"H. Peter Anvin" <hpa@...or.com>, Valdis.Kletnieks@...edu,
linux-kernel@...r.kernel.org
Subject: Re: [patch 1/1] document Acked-by:
On Fri, 1 Jun 2007 13:00:24 -0700
Andrew Morton <akpm@...ux-foundation.org> wrote:
> On Fri, 1 Jun 2007 14:37:54 -0500
> "Scott Preece" <sepreece@...il.com> wrote:
>
> > On 6/1/07, Krzysztof Halasa <khc@...waw.pl> wrote:
> > > "John Anthony Kazos Jr." <jakj@...-k-j.com> 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists