Open Stack

Yeah, pushing a patch following the patch going in for review is more what I was thinking. So, a patch that fixes the previous patch, not actually rewriting the patch.

Is it a problem for the commit to "come from" and be "signed off" by the automation itself?

It surfaces the cleanup patches as just cleanup patches. And in the very end of the ps, we squash the pr on merge anyway? If the user wants, they can also just flatten the PS themselves and it would automatically merge in the automation provided patches.

Thanks,
Kevin
________________________________________
From: Jeremy Stanley [fungi at yuggoth.org]
Sent: Tuesday, April 23, 2019 1:49 PM
To: openstack-discuss at lists.openstack.org
Subject: Re: The python black project.

On 2019-04-23 20:26:10 +0000 (+0000), Fox, Kevin M wrote:
[...]
> I usually prefer server side hooks as then I don't have to deploy
> all the developer tools all of the random repos I contribute to
> require all the time. If it can be made server side somehow, thats
> vastly easier to deal with by folks like me or other drive by
> contributors.

Server-side hooks are fine for rejecting a push (if somewhat
inflexible and hard to manage across projects, and in most ways
inferior to equivalent CI jobs), but you don't want them altering
commits as that invalidates any commit signing (in the git commit
-S/--gpg-sign sense, not the -s/--signoff sense) the original
committer may have performed.

> I'm thinking more along the line of, we have a bunch of gate
> blocking tests that ensure some amount of code quality going in.
> But what if we could take it to the next level and have those
> tests actually feed back quality enhancements too, not just saying
> no and without the developer to install extra tools?
[...]

The suggestion to have automation push a revision to a patch you
propose while it's still under review is an interesting one, though
it does bear some resemblance to the server-side hooks problem. The
commit which would be approved and merged at that point isn't
identified as yours. Some attempt could be made to have the
automation masquerade as your identity insofar as forging the
committer details to match the prior patch, but it wouldn't be able
to reproduce your cryptographic signature so *if* you're keen on
OpenPGP-signing your commits, you'll lose that when the auto-revised
version ends up merging instead of your original.
--
Jeremy Stanley