I am -1 on the current GH stuff, just because I feel like there wasn't enough discussion, testing, and documentation of it. The initial proposal had no details and was implemented before any of the people who had had misgivings on the previous email thread had a chance to even see it.
It's a big change to totally change our commit workflow. Much bigger than something like merging a feature branch or making a release, both of which require votes. This kind of change should require an actual proposal and a VOTE thread. I would be +0 on GH if there was a concrete proposal addressing * How this going to interact with JIRA. For example, what is the new process once a bug has been identified? Is a JIRA required? How do we link JIRA and GH? Do we reject GH requests without a JIRA? * What will we update the HowToContribute page to say? * How will we deal with the merge commit problem? Will we have a tool to remove them? Can GH be configured to avoid them? Will we update tools on top (including in-house tools) to handle merge commits? * Will we have tooling to search GH pull requests? How do we prevent patches from new committers from falling through the cracks if they don't know about JIRA? Colin On Fri, Oct 30, 2015 at 11:57 AM, Sean Busbey <bus...@cloudera.com> wrote: > On Fri, Oct 30, 2015 at 1:22 PM, Allen Wittenauer <a...@altiscale.com> wrote: >> >>> * 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? >> >> >> I don’t know about the Jenkins-side of things (e.g., how does >> Jenkins trigger a build?). As far as Yetus is concerned, here’s the >> functionality that has been written: >> >> * Pull patches from Github by PR # >> * Comment on patches in Github, given credentials >> * Comment on specific lines in Github, given credentials >> * Test patches against the branch/repo that the pull request is >> against >> * GH<->JIRA intelligence such that if a PR mentions an issue as the >> leading text in the subject line or an issue mentions a PR in the comments, >> pull from github and put a comment in both places (again, given credentials) > > > Jenkins builds are all driven off of the "Precommit Admin" job that > does a JQL search for enabled projects with open patches: > > https://builds.apache.org/view/PreCommit%20Builds/job/PreCommit-Admin/ > > I believe with the current integration, that means we'll find an test > any github PRs that are mentioned in a jira ticket that is in > PATCH_AVAILABLE status. > > At some point we'll need an exemplar jenkins trigger job that just > activates on open PRs, at least for ASF projects. But no such job > exists now. > > > -- > Sean
