[DISCUSS] move to gitbox

Discussion:

Sean Busbey

2018-12-07 17:03:33 UTC

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.

Misty Linville

2018-12-07 17:13:33 UTC

Permalink

+1 What needs to happen next?

Post by Sean Busbey
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.

Sean Busbey

2018-12-08 02:25:13 UTC

Permalink

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

Post by Misty Linville
+1 What needs to happen next?

Andrew Purtell

2018-12-07 17:23:20 UTC

Permalink

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.

Post by Sean Busbey
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.

Andrew Purtell

2018-12-07 18:03:20 UTC

Permalink

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?

Post by Andrew Purtell
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.

Post by Sean Busbey
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.

Post by Sean Busbey
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?

Post by Sean Busbey
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

Stack

2018-12-07 17:59:48 UTC

Permalink

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

Sean Busbey

2018-12-08 02:23:05 UTC

Permalink

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)