linux-kernel - Re: [patch] pci: pci_enable_device

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 02 Feb 2008 12:33:33 -0500
From:	Jeff Garzik <jeff@...zik.org>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Greg KH <gregkh@...e.de>, Linus Torvalds <torvalds@...l.org>,
	Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org,
	linux-pci@...ey.karlin.mff.cuni.cz,
	pcihpd-discuss@...ts.sourceforge.net,
	linux-scsi <linux-scsi@...r.kernel.org>,
	James Bottomley <James.Bottomley@...senPartnership.com>
Subject: Re: [patch] pci: pci_enable_device_bars() fix

Ingo Molnar wrote:
> it would have been totally appropriate for me to just send a mail to 
> lkml with the proper subject line about the breakage. (I might even have 
> decided to stay completely silent about the issue and fix it for my own 
> build, letting you guys figure it out.)

Oh come on...   You are smart enough to know to at least CC the driver 
maintainer, the key POC who should be aware of breakage of their driver. 
  That is a standard courtesy.

> ( And as this was spent from my family's weekend time and i had no time
>   and no interest to dig any further than to figure out the "first hop"
>   of the change that broke the build, and the parties who initiated that
>   hop. I'm in fact surprised that your and James's answer to my
>   bugreport is hostility. )

I'm sorry you read "would be nice" as hostility.

> So i find your suggestion that i should have added more people to the 
> Cc: line unfair on several levels.

As I noted, it is an obvious courtesy to CC the driver maintainer, at 
the very least.

_Especially_ when it is a change that requires some knowledge of the 
hardware, as was this case.

>> This set of changes seemed like 50% guesswork to me, without 
>> consulting the authors :( And unlike many changes, you actually have 
>> to know the hardware [or get clues from surrounding code] to make the 
>> change.
> 
> you mean the whole set of changes?

The whole set of changes, yes, not just yours.

> but ... i guess next time i'll think twice before sending any bugreports 
> about or related to the SCSI code anywhere, unless they become really 
> annoying. Who needs this hassle?

The fact is, each larger subsystem (net, scsi, ata I know) has several 
vendor contacts and driver maintainers who for various reasons prefer a 
more focused -- and often less hostile -- mailing list to LKML.

I have a hard enough time as it is, trying to convince hardware vendors 
to work with us, that we are not all assholes.

How about respecting the preferences of certain segments of a very large 
community, even when they differ from your own?  We have a 
community-accepted method of expressing these preferences, the 
MAINTAINERS file.

IMO, standard practice should be:

* To or CC: driver maintainer mentioned in MAINTAINERS (if any)
* CC: LKML, any list mentioned in MAINTAINERS

So, how about CC'ing the targets that have nicely requested to be CC'd?

	Jeff

--
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/