Author/contributor information will be in the commit log. It doesnt matter if assigned on JIRA or not. We can update documentation for committers to make it clear proper attribution via commit metadata (either git author field or name in parenthesis at tail of summary line) is expected.
All we currently require from JIRA is that an issue for a commit exists, the identifier matches what was specified in the commit, the fix versions correctly cover the code lines where the change was committed, and the state reflects commit state (resolved when committed). This is so when RMs use the JIRA changelog for the release the information is accurate. > On Sep 4, 2018, at 7:00 AM, Sean Busbey <[email protected]> wrote: > > As a project we haven't always been diligent on JIRA fields. If > "Unassigned" means "you need to look at the git author" then there's > no way to differentiate that from "someone forgot to assign the JIRA". >> On Mon, Sep 3, 2018 at 9:43 PM Josh Elser <[email protected]> wrote: >> >> >> >>> On 9/2/18 12:00 PM, Sean Busbey wrote: >>>> On Mon, Aug 20, 2018, 22:09 Stack <[email protected]> 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 >>>> >>> >>> >>> Hey folks, >>> >>> This authorship bit might be coming up now. There's a PR for an existing >>> JIRA issue that I'd like to accept, but AFAICT the PR author doesn't have a >>> JIRA account. >>> >>> I've asked them about it. If they don't have an account and don't want to >>> make one, I suppose I'll make a placeholder JIRA account and send the >>> details to the PMC, unless someone objects. >>> >>> I'm not happy about the bifrucation of authorship information but I don't >>> see how forcing JIRA account creation could possibly be sustainable. >> >> Maybe I'm missing something, but what does an "empty" Jira account just >> to assign a Jira issue to actually get us over "Unassigned"? To Andrew's >> point about the committer ensuring IP provenance for changes hitting the >> repo to satisfy ASF requirements, I think that's orthogonal to having a >> Jira name tied to it, right? >> >> Maybe I'm missing something though?
