Re: RFD: Kernel release numbering

Andrew Morton
2005-03-04T11:57:04Z

Alan Cox <alan@lxorguk.ukuu.org.uk> 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.