You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by Stack <st...@duboce.net> on 2018/08/21 03:08:36 UTC
[DISCUSS] Move to github flow (WAS subtopic of "Rough notes from dev
meetup, day after hbaseconasia 2018, saturday morning")
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
Re: [DISCUSS] Move to github flow (WAS subtopic of "Rough notes from
dev meetup, day after hbaseconasia 2018, saturday morning")
Posted by Stack <st...@duboce.net>.
On Mon, Aug 20, 2018 at 9:30 PM Sean Busbey <bu...@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
>
Re: [DISCUSS] Move to github flow (WAS subtopic of "Rough notes from
dev meetup, day after hbaseconasia 2018, saturday morning")
Posted by Misty Linville <mi...@apache.org>.
Is GitHub integration going to make patch review more palatable and
efficient for reviewers? Maybe we can increase our roster of regular
reviewers by using GitHub.
We can make a bot that looks for things in PR comment text. That way you
could add the JIRA number in a way the bit can pick it up and use it. Maybe
the bot could even attach the patch to the JIRA automatically on new
commits. Kubernetes uses something called Prow and something else called
Blunderbuss for this type of thing.
On Tue, Aug 21, 2018, 9:03 AM Josh Elser <el...@apache.org> wrote:
> 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
>
Re: [DISCUSS] Move to github flow (WAS subtopic of "Rough notes from
dev meetup, day after hbaseconasia 2018, saturday morning")
Posted by Reid Chan <re...@outlook.com>.
Is our goal to add an option(PRs) way for contributions or to replace the jira-patch way?
I supposed to be the former, but looks like the latter.
________________________________________
From: Sean Busbey <bu...@apache.org>
Sent: 22 August 2018 00:15:50
To: dev
Subject: Re: [DISCUSS] Move to github flow (WAS subtopic of "Rough notes from dev meetup, day after hbaseconasia 2018, saturday morning")
On Tue, Aug 21, 2018 at 11:03 AM, Josh Elser <el...@apache.org> wrote:
> 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.
>
We already do this today. As with review board and phabricator it
mostly depends on the reviewer(s) you have or want.
For example, when I work on significant doc changes now I put up a PR
because that's how Misty likes to do reviews.
That said, currently the folks who pay attention to outstanding PRs (I
think maybe me and Chia-Ping?) mostly focus on pushing folks to JIRA
and/or closing out unresponsive folks.
Re: [DISCUSS] Move to github flow (WAS subtopic of "Rough notes from
dev meetup, day after hbaseconasia 2018, saturday morning")
Posted by Andrew Purtell <ap...@apache.org>.
It is my impression as mainly a lurker on a bunch of GH based projects,
that there are a ton of younger software developers have no idea that other
options besides Github even exist. We can tell them to open a JIRA, god
forbid attach a patch to JIRA, but they'll shrug and forget about it. They
might not even have any idea what we are talking about. Generating a patch
file and handling it manually would be a (possibly unwelcome) revelation.
So I think if we want to take these kinds of contributions the onus on
doing everything other than interacting on the PR will be on the project
committers. I think ultimately every ASF project is going to have to
implement a pipeline for Github contributions, catering to the expectations
and limitations of contributors who have only interacted with open source
contribution via that platform, or otherwise we accept we've lost a whole
generation of contributors.
On Tue, Aug 21, 2018 at 9:31 AM Sean Busbey <bu...@apache.org> wrote:
> On Tue, Aug 21, 2018 at 11:24 AM, Josh Elser <el...@apache.org> wrote:
> > On 8/21/18 12:15 PM, Sean Busbey wrote:
> >>
> >> On Tue, Aug 21, 2018 at 11:03 AM, Josh Elser <el...@apache.org> wrote:
> >>>
> >>> 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.
> >>>
> >>
> >>
> >> We already do this today. As with review board and phabricator it
> >> mostly depends on the reviewer(s) you have or want.
> >>
> >> For example, when I work on significant doc changes now I put up a PR
> >> because that's how Misty likes to do reviews.
> >>
> >> That said, currently the folks who pay attention to outstanding PRs (I
> >> think maybe me and Chia-Ping?) mostly focus on pushing folks to JIRA
> >> and/or closing out unresponsive folks.
> >
> >
> > Oh, we do? I was under the impression that PRs were largely just told
> "File
> > a Jira and attach changes as a patch" for HBase. I guess I'm ignorant of
> > something that we already "support"?
>
>
> PRs that show up without a JIRA associated with them are told that we
> rely on JIRA for tracking issues and they'll need to create a JIRA
> issue before having a PR. I haven't crunched the actual numbers yet,
> but my intuition is that the majority of folks who are given this
> feedback never return and their issue is eventually closed as
> inactive.
>
> I believe the folks who currently do the work of posting feedback to
> PRs that don't have a JIRA also happen to prefer using JIRA for
> review, so we tend to direct folks to post their change there at the
> same time. Doing it as a second step after they've made a JIRA would
> probably kill off any remaining enthusiasm, but we could probable
> rephrase how we present that so that it's clearer that it's optional.
>
--
Best regards,
Andrew
Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
- A23, Crosstalk
Re: [DISCUSS] Move to github flow (WAS subtopic of "Rough notes from
dev meetup, day after hbaseconasia 2018, saturday morning")
Posted by Sean Busbey <bu...@apache.org>.
On Tue, Aug 21, 2018 at 11:24 AM, Josh Elser <el...@apache.org> wrote:
> On 8/21/18 12:15 PM, Sean Busbey wrote:
>>
>> On Tue, Aug 21, 2018 at 11:03 AM, Josh Elser <el...@apache.org> wrote:
>>>
>>> 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.
>>>
>>
>>
>> We already do this today. As with review board and phabricator it
>> mostly depends on the reviewer(s) you have or want.
>>
>> For example, when I work on significant doc changes now I put up a PR
>> because that's how Misty likes to do reviews.
>>
>> That said, currently the folks who pay attention to outstanding PRs (I
>> think maybe me and Chia-Ping?) mostly focus on pushing folks to JIRA
>> and/or closing out unresponsive folks.
>
>
> Oh, we do? I was under the impression that PRs were largely just told "File
> a Jira and attach changes as a patch" for HBase. I guess I'm ignorant of
> something that we already "support"?
PRs that show up without a JIRA associated with them are told that we
rely on JIRA for tracking issues and they'll need to create a JIRA
issue before having a PR. I haven't crunched the actual numbers yet,
but my intuition is that the majority of folks who are given this
feedback never return and their issue is eventually closed as
inactive.
I believe the folks who currently do the work of posting feedback to
PRs that don't have a JIRA also happen to prefer using JIRA for
review, so we tend to direct folks to post their change there at the
same time. Doing it as a second step after they've made a JIRA would
probably kill off any remaining enthusiasm, but we could probable
rephrase how we present that so that it's clearer that it's optional.
Re: [DISCUSS] Move to github flow (WAS subtopic of "Rough notes from
dev meetup, day after hbaseconasia 2018, saturday morning")
Posted by Josh Elser <el...@apache.org>.
On 8/21/18 12:15 PM, Sean Busbey wrote:
> On Tue, Aug 21, 2018 at 11:03 AM, Josh Elser <el...@apache.org> wrote:
>> 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.
>>
>
>
> We already do this today. As with review board and phabricator it
> mostly depends on the reviewer(s) you have or want.
>
> For example, when I work on significant doc changes now I put up a PR
> because that's how Misty likes to do reviews.
>
> That said, currently the folks who pay attention to outstanding PRs (I
> think maybe me and Chia-Ping?) mostly focus on pushing folks to JIRA
> and/or closing out unresponsive folks.
Oh, we do? I was under the impression that PRs were largely just told
"File a Jira and attach changes as a patch" for HBase. I guess I'm
ignorant of something that we already "support"?
Re: [DISCUSS] Move to github flow (WAS subtopic of "Rough notes from
dev meetup, day after hbaseconasia 2018, saturday morning")
Posted by Sean Busbey <bu...@apache.org>.
On Tue, Aug 21, 2018 at 11:03 AM, Josh Elser <el...@apache.org> wrote:
> 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.
>
We already do this today. As with review board and phabricator it
mostly depends on the reviewer(s) you have or want.
For example, when I work on significant doc changes now I put up a PR
because that's how Misty likes to do reviews.
That said, currently the folks who pay attention to outstanding PRs (I
think maybe me and Chia-Ping?) mostly focus on pushing folks to JIRA
and/or closing out unresponsive folks.
Re: [DISCUSS] Move to github flow (WAS subtopic of "Rough notes from
dev meetup, day after hbaseconasia 2018, saturday morning")
Posted by Josh Elser <el...@apache.org>.
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
Re: [DISCUSS] Move to github flow (WAS subtopic of "Rough notes from
dev meetup, day after hbaseconasia 2018, saturday morning")
Posted by Sean Busbey <bu...@apache.org>.
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.
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.
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.
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.
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
Re: [DISCUSS] Move to github flow (WAS subtopic of "Rough notes from
dev meetup, day after hbaseconasia 2018, saturday morning")
Posted by Yu Li <ca...@gmail.com>.
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 <el...@apache.org> wrote:
>
>
> On 9/2/18 12:00 PM, Sean Busbey wrote:
> > On Mon, Aug 20, 2018, 22:09 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
> >>
> >
> >
> > 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?
>
Re: [DISCUSS] Move to github flow (WAS subtopic of "Rough notes from
dev meetup, day after hbaseconasia 2018, saturday morning")
Posted by Josh Elser <el...@apache.org>.
Reading between the lines: so, this is just HBase convention to have a
Jira assignee mapping to the change's author, right? We're not concerned
about Jira assignee and its relation to ASF intellectual property
provenance.
If I'm getting this right, I think requiring a Jira account is
unnecessary and us coming up with a convention is fine _if_ we want to
be tracking the number of commits from authors that don't have Jira
accounts. But, I don't see why we would care about such a metric.
On 9/4/18 9:04 AM, Andrew Purtell wrote:
> 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 <bu...@apache.org> 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 <el...@apache.org> wrote:
>>>
>>>
>>>
>>>> On 9/2/18 12:00 PM, Sean Busbey wrote:
>>>>> On Mon, Aug 20, 2018, 22:09 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
>>>>>
>>>>
>>>>
>>>> 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?
Re: [DISCUSS] Move to github flow (WAS subtopic of "Rough notes from dev meetup, day after hbaseconasia 2018, saturday morning")
Posted by Andrew Purtell <an...@gmail.com>.
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 <bu...@apache.org> 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 <el...@apache.org> wrote:
>>
>>
>>
>>> On 9/2/18 12:00 PM, Sean Busbey wrote:
>>>> On Mon, Aug 20, 2018, 22:09 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
>>>>
>>>
>>>
>>> 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?
Re: [DISCUSS] Move to github flow (WAS subtopic of "Rough notes from
dev meetup, day after hbaseconasia 2018, saturday morning")
Posted by Sean Busbey <bu...@apache.org>.
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 <el...@apache.org> wrote:
>
>
>
> On 9/2/18 12:00 PM, Sean Busbey wrote:
> > On Mon, Aug 20, 2018, 22:09 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
> >>
> >
> >
> > 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?
Re: [DISCUSS] Move to github flow (WAS subtopic of "Rough notes from
dev meetup, day after hbaseconasia 2018, saturday morning")
Posted by Josh Elser <el...@apache.org>.
On 9/2/18 12:00 PM, Sean Busbey wrote:
> On Mon, Aug 20, 2018, 22:09 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
>>
>
>
> 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?
Re: [DISCUSS] Move to github flow (WAS subtopic of "Rough notes from
dev meetup, day after hbaseconasia 2018, saturday morning")
Posted by Sean Busbey <bu...@apache.org>.
The issue is specific to us being an ASF project. ASF project
repositories can either be set up with "Git WIP" or "Dual Master"[1].
Repositories that use "Git WIP" have their repo mirrored read-only to
GitHub. Repositories that use "Dual Master" have the canonical repo on
GitHub.
Our main project repo is a "Git WIP" one. That means we don't have
write access on GitHub, including merging or closing PRs. Thus the
only way we can close PRs on our main repo is to use the github
integrated commit message handling[2]. Which relies on pushing to the
master branch.
Since our main repo is used to create release artifacts we can only
have committers pushing to it, which precludes having a bot do so.
[1]:
"Dual Master" is also sometimes called "gitbox" because of where the
asf infra side of it lives.
http://git.apache.org/
[2]: https://help.github.com/articles/closing-issues-using-keywords/
On Tue, Sep 4, 2018 at 6:16 PM Misty Linville <mi...@apache.org> wrote:
>
> The code I posted above is an abstraction that is configured by YAML stuff
> like the following (where the test exists for closing PRs):
> https://github.com/kubernetes/test-infra/blob/a8cee5a60a2d9476341cf843867221a8bd18a3e8/config/jobs/kubernetes/test-infra/test-infra-periodics.yaml#L47
>
> I am not up on Go, but others pointed me there.
>
> On Tue, Sep 4, 2018 at 4:12 PM, Misty Linville <mi...@apache.org> wrote:
>
> > Here's the code to the bot: https://github.com/kubernetes/test-infra/tree/
> > master/robots/commenter
> >
> > On Tue, Sep 4, 2018 at 10:21 AM, Sean Busbey <bu...@apache.org> wrote:
> >
> >> Do you have a link to an instance of the bot you're talking about?
> >> On Tue, Sep 4, 2018 at 11:18 AM Misty Linville <mi...@apache.org> wrote:
> >> >
> >> > The below snip isn't true. Somehow CNCF has tooling that does it (it is
> >> a
> >> > bot called fejtabot). I can try to find out more about it if this is a
> >> > mechanism we are interested in pursuing.
> >> >
> >> > On Tue, Sep 4, 2018 at 7:08 AM, Sean Busbey <bu...@apache.org> wrote:
> >> > >
> >> > >
> >> > > We can't automate closing PRs because the only way to close a PR is by
> >> > > pushing a commit to our master branch and ASF policy doesn't allow for
> >> > > non-commiters pushing into the repository if the repository is used to
> >> > > make release artifacts.
> >> > >
> >> > >
> >>
> >
> >
Re: [DISCUSS] Move to github flow (WAS subtopic of "Rough notes from
dev meetup, day after hbaseconasia 2018, saturday morning")
Posted by Misty Linville <mi...@apache.org>.
The code I posted above is an abstraction that is configured by YAML stuff
like the following (where the test exists for closing PRs):
https://github.com/kubernetes/test-infra/blob/a8cee5a60a2d9476341cf843867221a8bd18a3e8/config/jobs/kubernetes/test-infra/test-infra-periodics.yaml#L47
I am not up on Go, but others pointed me there.
On Tue, Sep 4, 2018 at 4:12 PM, Misty Linville <mi...@apache.org> wrote:
> Here's the code to the bot: https://github.com/kubernetes/test-infra/tree/
> master/robots/commenter
>
> On Tue, Sep 4, 2018 at 10:21 AM, Sean Busbey <bu...@apache.org> wrote:
>
>> Do you have a link to an instance of the bot you're talking about?
>> On Tue, Sep 4, 2018 at 11:18 AM Misty Linville <mi...@apache.org> wrote:
>> >
>> > The below snip isn't true. Somehow CNCF has tooling that does it (it is
>> a
>> > bot called fejtabot). I can try to find out more about it if this is a
>> > mechanism we are interested in pursuing.
>> >
>> > On Tue, Sep 4, 2018 at 7:08 AM, Sean Busbey <bu...@apache.org> wrote:
>> > >
>> > >
>> > > We can't automate closing PRs because the only way to close a PR is by
>> > > pushing a commit to our master branch and ASF policy doesn't allow for
>> > > non-commiters pushing into the repository if the repository is used to
>> > > make release artifacts.
>> > >
>> > >
>>
>
>
Re: [DISCUSS] Move to github flow (WAS subtopic of "Rough notes from
dev meetup, day after hbaseconasia 2018, saturday morning")
Posted by Misty Linville <mi...@apache.org>.
Here's the code to the bot:
https://github.com/kubernetes/test-infra/tree/master/robots/commenter
On Tue, Sep 4, 2018 at 10:21 AM, Sean Busbey <bu...@apache.org> wrote:
> Do you have a link to an instance of the bot you're talking about?
> On Tue, Sep 4, 2018 at 11:18 AM Misty Linville <mi...@apache.org> wrote:
> >
> > The below snip isn't true. Somehow CNCF has tooling that does it (it is a
> > bot called fejtabot). I can try to find out more about it if this is a
> > mechanism we are interested in pursuing.
> >
> > On Tue, Sep 4, 2018 at 7:08 AM, Sean Busbey <bu...@apache.org> wrote:
> > >
> > >
> > > We can't automate closing PRs because the only way to close a PR is by
> > > pushing a commit to our master branch and ASF policy doesn't allow for
> > > non-commiters pushing into the repository if the repository is used to
> > > make release artifacts.
> > >
> > >
>
Re: [DISCUSS] Move to github flow (WAS subtopic of "Rough notes from
dev meetup, day after hbaseconasia 2018, saturday morning")
Posted by Andrew Purtell <ap...@apache.org>.
I use JIRA, good point.
On Tue, Sep 4, 2018 at 10:27 AM Mike Drob <md...@apache.org> wrote:
> Do folks use JIRA issues to account for work done when evaluating potential
> committers? Or is that generally gathered from git log? I don't think I
> have a preference either way but with multiple sources of "truth" we need
> to be aware of the possible inconsistencies.
>
> Mike
>
> On Tue, Sep 4, 2018 at 12:21 PM, Sean Busbey <bu...@apache.org> wrote:
>
> > Do you have a link to an instance of the bot you're talking about?
> > On Tue, Sep 4, 2018 at 11:18 AM Misty Linville <mi...@apache.org> wrote:
> > >
> > > The below snip isn't true. Somehow CNCF has tooling that does it (it
> is a
> > > bot called fejtabot). I can try to find out more about it if this is a
> > > mechanism we are interested in pursuing.
> > >
> > > On Tue, Sep 4, 2018 at 7:08 AM, Sean Busbey <bu...@apache.org> wrote:
> > > >
> > > >
> > > > We can't automate closing PRs because the only way to close a PR is
> by
> > > > pushing a commit to our master branch and ASF policy doesn't allow
> for
> > > > non-commiters pushing into the repository if the repository is used
> to
> > > > make release artifacts.
> > > >
> > > >
> >
>
--
Best regards,
Andrew
Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
- A23, Crosstalk
Re: [DISCUSS] Move to github flow (WAS subtopic of "Rough notes from
dev meetup, day after hbaseconasia 2018, saturday morning")
Posted by Mike Drob <md...@apache.org>.
Do folks use JIRA issues to account for work done when evaluating potential
committers? Or is that generally gathered from git log? I don't think I
have a preference either way but with multiple sources of "truth" we need
to be aware of the possible inconsistencies.
Mike
On Tue, Sep 4, 2018 at 12:21 PM, Sean Busbey <bu...@apache.org> wrote:
> Do you have a link to an instance of the bot you're talking about?
> On Tue, Sep 4, 2018 at 11:18 AM Misty Linville <mi...@apache.org> wrote:
> >
> > The below snip isn't true. Somehow CNCF has tooling that does it (it is a
> > bot called fejtabot). I can try to find out more about it if this is a
> > mechanism we are interested in pursuing.
> >
> > On Tue, Sep 4, 2018 at 7:08 AM, Sean Busbey <bu...@apache.org> wrote:
> > >
> > >
> > > We can't automate closing PRs because the only way to close a PR is by
> > > pushing a commit to our master branch and ASF policy doesn't allow for
> > > non-commiters pushing into the repository if the repository is used to
> > > make release artifacts.
> > >
> > >
>
Re: [DISCUSS] Move to github flow (WAS subtopic of "Rough notes from
dev meetup, day after hbaseconasia 2018, saturday morning")
Posted by Sean Busbey <bu...@apache.org>.
Do you have a link to an instance of the bot you're talking about?
On Tue, Sep 4, 2018 at 11:18 AM Misty Linville <mi...@apache.org> wrote:
>
> The below snip isn't true. Somehow CNCF has tooling that does it (it is a
> bot called fejtabot). I can try to find out more about it if this is a
> mechanism we are interested in pursuing.
>
> On Tue, Sep 4, 2018 at 7:08 AM, Sean Busbey <bu...@apache.org> wrote:
> >
> >
> > We can't automate closing PRs because the only way to close a PR is by
> > pushing a commit to our master branch and ASF policy doesn't allow for
> > non-commiters pushing into the repository if the repository is used to
> > make release artifacts.
> >
> >
Re: [DISCUSS] Move to github flow (WAS subtopic of "Rough notes from
dev meetup, day after hbaseconasia 2018, saturday morning")
Posted by Misty Linville <mi...@apache.org>.
The below snip isn't true. Somehow CNCF has tooling that does it (it is a
bot called fejtabot). I can try to find out more about it if this is a
mechanism we are interested in pursuing.
On Tue, Sep 4, 2018 at 7:08 AM, Sean Busbey <bu...@apache.org> wrote:
>
>
> We can't automate closing PRs because the only way to close a PR is by
> pushing a commit to our master branch and ASF policy doesn't allow for
> non-commiters pushing into the repository if the repository is used to
> make release artifacts.
>
>
Re: [DISCUSS] Move to github flow (WAS subtopic of "Rough notes from
dev meetup, day after hbaseconasia 2018, saturday morning")
Posted by Sean Busbey <bu...@apache.org>.
We could require ASF JIRA accounts, but it will definitely keep some
people from contributing. We have no way to measure what the fall off
is because we won't be able to tell those folks apart from those who
don't follow up on the PR for other reasons.
We can't automate closing PRs because the only way to close a PR is by
pushing a commit to our master branch and ASF policy doesn't allow for
non-commiters pushing into the repository if the repository is used to
make release artifacts.
This needn't be a pressing issue. We've had 90 PRs _ever_, so right
now we're only talking about ~2 per month.
On Mon, Sep 3, 2018 at 1:26 PM Misty Linville <mi...@apache.org> wrote:
>
> I like this suggestion, Yu, along with enthusiastic closing of GitHub PRs
> that don't follow the established procedures. Could we create an automated
> test for such compliance, like scanning the PR comments for specific text?
> CNCF projects use automation to parse a specific syntax in comments and set
> GitHub labels based on it. It could be as simple as /jira HBASE-foo, and
> automation could check that the issue actually exists and is open. The PR
> author could get a grace period of say a week before the PR is
> automatically closed, with warnings at regular intervals. Even if the PR is
> closed they can easily reopen it when they have created the issue. If they
> don't, we can't take their contribution, no matter how good it is.
>
> This approach front-loads the work of creating the automation, but reduces
> overall load of reviewers verifying compliance of the PR. It also enforces
> the policy with more consistency than relying on humans to do it.
>
> I suspect that ASF will eventually need to offer account holders to
> associate their account with a GitHub account, and that would alleviate
> some of this. There could even be a chain of trust by committing a
> cryptographically unique file generated by ASF processes into the user's
> GitHub account maybe (as a gist?) as part of that connection, or by using
> GitHub's authorization system.
>
> On Sun, Sep 2, 2018, 11:32 PM Yu Li <ca...@gmail.com> wrote:
>
> > Maybe we could follow some other projects' process? For example I could
> > find below lines of Flink's Code of Conduct
> > <https://flink.apache.org/contribute-code.html>, JFYI:
> >
> > *Before you start coding…*
> >
> > *…please make sure there is a Jira issue that corresponds to your
> > contribution. This is a general rule that the Flink community follows for
> > all code contributions, including bug fixes, improvements, or new features,
> > with an exception for trivial hot fixes. If you would like to fix a bug
> > that you found or if you would like to add a new feature or improvement to
> > Flink, please follow the File a bug report
> > <https://flink.apache.org/how-to-contribute.html#file-a-bug-report> or
> > Propose
> > an improvement or a new feature
> > <
> > https://flink.apache.org/how-to-contribute.html#propose-an-improvement-or-a-new-feature
> > >
> > guidelines
> > to open an issue in Flink’s Jira
> > <http://issues.apache.org/jira/browse/FLINK> before starting with the
> > implementation.*
> >
> > Best Regards,
> > Yu
> >
> >
> > On Mon, 3 Sep 2018 at 00:52, Andrew Purtell <an...@gmail.com>
> > wrote:
> >
> > > It's on us as committers to ensure Apache policies on code contribution
> > > are followed. I think that is the bottom line. Our identities are known
> > to
> > > Apache infrastructure and recorded in commit history. By committing we
> > are
> > > asserting we believe the provenance of the contribution is known and
> > > conforms to Apache policy. If you have concerns then don't commit.
> > > Otherwise, it is the same as it always was. Both of Apache's JIRA
> > instance
> > > and Github offer self service account signups without any sort of
> > identity
> > > verification, only verification that the email account provided is valid
> > > and under the control of the contributor.
> > >
> > > I think opening placeholder JIRAs as committers because we need it for
> > > tracking is fine. With my PMC hat on I'd like to wonder aloud what is the
> > > problem with signing up to Apache's JIRA instance. Any reason to be
> > > concerned? I take it you don't think so. I also take it you believe you
> > > know the identity of the contributor. Assuming you answer in the
> > > affirmative I don't see that we have any issues.
> > >
> > >
> > > > On Sep 2, 2018, at 9:00 AM, Sean Busbey <bu...@apache.org> wrote:
> > > >
> > > >> On Mon, Aug 20, 2018, 22:09 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
> > > >>
> > > >
> > > >
> > > > 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.
> > > >
> > > >>
> > >
> >
Re: [DISCUSS] Move to github flow (WAS subtopic of "Rough notes from
dev meetup, day after hbaseconasia 2018, saturday morning")
Posted by Misty Linville <mi...@apache.org>.
I like this suggestion, Yu, along with enthusiastic closing of GitHub PRs
that don't follow the established procedures. Could we create an automated
test for such compliance, like scanning the PR comments for specific text?
CNCF projects use automation to parse a specific syntax in comments and set
GitHub labels based on it. It could be as simple as /jira HBASE-foo, and
automation could check that the issue actually exists and is open. The PR
author could get a grace period of say a week before the PR is
automatically closed, with warnings at regular intervals. Even if the PR is
closed they can easily reopen it when they have created the issue. If they
don't, we can't take their contribution, no matter how good it is.
This approach front-loads the work of creating the automation, but reduces
overall load of reviewers verifying compliance of the PR. It also enforces
the policy with more consistency than relying on humans to do it.
I suspect that ASF will eventually need to offer account holders to
associate their account with a GitHub account, and that would alleviate
some of this. There could even be a chain of trust by committing a
cryptographically unique file generated by ASF processes into the user's
GitHub account maybe (as a gist?) as part of that connection, or by using
GitHub's authorization system.
On Sun, Sep 2, 2018, 11:32 PM Yu Li <ca...@gmail.com> wrote:
> Maybe we could follow some other projects' process? For example I could
> find below lines of Flink's Code of Conduct
> <https://flink.apache.org/contribute-code.html>, JFYI:
>
> *Before you start coding…*
>
> *…please make sure there is a Jira issue that corresponds to your
> contribution. This is a general rule that the Flink community follows for
> all code contributions, including bug fixes, improvements, or new features,
> with an exception for trivial hot fixes. If you would like to fix a bug
> that you found or if you would like to add a new feature or improvement to
> Flink, please follow the File a bug report
> <https://flink.apache.org/how-to-contribute.html#file-a-bug-report> or
> Propose
> an improvement or a new feature
> <
> https://flink.apache.org/how-to-contribute.html#propose-an-improvement-or-a-new-feature
> >
> guidelines
> to open an issue in Flink’s Jira
> <http://issues.apache.org/jira/browse/FLINK> before starting with the
> implementation.*
>
> Best Regards,
> Yu
>
>
> On Mon, 3 Sep 2018 at 00:52, Andrew Purtell <an...@gmail.com>
> wrote:
>
> > It's on us as committers to ensure Apache policies on code contribution
> > are followed. I think that is the bottom line. Our identities are known
> to
> > Apache infrastructure and recorded in commit history. By committing we
> are
> > asserting we believe the provenance of the contribution is known and
> > conforms to Apache policy. If you have concerns then don't commit.
> > Otherwise, it is the same as it always was. Both of Apache's JIRA
> instance
> > and Github offer self service account signups without any sort of
> identity
> > verification, only verification that the email account provided is valid
> > and under the control of the contributor.
> >
> > I think opening placeholder JIRAs as committers because we need it for
> > tracking is fine. With my PMC hat on I'd like to wonder aloud what is the
> > problem with signing up to Apache's JIRA instance. Any reason to be
> > concerned? I take it you don't think so. I also take it you believe you
> > know the identity of the contributor. Assuming you answer in the
> > affirmative I don't see that we have any issues.
> >
> >
> > > On Sep 2, 2018, at 9:00 AM, Sean Busbey <bu...@apache.org> wrote:
> > >
> > >> On Mon, Aug 20, 2018, 22:09 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
> > >>
> > >
> > >
> > > 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.
> > >
> > >>
> >
>
Re: [DISCUSS] Move to github flow (WAS subtopic of "Rough notes from
dev meetup, day after hbaseconasia 2018, saturday morning")
Posted by Yu Li <ca...@gmail.com>.
Maybe we could follow some other projects' process? For example I could
find below lines of Flink's Code of Conduct
<https://flink.apache.org/contribute-code.html>, JFYI:
*Before you start coding…*
*…please make sure there is a Jira issue that corresponds to your
contribution. This is a general rule that the Flink community follows for
all code contributions, including bug fixes, improvements, or new features,
with an exception for trivial hot fixes. If you would like to fix a bug
that you found or if you would like to add a new feature or improvement to
Flink, please follow the File a bug report
<https://flink.apache.org/how-to-contribute.html#file-a-bug-report> or Propose
an improvement or a new feature
<https://flink.apache.org/how-to-contribute.html#propose-an-improvement-or-a-new-feature>
guidelines
to open an issue in Flink’s Jira
<http://issues.apache.org/jira/browse/FLINK> before starting with the
implementation.*
Best Regards,
Yu
On Mon, 3 Sep 2018 at 00:52, Andrew Purtell <an...@gmail.com>
wrote:
> It's on us as committers to ensure Apache policies on code contribution
> are followed. I think that is the bottom line. Our identities are known to
> Apache infrastructure and recorded in commit history. By committing we are
> asserting we believe the provenance of the contribution is known and
> conforms to Apache policy. If you have concerns then don't commit.
> Otherwise, it is the same as it always was. Both of Apache's JIRA instance
> and Github offer self service account signups without any sort of identity
> verification, only verification that the email account provided is valid
> and under the control of the contributor.
>
> I think opening placeholder JIRAs as committers because we need it for
> tracking is fine. With my PMC hat on I'd like to wonder aloud what is the
> problem with signing up to Apache's JIRA instance. Any reason to be
> concerned? I take it you don't think so. I also take it you believe you
> know the identity of the contributor. Assuming you answer in the
> affirmative I don't see that we have any issues.
>
>
> > On Sep 2, 2018, at 9:00 AM, Sean Busbey <bu...@apache.org> wrote:
> >
> >> On Mon, Aug 20, 2018, 22:09 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
> >>
> >
> >
> > 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.
> >
> >>
>
Re: [DISCUSS] Move to github flow (WAS subtopic of "Rough notes from dev meetup, day after hbaseconasia 2018, saturday morning")
Posted by Andrew Purtell <an...@gmail.com>.
It's on us as committers to ensure Apache policies on code contribution are followed. I think that is the bottom line. Our identities are known to Apache infrastructure and recorded in commit history. By committing we are asserting we believe the provenance of the contribution is known and conforms to Apache policy. If you have concerns then don't commit. Otherwise, it is the same as it always was. Both of Apache's JIRA instance and Github offer self service account signups without any sort of identity verification, only verification that the email account provided is valid and under the control of the contributor.
I think opening placeholder JIRAs as committers because we need it for tracking is fine. With my PMC hat on I'd like to wonder aloud what is the problem with signing up to Apache's JIRA instance. Any reason to be concerned? I take it you don't think so. I also take it you believe you know the identity of the contributor. Assuming you answer in the affirmative I don't see that we have any issues.
> On Sep 2, 2018, at 9:00 AM, Sean Busbey <bu...@apache.org> wrote:
>
>> On Mon, Aug 20, 2018, 22:09 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
>>
>
>
> 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.
>
>>
Re: [DISCUSS] Move to github flow (WAS subtopic of "Rough notes from
dev meetup, day after hbaseconasia 2018, saturday morning")
Posted by Sean Busbey <bu...@apache.org>.
On Mon, Aug 20, 2018, 22:09 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
>
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.
>