linux-kernel - Re: 3.5 stable compat-wireless

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:	Thu, 5 Jul 2012 16:18:01 -0700
From:	"Luis R. Rodriguez" <rodrigue@....qualcomm.com>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	Sujith Manoharan <c_manoha@....qualcomm.com>,
	"Balasubramanian, Senthil Kumar" <senthilb@....qualcomm.com>,
	"Manoharan, Rajkumar" <rmanohar@....qualcomm.com>,
	qca-linux-team <qca-linux-team@...lcomm.com>,
	Imran Ansari <imran@....qualcomm.com>,
	linux-wireless@...r.kernel.org, linux-kernel@...r.kernel.org,
	sfr@...b.auug.org.au, hauke@...ke-m.de, ozancag@...il.com,
	pstew@...gle.com, warthog9@...nel.org, jrnieder@...il.com,
	ben@...adent.org.uk, akpm@...ux-foundation.org,
	linville@...driver.com
Subject: Re: 3.5 stable compat-wireless

On Thu, Jul 5, 2012 at 4:08 PM, Greg KH <gregkh@...uxfoundation.org> wrote:
> On Thu, Jul 05, 2012 at 12:08:01PM -0700, Luis R. Rodriguez wrote:
>>   * linux-crap.git: based on linux-next-pending.git and allows
>>     contributors to send pull requests of crap that is not *ready*
>>     to be sent properly upstream. Examples would be code we know
>>     we simply already know that is not dealing with proper architecture
>>     or style / etc. The drivers/staging/ allows vendors to post full
>>     crap drivers, this would enable us to merge crap patches but that
>>     some vendors might need / want.
>
> I really doubt this will work, look at the patches in some distros for
> examples of why.  I'm having a hard enough time with the LTSI project in
> conveying that "Yes, you can send patches to me for merging into the
> LSTI kernel, you still have to justify it, and work to get the patches
> then upstream, I'm not going to do your work for you."
>
> Having a random tree where these patches show up help no one except the
> original developer so that they can fire-and-forget, which is not what
> you want, unless you wish to take on the "get it cleaned up and merged
> upstream" task yourself, which you really don't want to.

Ah but that's the trick with the metrics. Kind of like with kernel
contribution statistics we should be able to show *who* is working
with *crap*, and see if the delta is reducing. Without this -- such
entities are just keeping the *crap* to themselves anyway, and in fact
given that there is no outlet they work on private outlets. I'd like
to not do the work for them but -- to enable that crap to become
public and for me to prod on with a stick to shrink crap but to also
understand it. The other thing about the technique here is that each
release is annotated to reflect *where* delta is pulled from.
Distributions / system integrators can then cringe if they are asked
to use releases with crap delta, or they may very well be OK with it.

Something similar had happened with hostapd -- if we have no outlet
for "crap" then the only option is to not make it public. This doesn't
get us anywhere. As much as I'd love assume we can live in a world
where no delta is required experience so far is showing there are some
*reasonable* justifications for some of these deltas. But without
enabling them -- we can't study them, or prod to correct them.

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