To revert or not to revert

[Jeremy Kerr]

Hi Tim,

> Pursuant to the kernel verification cadence policy recently discussed at
> UDS, the question has arisen of how to manage changelogs and whether or
> not to revert un-verified patches, or just rebase them out of existence.

I think that the rebase option might be better; this means we have a cleaner 
git history and changelog. If the patch hasn't made it through to an -updates 
release, I see no point in mentioning it in the changelog, even if it does 
have a subsequent revert entry.

In fact, mentioning it in the changelog may cause some confusion, as there is 
an entry saying that the patch went in. We're relying on thorough examination 
to see that it was later removed. This will get more noticable when we get 
patches re-submitted for SRU.

If the reason for the revert approach is to keep the patches in the git 
history, a simple tagging scheme might suit, to mark each -proposed upload. 
The proposed upload tag may end up up differing from the eventual -update/-
security upload, so getting the rejected patches is just a:

 git log -p <proposed-upload-tag> ^<updates-upload-tag>

and no messing with the changelogs (to prevent bug updates) is required.

Cheers,


Jeremy