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 > > >> > > >
