On Fri, Oct 30, 2015 at 1:59 PM, Colin P. McCabe <cmcc...@apache.org> wrote:
> 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. > > So this was only clarified this morning, but we'd be using GH only for code review, not for code integration. So committers still need to download the PR, squash it, update CHANGES, push. Agree if we go beyond this, it 100% needs to be in a VOTE. Even this probably should have been in a VOTE with a proposal spelling out all these details. 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? > > Strongly agree that we need documentation for all this. Some of my open questions are also still pending. We need to test precommit integration too. Owen, are you chasing all of this down? Do we need some JIRAs to track?
