Summarizing my feelings: A first-step might be to inch towards some
middle ground where we allow code-review via PRs, but we still require a
Jira issue and a patch to trigger QA (and avoid authorship issues,
release note issues, etc) to "gate" the commit.
That gives us clear next steps:
1) Once QA works for PRs automatically, we can remove patch step
2) Once Yetus doc-maker can pull from GH, we can skip Jira issues
...
There's some precedence here with already allowing reviewboard and
phabricator (in my mind). I would be OK with doing code-review on GH and
would personally prefer it over all other tools at our disposal.
(some things inline too)
On 8/21/18 12:30 AM, Sean Busbey wrote:
A couple of other contribution concerns:
a) Yetus Precommit works with github PRs, but the ASF Jenkins admin
job that sends requests over to our job that runs the precommit tests
does not. It's a minor issue (in that collectively we know what has to
change), but someone will have to do the work.
Thanks, Sean. I expected something like this to be an immediate blocker.
b) We've just started getting better release notes together by using
Yetus Release Doc Maker. AFAIK it currently only works off of JIRA. I
know we haven't said anything about not having a JIRA associated with
changes just because we support github PRs, but it'll be around the
corner because we'll be duplicating work for those PRs. The two may
very well stay side-by-site for those who don't have/want GitHub
accounts, but if anything that makes the situation for "how do I
gather release notes" more complicated.
Agreed, that would be the next thing to come down the pipe.
Like point-A, I would guess that this is something we can fix by
expanding Yetus release-doc maker, but requires someone to do it.
c) Are more casual PRs a boon? In addition to HBase I spend time on an
open source project that relies exclusively on GitHub tooling and I
lurk on several others. One thing I've noticed is that while the
number of casual PRs is certainly higher they tend to be "drop off
PRs"; the engagement for follow up is much lower. Many folks who get
that PR up on GitHub then don't come back to address requests from
reviewers. We'll have to pick one or more of closing unresponsive PRs,
more proactively having committers "fix up" contributions, providing
more feedback as "follow-on work" instead of something that gets done
during the review. I personally would favor closing unresponsive PRs
because it has the least overhead for our already sparse reviewing
bandwidth.
That's a good point. I don't have strong feelings on how to interpret these.
d) All this said, we don't need to move to gitbox to accept PRs. We
can do anything today that we could do after moving to gitbox except
have committers merge the PR directly from the GitHub interface.
That's not easier for contributors, that's easier for committers. I'm
definitely not saying this is a bad thing. I do a non-trivial amount
of reviews from my phone and the github UI is definitely worlds
better.
Agreed. I think these are two separate issues.
On Mon, Aug 20, 2018 at 10:08 PM, Stack <st...@duboce.net> wrote:
This came up at the recent devs meeting: could we move to github flow
committing to Apache HBase? Do folks want this? If so, what would it take?
What would it look like?
The new gitbox repos at apache allow contribution back into apache via
github tooling: PRs can be merged into apache repos with a click of a
button, github-based comments can show as comments in apache JIRA. The new
hbase-operator-tools and hbase-connector repos are gitbox based. We can run
experiments there with fear of damage to the core.
The justification is that if our project supported PRs and contribution via
github, we could glean more contributors.
Below I repeat two follow-on comments taken from the "Rough notes from dev
meetup, day after hbaseconasia 2018, saturday morning" thread by way of a
kickstart:
From our Josh Elser:
This [supporting PRs] is something the PMC should take to heart. If we
are excluding
contributions because of how we choose accept them, we're limiting our own
growth. Do we have technical reasons (e.g. PreCommit) which we cannot
accept
PR's or is it just because "we do patches because we do patches"?
By our Sean:
"I don't want to bog down this thread, but there are a ton of
unanswered questions for allowing github PRs.
"The biggest one for me is that JIRA is currently our best hope for an
authoritative place for authorship information. If we're taking PRs
from folks who have GitHub accounts but find ASF JIRA accounts too
burdensome, what are we putting for the author in JIRA? Am I going to
have to look in JIRA before a certain date and in Git after? Or in Git
only if JIRA is set to some "HBase Contributor from GitHub" account?"
Thanks,
St.Ack
