[DISCUSS] move to gitbox

[Sean Busbey <bu...@apache.org>]

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.

Re: [DISCUSS] move to gitbox

[Sean Busbey <bu...@apache.org>]

Once we can show a consensus position one of the PMC files an INFRA
jira and then they coordinate with us (but I don't know specifically
what that coordination looks like).
On Fri, Dec 7, 2018 at 11:13 AM Misty Linville <mi...@apache.org> wrote:
>
> +1 What needs to happen next?
>
> On Fri, Dec 7, 2018, 9:03 AM Sean Busbey <busbey@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.
> >
> >
> >
> >
> >

Re: [DISCUSS] move to gitbox

[Misty Linville <mi...@apache.org>]

+1 What needs to happen next?

On Fri, Dec 7, 2018, 9:03 AM Sean Busbey <busbey@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.
>
>
>
>
>

Re: [DISCUSS] move to gitbox

[Andrew Purtell <an...@gmail.com>]

In the interest of helping this discussion along, let me change this from
an open ended comment to a specific proposal.

What if we require a PR for every commit? No cherry picking. This would
mean that a change might need three or four, or possibly even five PRs, one
for each affected branch. The primary benefit is we fully commit to the
GitHub way of managing workflow. We can still do JIRAs but they become
independent of commit work. (They kind of are already, if you think about
it. A change is reviewed for master and then backported, and the backports
may or may not see review themselves, and may or may not be done on a
different JIRA, there's no consistency there.) This would have the
additional benefit of raising the visibility of changes going into
maintenance branches. Rather than have a committer possibly doing cherry
picks in the background there would be a nominal PR review cycle for
everything. Overall it raises our workload, though. Even if a committer or
PMC opts to ignore the additional PRs raised for backports there is still
some cognitive work needed to sort through the list of PRs or emails about
same and decide what to ignore. Would also require branch maintainers to be
responsive to gitbox at-mentions, though. Probably would also require
branch maintainers to drive the additional PRs for changes landing in their
respective branch(es).

What do you think?


On Fri, Dec 7, 2018 at 9:23 AM Andrew Purtell <an...@gmail.com>
wrote:

> We also need to discuss and document how to target specific code lines.
> You can't fix a branch-1 issue where the code is different in branch-2 and
> up by opening a PR against master (assuming this is the default branch). It
> seems obvious but is not. Occasionally a fix is relevant for all branches
> but needs three or four distinct patches due to differences among the code
> lines. In that situation do we require a PR for each distinct change? One
> for master, branch-2, and branch-1, and again for branch-1.2, per recent
> example?
>
> Squash merging is a must I think. Otherwise cherry picking changes from
> the branch that received the PR changes to other branches is unnecessary
> difficult and frankly life is too short. It is difficult enough to
> participate in this project already just given the challenges of having
> three major code lines and several more releasing branches.
>
> Or maybe we won't do cherry picks and instead do it by PR for every branch
> / commit?
>
> Need to sort all of this out and provide clarity now before a switch over.
>
> > On 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.
> >
> >
> >
> >
>


-- 
Best regards,
Andrew

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
   - A23, Crosstalk

Re: [DISCUSS] move to gitbox

[Andrew Purtell <an...@gmail.com>]

We also need to discuss and document how to target specific code lines. You can't fix a branch-1 issue where the code is different in branch-2 and up by opening a PR against master (assuming this is the default branch). It seems obvious but is not. Occasionally a fix is relevant for all branches but needs three or four distinct patches due to differences among the code lines. In that situation do we require a PR for each distinct change? One for master, branch-2, and branch-1, and again for branch-1.2, per recent example? 

Squash merging is a must I think. Otherwise cherry picking changes from the branch that received the PR changes to other branches is unnecessary difficult and frankly life is too short. It is difficult enough to participate in this project already just given the challenges of having three major code lines and several more releasing branches. 

Or maybe we won't do cherry picks and instead do it by PR for every branch / commit?

Need to sort all of this out and provide clarity now before a switch over. 

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

Re: [DISCUSS] move to gitbox

[Sean Busbey <bu...@apache.org>]

Today if you add a link to a PR on the main repo to a JIRA ticket and put
it in patch available status, yetus should properly recognize and use it
for testing. The results should go to JIRA like normal.

I don't think it's gotten much testing in our setup. (And it wouldn't work
on the operator tools or connectors repos because our precommit currently
only knows about the main repo.)

On Sat, Dec 8, 2018, 01:44 Peter Somogyi <psomogyi@apache.org wrote:

> How should we verify pull requests in the new workflow? I wouldn't like to
> force contributors to create a PR and also attach the same patch file to
> Jira to have it tested. In case the plan is to create PR-based precommit
> I'd recommend to test run it on hbase-connectors or hbase-operator tools
> gitbox repositories.
>
>
> On Sat, Dec 8, 2018 at 3:30 AM Sean Busbey <bu...@apache.org> wrote:
>
> > Yes I definitely agree. I think that'll take some committer practice
> > and I'll want to have a decent section in the ref guide to point folks
> > to. On the plus side, there's a step committers have to go through to
> > link their ASF ID to their GitHub profile before they can start
> > merging through the GitHub UI. So if we tell folks about how to do
> > that step at the same time as show them how to make sure they're
> > squash merging maybe we'll avoid some mistakes.
> > On Fri, Dec 7, 2018 at 8:26 PM Andrew Purtell <ap...@apache.org>
> wrote:
> > >
> > > However you want to best phrase it, squash merging for commit is a
> must,
> > I
> > > think. Depending on the contributor's style there could be 1 or 10
> > commits
> > > comprising the PR. Even more than one commit for a change encompassed
> by
> > a
> > > JIRA would make cherry picking between the branches unnecessarily
> > onerous.
> > > This is really the only thing I'd like to establish as very important.
> > >
> > >
> > > 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)
> > > > 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
> > > >
> > >
> > >
> > > --
> > > Best regards,
> > > Andrew
> > >
> > > Words like orphans lost among the crosstalk, meaning torn from truth's
> > > decrepit hands
> > >    - A23, Crosstalk
> >
>

