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