hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yu Li <car...@gmail.com>
Subject Re: [DISCUSS] Move to github flow (WAS subtopic of "Rough notes from dev meetup, day after hbaseconasia 2018, saturday morning")
Date Tue, 04 Sep 2018 11:30:28 GMT
Just checked Flink document more carefully, it requires to file a JIRA but
no mention of creating account or assigning to oneself. However, I think
it's OK to require our contributor to create a JIRA account with the same
email address as github account - it requires no big effort and gives
people credit (telling who resolves the issue) - or at least we could make
it a strong recommendation.

Maybe I'm too old to guess the young generation's thought, but I believe
process won't be the obstacle of contributing if one really loves open
source, not to mention it's a one-time effort (smile)

Best Regards,
Yu


On Tue, 4 Sep 2018 at 10:43, Josh Elser <elserj@apache.org> wrote:

>
>
> On 9/2/18 12:00 PM, Sean Busbey wrote:
> > On Mon, Aug 20, 2018, 22:09 Stack <stack@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
> >>
> >
> >
> > 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?
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message