Re: [DISCUSS] move to gitbox

[Peter Somogyi <ps...@apache.org>]

How should we verify pull requests in the new workflow? I wouldn't like to
force contributors to create a PR and also attach the same patch file to
Jira to have it tested. In case the plan is to create PR-based precommit
I'd recommend to test run it on hbase-connectors or hbase-operator tools
gitbox repositories.


On Sat, Dec 8, 2018 at 3:30 AM Sean Busbey <bu...@apache.org> wrote:

> Yes I definitely agree. I think that'll take some committer practice
> and I'll want to have a decent section in the ref guide to point folks
> to. On the plus side, there's a step committers have to go through to
> link their ASF ID to their GitHub profile before they can start
> merging through the GitHub UI. So if we tell folks about how to do
> that step at the same time as show them how to make sure they're
> squash merging maybe we'll avoid some mistakes.
> On Fri, Dec 7, 2018 at 8:26 PM Andrew Purtell <ap...@apache.org> wrote:
> >
> > However you want to best phrase it, squash merging for commit is a must,
> I
> > think. Depending on the contributor's style there could be 1 or 10
> commits
> > comprising the PR. Even more than one commit for a change encompassed by
> a
> > JIRA would make cherry picking between the branches unnecessarily
> onerous.
> > This is really the only thing I'd like to establish as very important.
> >
> >
> > 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)
> > > 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
> > >
> >
> >
> > --
> > Best regards,
> > Andrew
> >
> > Words like orphans lost among the crosstalk, meaning torn from truth's
> > decrepit hands
> >    - A23, Crosstalk
>

Re: [DISCUSS] move to gitbox

[Sean Busbey <bu...@apache.org>]

Yes I definitely agree. I think that'll take some committer practice
and I'll want to have a decent section in the ref guide to point folks
to. On the plus side, there's a step committers have to go through to
link their ASF ID to their GitHub profile before they can start
merging through the GitHub UI. So if we tell folks about how to do
that step at the same time as show them how to make sure they're
squash merging maybe we'll avoid some mistakes.
On Fri, Dec 7, 2018 at 8:26 PM Andrew Purtell <ap...@apache.org> wrote:
>
> However you want to best phrase it, squash merging for commit is a must, I
> think. Depending on the contributor's style there could be 1 or 10 commits
> comprising the PR. Even more than one commit for a change encompassed by a
> JIRA would make cherry picking between the branches unnecessarily onerous.
> This is really the only thing I'd like to establish as very important.
>
>
> 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)
> > 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
> >
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>    - A23, Crosstalk

Re: [DISCUSS] move to gitbox

[Andrew Purtell <ap...@apache.org>]

However you want to best phrase it, squash merging for commit is a must, I
think. Depending on the contributor's style there could be 1 or 10 commits
comprising the PR. Even more than one commit for a change encompassed by a
JIRA would make cherry picking between the branches unnecessarily onerous.
This is really the only thing I'd like to establish as very important.


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


-- 
Best regards,
Andrew

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
   - A23, Crosstalk

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

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

[Sean Busbey <bu...@apache.org>]

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

[Andrew Purtell <an...@gmail.com>]

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 <an...@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

[Sean Busbey <bu...@apache.org>]

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 <an...@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

