> The coarse status granularity of GitHub's pull request is a non-starter for automated patch queue management and a gated trunk. Period. Solutions such as roundabout and hubcap must use hacks such as looking in review comments for one or more "lgtm"s to determine if a commit is approved to be merged. This is not a robust solution and is prone to errors.
I agree. Hubcap proposes to fix this course granularity. That's the whole point. Ttx has informed me that there are nuances to the merge process that I'm perhaps missing. I understand there are issues with cherry picking, etc that github does not excel at. I'd love to understand these requirements in greater depth. And, regarding how hubcap would be any more error prone/robust than any other solution, I have to plead ignorance,. Can you elaborate on these two points please? Thanks, -S PS> I think it's very impressive the work that has gone into gerrit/jenkins integration. But from the (admittedly limited) merges/reviews I've done so far it seems overly complex. But, don't confuse my ignorance of the requirements as a slight against the efforts thus far. And, I have to say, I'm certainly not a github/git fanboy. My personal preference is definitely in the bzr/lp house. I would expect any solution to be at least as good at that. This email may include confidential information. If you received it in error, please delete it. _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
