On Mon, Aug 20, 2018 at 9:30 PM Sean Busbey <bus...@apache.org> 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. > > Good to know. Going by the tone of the above, you don't see this as an insurmountable obstacle. > 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. > > The new yetus release notes maker saves RMs hours of wrangling and the yetus product is just superior all around. Lets not break this smoothing of the release process. Its good that we consider a possibly JIRA-less process because it'll be "just around the corner" after we have PR integration (Or contributors will be asking "What is JIRA?" as per Andrew's note). But do you think our not having an answer to the JIRA question precludes our moving forward per the Josh "stepped" suggestion? (I think I can guess the answer -- smile). > 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. > > Yeah. I've seen this. It'll be par up on the new course. Hopefully the grunt work will be heavily diluted by the new contrib source Andrew's note suggests. St.Ack > 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 >
