On Wed, Apr 26, 2017 at 01:40:33PM +0100, Daniel P. Berrange wrote:
On Wed, Apr 26, 2017 at 08:14:31AM -0400, John Ferlan wrote:
[...] # Snip some useful discussion
> What happens if one forgets or one consistently doesn't
provide the
> tags? Is their push privilege taken away? IOW, what's the penalty for
> not following the accepted community rule?
> Again, I'm not against this, but sometimes getting *any* commit message
> for a patch is a struggle for some! Adding tags could be torturous ;-)
Dealing with S-o-B is trivial, since it just means adding -s flag to
git. The other tags are more manual, but not that much work.
The reviewed-by tags serve two purposes - one they give an indication to
the subsystem maintainer that the code has a certain level of review and
thus might be ready for merging, and two they give a historic record of
who did what. In our model with much broader set of committers, I don't
think the reviewed-by gives much benefit, so it just becomes a record of
who did what - which is already something present in the mailing list.
Personally I'd just keep things simple and only require a S-o-B from the
patch author, and the person committing. If people want to add other
tags fine, but I certaily wouldn't enforce anything other than S-o-B
I concur with your view. (I didn't imply that the specific tag
mentioned in my email Subject ought to be 'enforced'.)
---
Is there any hurdle from adopting the S-o-b approach that you outlined
above? Or is it just that it involves getting a consensus-based
agreement among upstream contributors, and making the trivial adjustment
to the Git workflow like you indicated above, adding: '--signoff' flag
to `git commit`? (I guess it's the latter.)
Thanks.
--
/kashyap