Alan Cox <[EMAIL PROTECTED]> wrote: > > 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.
I think you're assuming that 2.6.x.y will have larger scope than is intended. - 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/
