3 ms·
> Can you make a recommendation of a process which doesn't involve cherry-pick commits (or more often patch-sets)? This is for LTS, Long Term Support. Why woul
by CalChris 7y ago
> Can you make a recommendation of a process which doesn't involve cherry-pick commits (or more often patch-sets)?
This is for LTS, Long Term Support. Why would the maintainers be cherry picking candidate patch sets at all? Shouldn't they wait for a release and back port from that? Regular release intervals are 8-10 weeks.
That would be my recommendation, backport only from releases. This is especially the case here because it was a security fix.
- SolarNet 7y agoBecause a significant portion of those changes will conflict, and one will have to go back to each commit that made the changes to figure out the intention of the change. Easier to back port each set of changes while knowing what the point of the changes are.
- cyphar 7y agoPatches have to be in Linus's tree before they land in -stable. That's been the policy for at least as long as I remember. Also, Greg does releases of -stable every week or two -- waiting 8 weeks for patches (that Linus has already merged) makes very little sense. Yes, fixup patches are something that need to be handled separately but Greg has always handled those properly (and good kernel devs use the Fixes: tags and always Cc: stable on those fixup patches). Not to mention you'd need to handle fixup patches even if you did depend on releases (if a bug was introduced in a released version it's usually fixed by the next -rc1 -- so waiting means the newest kernel is broken needlessly for 8 weeks).
- richardwhiuk 7y agoHow would you back-port from a release, apart from cherry-picking commits or patch-sets?