OK, now we have the yetus set up for GitHub PR, and I've tried to use GitHub PR to process several issues. For example HBASE-22174, Sean Busbey approved on the PR, and I used the GitHub PR to commit to master, and then cherry-picked the commit to other branches, and committed them using command line. Worked pretty fine. The only problem is that I accidentally clicked the default merge button and created a merge commit in the commit history...
So I'm +1 on only allowing rebase merging, for squash merging, it is not a big deal to let the author squash the commits before merging. And at least, let's disable the default 'Create a Merge Commit' option... Thanks. Sean Busbey <[email protected]> 于2019年1月10日周四 上午2:03写道： > sure thing. let me draft it up now. > > On Wed, Jan 9, 2019 at 11:29 AM Andrew Purtell <[email protected]> > wrote: > > > According to the ticket the main repo and third-party repo have been > > migrated. We are just waiting on site. > > > > I'd appreciate it if we can send out that email now, because I'd like to > > continue commiting toward 1.5.0. At least, a pointer to docs on how the > > integration functions and the steps a committer needs to take to push and > > pull changes would be appreciated. > > > > > > > On Jan 9, 2019, at 8:56 AM, Sean Busbey <[email protected]> wrote: > > > > > > I filed a ticket with INFRA: > > > > > > https://issues.apache.org/jira/browse/INFRA-17597 > > > > > > The actual transition is supposed to only take a few minutes. Once it's > > done we should send a NOTICE email to dev@hbase summarizing what has > > changed and what folks will need to do different. > > > > > > > > > > > >> On 2019/01/08 19:07:30, Peter Somogyi <[email protected]> wrote: > > >> I believe we reached consensus to migrate our remaining repositories > to > > >> GitBox before the mandatory migration which will happen on 7th of > > February. > > >> Apart from 'hbase' we still have 'hbase-site' and 'hbase-thirdparty' > > >> repositories that also require the same migration process. > > >> > > >> From users' point of view they could still use git:// > > >> git.apache.org/hbase.git for read only access, only committers need > to > > >> change the remote URL to the GitBox one. Jenkins jobs are already > using > > the > > >> GitHub URL for cloning the repository and I created a patch for the > > >> documentation and website changes in HBASE-21685 that we can merge > after > > >> the process is competed. > > >> > > >> There's still outstanding work to do before we have good guidelines on > > >> accepting pull requests on GitHub, but the GitBox migration doesn't > > require > > >> our committers to start working with PRs in a different way. > > >> > > >> If there is no disagreement I'd kindly ask one of the PMC members to > > reach > > >> out to INFRA to perform the migration. > > >> > > >> Thanks, > > >> Peter > > >> > > >> On Sun, Dec 9, 2018 at 12:56 AM Andrew Purtell < > > [email protected]> > > >> wrote: > > >> > > >>> Sounds good to me except squash merge at commit of PR shouldn’t be an > > >>> option it should be required except for good reason (and I don’t know > > what > > >>> that would be ) > > >>> > > >>>>> On Dec 8, 2018, at 3:28 PM, Stack <[email protected]> wrote: > > >>>>> > > >>>>> On Fri, Dec 7, 2018 at 6:23 PM Sean Busbey <[email protected]> > > wrote: > > >>>>> > > >>>>> The move to gitbox doesn't require us to only accept github PRs. > > Given > > >>>>> the current rate of contributions via patches on JIRA vs GitHub > PRs, > > I > > >>>>> wouldn't want to push for that now. > > >>>>> > > >>>>> The change does make it easier for us to start encouraging PR > > >>>>> submissions, because committers will be able to directly merge from > > >>>>> the GitHub UI. > > >>>>> > > >>>>> I'd recommend we try to keep this as a small incremental change. > That > > >>>>> would mean: > > >>>>> > > >>>>> * committers ensure there's an associated JIRA for release note and > > >>>>> precommit checks (that can be just by pinging the contributor to go > > >>>>> make one) > > >>>>> * backports are still handled by the committer if they're simple > and > > >>>>> the contributor if there's a problem. I think saying "open a new PR > > to > > >>>>> backport to branch FOO" is perfectly reasonable since it's > analogous > > >>>>> to when we ask contributors to attach a branch specific patch. > > >>>>> * committers ensure the pushed commit has a message that follows > our > > >>>>> current practice (which would mean looking out for the "helpful" > > >>>>> subject wrapping) > > >>>>> * Squash merge is an option when the committer goes to accept the > PR. > > >>>>> the contributor is free to either push additional commits or squash > > on > > >>>>> their branch when working through reviews, I don't think we need to > > >>>>> weigh in on how contributors choose which of those works best for > > >>>>> them. > > >>>>> > > >>>>> That way we can also incrementally improve how well we handle PR > > >>>>> submissions by better documenting expectations and building up > > >>>>> additional tooling (e.g. having our precommit feedback go directly > to > > >>>>> the PR instead of being tied to a JIRA) > > >>>>> > > >>>> > > >>>> This seems reasonable to me. Andrew's strawman would be too radical > a > > >>>> change. > > >>>> Thanks, > > >>>> S > > >>>> > > >>>> > > >>>>>>> On Fri, Dec 7, 2018 at 12:09 PM Stack <[email protected]> wrote: > > >>>>>>> > > >>>>>>> On Fri, Dec 7, 2018 at 9:03 AM Sean Busbey <[email protected]> > > wrote: > > >>>>>>> > > >>>>>>> Hi folks! > > >>>>>>> > > >>>>>>> Per the email from infra "[NOTICE] Mandatory relocation of Apache > > git > > >>>>>>> repositories on git-wip-us.apache.org" ( > https://s.apache.org/0sfe > > ) > > >>>>> it > > >>>>>>> looks like the future of interacting directly with PRs is coming > > >>> sooner > > >>>>>>> rather than later. > > >>>>>>> > > >>>>>>> I think we should move to gitbox ASAP rather than wait for the > > crunch. > > >>>>> If > > >>>>>>> we hit a rough spot we're more likely to get some help when > things > > >>>>> aren't > > >>>>>>> busy. Maybe we wait until our open RCs close so that folks that > > need > > >>>>> to tag > > >>>>>>> those releases don't need to update their workflow first? > > >>>>>>> > > >>>>>>> Presuming everyone still agrees that we get value out of JIRA, I > > think > > >>>>> we > > >>>>>>> need update our committer guidelines to expressly remind folks to > > >>>>> check on > > >>>>>>> things like commit messages before merging PRs, as well as to > > ensure > > >>>>> folks > > >>>>>>> use the "squash and merge" option to keep the git history less > > >>>>> complicated. > > >>>>>>> Probably a good time to add text about the importance of > > backporting, > > >>>>> since > > >>>>>>> there isn't a github UI for doing that. > > >>>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Sounds good. > > >>>>>> > > >>>>>> Use this thread to list what needs documentation? (Agree with the > > "Need > > >>>>> to > > >>>>>> sort all of this out and provide clarity now before a switch > over." > > >>> from > > >>>>>> Andrew). > > >>>>>> > > >>>>>> What should the commit be like? Should be like now? What about > that > > >>> ugly > > >>>>>> bleed that happens when the first line is too long and gets dumped > > into > > >>>>> the > > >>>>>> textbox below ... which then becomes the log IIRC. > > >>>>>> > > >>>>>> When do we do the squash merge? Is that the committer who does > this > > >>> after > > >>>>>> rounds of review? > > >>>>>> > > >>>>>> I like Andrew's list. > > >>>>>> > > >>>>>> On the 'You can't fix a branch-1 issue where the code is different > > in > > >>>>>> branch-2 and up by opening a PR against master', this is a prob. > at > > >>> least > > >>>>>> with our current 'process'. We don't do a JIRA per push because it > > is > > >>>>> just > > >>>>>> a bunch of busy work. Do we have to do this now (any > alternatives?) > > >>>>>> > > >>>>>> Thanks for starting this up Sean, > > >>>>>> S > > >>>>> > > >>> > > >> > > >