[Peter Somogyi <ps...@apache.org>]

Created HBASE-21701 'Accept pull requests from contributors' and added to a
comment what was collected until now. Feel free to add more there!

On Wed, Jan 9, 2019 at 11:22 AM Tamas Penzes <ta...@cloudera.com.invalid>
wrote:

> +1 for rebase and merge.
>
> It is the most understandable merge strategy. Others can cause huge
> confusion when checking the history.
>
> On Wed, Jan 9, 2019, 00:19 Ankit Singhal <ankitsinghal59@gmail.com wrote:
>
> > Just sharing what other communities are thinking on some of the merging
> > strategies provided by github for pull requests:-
> >
> >
> https://lists.apache.org/thread.html/c41aef9a33548de8e543d01611e71316c1cd0b0d0a75fb583d609ae1@%3Cdev.calcite.apache.org%3E
> >
> > "default merge pull request" option:-
> > Affects the linear history of the commits , it will be hard to follow
> which
> > is commit recently.
> > https://help.github.com/articles/about-pull-request-merges/
> >
> > "Squash merge" option:-
> > Calcite community is considering of disabling the feature from Github and
> > delegating it to the author to squash all their commit before it can be
> > merged by the committer so that original author of the PR can be
> preserved
> > in the squashed commit.
> >
> > "rebase and merge" option:-
> > This is how most of the apache projects currently doing through git
> client,
> > It will preserves the author and linear history of the commit.(also
> tested
> > by calcite community and said on below blog)
> > https://blog.github.com/2016-09-26-rebase-and-merge-pull-requests/
> >
> > So , we may should consider disabling the ones which doesn't suit us to
> > avoid committers using them accidentally.
> >
> > Regards,
> > Ankit Singhal
> >
> >
> > On Tue, Jan 8, 2019 at 11:07 AM 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

[Tamas Penzes <ta...@cloudera.com.INVALID>]

+1 for rebase and merge.

It is the most understandable merge strategy. Others can cause huge
confusion when checking the history.

On Wed, Jan 9, 2019, 00:19 Ankit Singhal <ankitsinghal59@gmail.com wrote:

> Just sharing what other communities are thinking on some of the merging
> strategies provided by github for pull requests:-
>
> https://lists.apache.org/thread.html/c41aef9a33548de8e543d01611e71316c1cd0b0d0a75fb583d609ae1@%3Cdev.calcite.apache.org%3E
>
> "default merge pull request" option:-
> Affects the linear history of the commits , it will be hard to follow which
> is commit recently.
> https://help.github.com/articles/about-pull-request-merges/
>
> "Squash merge" option:-
> Calcite community is considering of disabling the feature from Github and
> delegating it to the author to squash all their commit before it can be
> merged by the committer so that original author of the PR can be preserved
> in the squashed commit.
>
> "rebase and merge" option:-
> This is how most of the apache projects currently doing through git client,
> It will preserves the author and linear history of the commit.(also tested
> by calcite community and said on below blog)
> https://blog.github.com/2016-09-26-rebase-and-merge-pull-requests/
>
> So , we may should consider disabling the ones which doesn't suit us to
> avoid committers using them accidentally.
>
> Regards,
> Ankit Singhal
>
>
> On Tue, Jan 8, 2019 at 11:07 AM 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

[Ankit Singhal <an...@gmail.com>]

Just sharing what other communities are thinking on some of the merging
strategies provided by github for pull requests:-
https://lists.apache.org/thread.html/c41aef9a33548de8e543d01611e71316c1cd0b0d0a75fb583d609ae1@%3Cdev.calcite.apache.org%3E

"default merge pull request" option:-
Affects the linear history of the commits , it will be hard to follow which
is commit recently.
https://help.github.com/articles/about-pull-request-merges/

"Squash merge" option:-
Calcite community is considering of disabling the feature from Github and
delegating it to the author to squash all their commit before it can be
merged by the committer so that original author of the PR can be preserved
in the squashed commit.

"rebase and merge" option:-
This is how most of the apache projects currently doing through git client,
It will preserves the author and linear history of the commit.(also tested
by calcite community and said on below blog)
https://blog.github.com/2016-09-26-rebase-and-merge-pull-requests/

So , we may should consider disabling the ones which doesn't suit us to
avoid committers using them accidentally.

Regards,
Ankit Singhal


On Tue, Jan 8, 2019 at 11:07 AM 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 <an...@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

[Peter Somogyi <ps...@apache.org>]

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 <an...@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

[Andrew Purtell <an...@gmail.com>]

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

[Stack <st...@duboce.net>]

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

[Sean Busbey <bu...@apache.org>]

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

[Stack <st...@duboce.net>]

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