Re: RFD: Kernel release numbering

[Andrew Morton]

Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/