On Thu, Jul 5, 2012 at 4:08 PM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> 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-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
