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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
