On Gwe, 2005-03-04 at 02:28, Andrew Morton wrote: > > I would disagree, and I suspect anyone else who has maintained a distro > > stable kernel would likewise. It needs one or more people who know who > > to ask about stuff, are careful, have a good grounding in bug spotting, > > races, common mistakes and know roughly how all the kernel works. > > Maintainers aren't very good at it in general and they don't see > > overlaps between areas very well. > > > That is all inappropriate activity for a 2.6.x.y tree as it is being > proposed. > > Am I right? All we're proposing here is a tree which has small fixups for > reasonably serious problems. Almost without exception it would consist of > backports.
Almost without exception maintainers will forget the backport (there are some notable exceptions). Almost without exception maintainers will not be aware that their backport fix clashes with another fix because that isn't their concern. Linus will try and sneak stuff in that is security but not mentioned which has to be dug out (because the bad guys read the patches too). And finally Linus throws the occasional gem into the backporting mix because he will (rightly) do the long term fix that rearranges a lot of code when the .x.y patch needs to be the ugly band aid. So for example Linus will happily changed remap_vm_area to fix a security bug by changing the API entirely and making it do some other things. Or in the case of the exec bug he did a fix that defaulted any missed fixes to unsafe. Fine for upstream where the goal is cleanness, bad for .x.y because the arch people hadn't caught up and did have remaining holes. You also have to review the dependancy tree for a backport and what was tested - so I skipped the NFS df fix as one example as it had never been tested standalone only on a pile of other NFS fixes. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
