> > > > 2) Better attribution of contributors with their GH id (Arpit) > > > > This doesn't happen very naturally other than the pull requests are > typically shown in their fork of the apache repo. > > It happens if we used PRs for integration, but yes I agree that it does not if GH is just used as a review tool.
> > > 3) The backlog of PRs against our unused GH project (Owen) > > > > This happens too. > > The backlog is from people who don't want to go through JIRA and just want to fork and PR on github. Enabling GH-as-code-review-tool is not going to help this community of developers. > > > > > Applying "use GH PRs as a review tool" to the above problems: > > > > 1) I think it has advantages, but as I said earlier, Github PRs really > are > > not designed for our rebase+squash workflow, since AFAIK it doesn't > support > > interdiffs. > > > > Yes, it does. Pushing to the branch that the pull request was created from > updates the pull request. > That's not interdiff support, which was my main point about differences in workflow. > > > > 3) not solved since all issues still need to start as a JIRA, or else the > > mirroring won't work. > > > > That isn't true. If you push an empty commit that tells the integration to > close pull requests, they are closed. We could clean up the current pull > requests now that the integration is there. > > Cleaning them up is good, but as I said above it doesn't help this community of users who filed these in the first place. That is, users who want to use GitHub but don't like JIRA. I also searched "disable pull requests" and found this, which could help with this issue: https://nopullrequests.appspot.com/ > > > > > I'd also ask the following unknown questions: > > > > * Is there a way to *disable* using PRs for integration? i.e. disable the > > ability to merge PRs? > > > > That is already disabled. > > Great, glad to hear it. That wasn't mentioned in the email thread or on the INFRA ticket, and the INFRA ticket mentions these integrations: Commit Comment, Create, Issue Comment, Issues, Pull Request, Pull Request Comment, and push, Push Are these the right set of permissions to disable integrating PRs? Namely, the "push" permissions look unnecessary. We should also disable GH issues since we don't want users filing issues there. > > > * Have we tried our precommit on PRs yet? Does it work for multiple > > branches? Is there a way to enforce rebase+squash vs. merge on the PR, > > since, per Allen, Yetus requires one commit to work? > > > > Allen said that it was either working or easy to make work. > > Great to hear, this was not mentioned on this email thread besides Allen saying multi-commit PRs are problematic. > > > > > This thread is barely 24 hours old, and I don't see why we're trying to > > move this fast on the issue. Let's discuss some alternatives (!) and > settle > > on the right solution. We also haven't even broached review alternatives > > like RB, Crucible, etc which were in the running last time this topic > came > > up. > > > > I'm sorry that I moved too fast. There are clearly a lot of people who want > to use it as a review tool and getting github integration enabled is easy. > Furthermore, it isn't exclusive. There will still be people uploading > patches on jira. This is about giving the contributors and committers the > ability to use a popular review tool > > I'm onboard with improved code review tools. It was not clear this proposal was for github *only* as a code review tool until about an hour ago. It also wasn't clear to a lot of the people who were +1ing based on the long-form comments. My one sticking point is that GH remains only a code review tool until a later discussion. So, no merging of PRs directly, and JIRAs come before PRs. If people want to revisit this, let's discuss in a thread that does not begin and end in 24 hours, and do a proper proposal and vote so there aren't ambiguities or open questions before things happen. Best, Andrew
