Re: [DISCUSS] move to gitbox

["张铎 (Duo Zhang)" <pa...@gmail.com>]

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 <bu...@apache.org> 于2019年1月10日周四 上午2:03写道：

> sure thing. let me draft it up now.
>
> On Wed, Jan 9, 2019 at 11:29 AM Andrew Purtell <an...@gmail.com>
> 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 <bu...@apache.org> 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 <ps...@apache.org> 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 <
> > andrew.purtell@gmail.com>
> > >> 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 <st...@duboce.net> wrote:
> > >>>>>
> > >>>>> On Fri, Dec 7, 2018 at 6:23 PM Sean Busbey <bu...@apache.org>
> > 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 <st...@duboce.net> wrote:
> > >>>>>>>
> > >>>>>>> On Fri, Dec 7, 2018 at 9:03 AM Sean Busbey <bu...@apache.org>
> > 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
> > >>>>>
> > >>>
> > >>
> >
>

Re: [DISCUSS] move to gitbox

[Josh Elser <el...@apache.org>]

+1

On 4/6/19 8:22 AM, 张铎(Duo Zhang) wrote:
> 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 <bu...@apache.org> 于2019年1月10日周四 上午2:03写道：
> 
>> sure thing. let me draft it up now.
>>
>> On Wed, Jan 9, 2019 at 11:29 AM Andrew Purtell <an...@gmail.com>
>> 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 <bu...@apache.org> 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 <ps...@apache.org> 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 <
>>> andrew.purtell@gmail.com>
>>>>> 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 <st...@duboce.net> wrote:
>>>>>>>>
>>>>>>>> On Fri, Dec 7, 2018 at 6:23 PM Sean Busbey <bu...@apache.org>
>>> 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 <st...@duboce.net> wrote:
>>>>>>>>>>
>>>>>>>>>> On Fri, Dec 7, 2018 at 9:03 AM Sean Busbey <bu...@apache.org>
>>> 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
>>>>>>>>
>>>>>>
>>>>>
>>>
>>
>