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