Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Add admin app #4067
May 16, 2017
I think being more strict here would be detrimental to our performance. Still a valid question though, maybe we should dedicate a separate issue to it. Would you like to create it?
I think your mentioned example is a bit different in that those were added to the branch via PR, not fiat, and that it stayed open with those commits for a full day prior to merge, but it's a valid point that those individual commits didn't explicitly get a second committer sign-off.
I feel like the approach we've taken with our 'new rules' is not one of flexibility, so far, and I don't think it'd have been detrimental to our performance for those changes you made to go in via PR to @guerler's branch. Maybe we formalize that that's how changes to PRs should be made, instead of direct commit, and go with that? That way there's at least explicit review or endorsement of changes (by someone) prior to merge.
I agree with @dannon, we should use the push to PR feature only if the original author is unresponsive (as an alternative to a new PR with cherry-picked commits). Another angle against this practice is that it may be surprising/annoying to find new commits on your personal branch.
Adding commits via PR to the PR branch shouldn't require another reviewer, it's equivalent to the original author making requested changes IMO, as long as they are approved by the original author.
@mvdbeek You explicitly allow people to push to your branch when creating the PR, if you do not want that, you can uncheck that option when creating PR.
This does not feel logically truthful. It is also happening in very non-equal positions where you as a committer have the merge and veto powers and the contributor often does not so they can be under pressure to merge your code they wouldn't write themselves in order to please you and save their contribution.
If you want to make this superformal then once you have a commit in the PR your vote does not count. I am against that approach though, I like the flexibility and I think we use it sparsely and efficiently.
Note that I can still e.g. send a patch to the contributor and ask them to incorporate it with their commit to circumvent even the superformal approach.
We just need to trust each other more I think, processes won't guarantee a responsible behavior.
Rereading https://github.com/galaxyproject/galaxy/blob/dev/doc/source/project/organization.rst#direct-commit-access, technically I don't think that this violates our rules because of how we've defined the 'pull request' as the driving object in question, with only the 'author of the pull request' being excluded from voting on it, though it still feels like it violates the spirit of them, to me.
The crux of the issue is that here was a change/commit to the core codebase committed without any oversight or review. Should we all just be committing directly to the core dev branch for 'minor' changes like typos, minor errors, and templating out language strings like this?