On Fri, Oct 30, 2015 at 10:20 AM, Andrew Wang <andrew.w...@cloudera.com> wrote:
> I'm trying to slow this discussion down so we can: > > a) Determine the problem(s) we're trying to solve > The problem is that many people like the github code review tools. Enabling the github integration does not mean that everyone has to use github. It is letting the people that want to use github to review patches do so. Furthermore, it means that github pull requests, which people were already creating, are appropriately mirrored to the Apache infrastructure (jira and email). > b) See how the proposed solutions meet this problem > The flood of +1's were made before a full proposal of what "enabling github > integration" means, which has only been really specified in Owen's most > recent email. > > Referring to a), the problems mentioned in this thread: > > 1) Better, easier review tool (Steve) > This is my main goal too. > 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. > 3) The backlog of PRs against our unused GH project (Owen) > This happens too. > > 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. > 2) not solved since the proposal is GH only as a review tool, not for > integration > > 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. > > 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. > * 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. > > 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 .. Owen > Best, > Andrew > > > On Fri, Oct 30, 2015 at 9:19 AM, Owen O'Malley <omal...@apache.org> wrote: > > > It seems like there is overwhelming support for enabling the github > > integration, so I went ahead and filed the infra ticket > > < > https://issues.apache.org/jira/servicedesk/agent/INFRA/issue/INFRA-10690 > > >. > > > > This is explicitly not changing the way that we commit on Hadoop and > > commits should be squashed and rebased rather than merged on to the > master > > branch. If you want to close a pull request with a commit, just add a > line > > at the end of the commit message that says: > > > > closes apache/hadoop#123 > > > > If someone else wants to setup gerrit, we can evaluate it. However, I am > > skeptical that it would be so much better than Github that it would be > > worth making people learn a new tool. > > > > Thanks, > > Owen > > >
