To revert or not to revert

[Stefan Bader]

On 11/12/2010 11:18 AM, Jeremy Kerr wrote:
> [sorry about the resend; original was from the wrong account...]
> 
> 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.
> 

Though it does not ultimately matter what I think, I cannot resist to reply. ;-P
>From my point of view having things mentioned serves much more the collective
memory than it is confusing. That way you know exactly from looking at the log
of master that there has been an upload with those patches and they got reverted
because. Sure you can do that tagging but then one (/me) has to remember tags
and maybe there were multiple rounds of reverts and I forget one.
But I can see this is probably personal taste and working with a proposed branch
that gets rebased until its ok could be some option. It just seemed to work out
better for me to have a master branch tag not only reflects the state but also
some history and processing records.
Whatever solution we end up with, one other thing that should be possible with
that is to queue up the next round of patches that have been submitted for sru
while the porposed cycle is running. But I think this works with both ways.

-Stefan

> Cheers,
> 
> 
> Jeremy
>