On Fri, 2014-04-11 at 12:18 -0700, Luis R. Rodriguez wrote: > On my current not published commit in which I've axed out all older > kernels its allowed me to rip out all the patches which were not split > up atomically and reshuffle and order every single series we have into > the new 4-digit form which implies they are atomically well split. > This can enable us to push for clean architecture on patches moving > forward. I don't think the 4-digit vs. 2/3 digit thing was ever really an indicator, but I do see that there are a whole bunch of patches, particularly for Atheros ethernet drivers (!!) for old kernels. Maybe a better compromise would be to bump those up with the dependencies file and keep the compat/compat-*.c code around for others, i.e. selectively reduce just the patches by bumping single driver dependencies? > I think this makes sense if we had an easy way to break things out as > optional right now but we don't, and given that some older patches > weren't really atomic (consider bluetooth for pre 3.0) I haven't looked at Bluetooth, but I wasn't really suggesting that we make the patches optional - that's never going to work. Again, like I said above, what we could potentially do is look through the pain areas (aka big patches) and reduce those by bumping single drivers/subsystems up in kernel version, instead of a wholesale bump. As far as 802.11 wireless is concerned, for example, I think the patches are actually relatively small for the older kernels. > Let's also consider now the > gains of being able to help persuade folks to upgrade if we also > embrace a sensible policy for what kernels we support. One of my goals > is to grow backports with more drivers and new options (in-kernel > support) but if backports can also be used as a carrot to help with > moving the ecosystem forward, I think its a strong element to > consider. So there are two gains here: helping us clean up things, and > setting up a sensible policy that aligns with kernel.org releases / > maintenance cycles. I'm not a big fan of politicising technical projects. We're mostly all here to get problems solved, and most of us push for better solutions, but usually what happens when we try to enforce better solutions technically is that we just get to maintain the workarounds outside the community, which makes it more effort for everybody... johannes -- To unsubscribe from this list: send the line "unsubscribe backports" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
