Re: [PATCH 1/2] Kconfig: Allow disabling of CONFIG_DEVPORT

[Mike Waychison]

On Fri, Jul 15, 2011 at 10:01 AM, Greg KH <gregkh@xxxxxxx> wrote:
> On Fri, Jul 15, 2011 at 09:45:20AM -0700, Mike Waychison wrote:
>> On Fri, Jul 15, 2011 at 8:19 AM, Greg KH <gregkh@xxxxxxx> wrote:
>> > On Fri, Jul 15, 2011 at 03:58:35PM +0100, Alan Cox wrote:
>> >> > But none of them are on the Signed-off-by: line area, right?
>> >>
>> >> We have a fair number of people using things like
>> >>
>> >> Fixes-bug: [URL]
>> >>
>> >>
>> >> Its useful public info, it makes it easier to grep
>> >
>> > That's fine, but that is not what was done here.  And those URLs had
>> > better be public as well.
>> >
>>
>> Greg, this is a bit ridiculous.  If adding a bug reference number to a
>> patch isn't used in lieu of a good patch description, I don't see how
>> this hurts anybody in the public.  You're only making it more
>> difficult for those who actually want to contribute to the public
>> sources.
>
> What?  Come on now, do you seriously want to start seeing _every_
> company put random things in the signed-off-by area depending on their
> internal development workflow that has _nothing_ to do with the kernel
> development community?
>

Considering the footer as a machine parseable audit trail, ya, I think
it's fair to extend the auditability to those who make the
contributions as a courtesy.

FWIW, we already use a _ton_ of footers for internal tracking of
changes as they go through code review, flow between rebased trees and
get merged into release trees.  I agree with you that that sort of
information isn't relevant to the usual LKML reader, and patches
posted to LKML coming from google.com don't publicize them as they
aren't very human readable either.

> You do realize just how many different companies contribute every year,
> right?
>
> The information in a git commit is for the developers of the kernel, the
> community, not for the individual companies that might contribute.

Why are you making a distinction?  The community members often *are*
individual companies.

>
> We need consistancy in commit logs, and by putting stuff like this in
> them, in the area that is parsed by tools, that don't fit any rhyme or
> reason, causes problems.  Look at the discussion that took place to just
> figure out how to properly reference email threads that result in a
> patch.  We worked it out, right?  But that was so we all can come to a
> common goal and understanding.

Did we?  I don't see it documented anywhere :(

>
> Unless you feel we should come up with something like:
>        Internal-reference-id: XXXXX
> and use a general tag like that for all companies, please don't put
> company-specific and internal references in a place where they will be
> commited to the public tree.

I'd be fine with something like "Internal-reference-id".

Really, I don't see what the problem with the format of the entry is,
I mean, it's prefixed with "Google" specifically so that doesn't clash
with other future tags.  If you feel that this needs to be into a
common tag that others can use, let's have that discussion.  I
honestly don't see what the big deal is though.

>
> Personally, I want to see the information in git commits to be useful
> for everyone, and not reference private information, as that helps no
> one except a very tiny minority of the community out, which, in my
> opinion, is very selfish of them.
>
> And yes, this means that if someone sees a reference to a private
> bugzilla url, then that should be fixed either by making that bug open,
> or removing that url from the git commit area.

The next time I'm on the stand trying to explain to a jury in federal
court why kernel developer X made change Y to Linux, I don't want to
have to explain that we can't find that information because keeping
the audit trail didn't align with your personal preferences.

Mike Waychison
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/