Github PRs without attached JIRA issue

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Github PRs without attached JIRA issue

Jan Høydahl / Cominvent
Hi,

We have some contributors that open GitHub PRs without also opening a JIRA and linking the two. Probably because they are used to that workflow from other projects and expect someone to have a look at the contribution. There is an email sent to the dev list, and sometimes it is noticed, other times the PR just falls through the cracks and is forgotten.

Here is a list of currently open PRs without a JIRA attached, 51 in total:

https://github.com/apache/lucene-solr/pulls?utf8=✓&q=is%3Apr+is%3Aopen+NOT+LUCENE+in%3Atitle+AND+NOT+SOLR+in%3Atitle+

How can we improve on the situation? I see a few alternatives:

A. Setup a bot with a GitHub WebHook that inspects the title and auto adds a comment if LUCENE or SOLR is missing
   https://developer.github.com/v3/activity/events/types/#pullrequestevent
B. Send the result of the above query to the dev@ list monthly for someone to jump in and interact
C. Add a GitHub Pull-Request Template https://help.github.com/en/articles/creating-a-pull-request-template-for-your-repository
   In there put some text about the requirement for a JIRA
D. Treat PRs as first-class issues, without the need for a shadow JIRA. In that case, we'd reference PRs in CHANGES too, e.g.:
   * #217: Fix bug foo
E. Migrate away from JIRA and use GitHub issues + PR instead. Some Apache projects do that already :)

Let the discussion begin :)

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Github PRs without attached JIRA issue

Cassandra Targett
Heh, here’s another idea I’ve had in my drafts folder for a while but thought if I suggest it I should be available to follow up on it and wasn’t sure if I’d have time to properly.

I actually started a pull request template and have a mostly complete version I could share (via a PR, I guess?). I don’t think it will 100% solve it, but it would greatly increase the number of issues that comply, for lack of a better term, with our processes/expectations for changes. In my draft I also included a short checklist to encourage people to make the patch for master, include tests with their patches, run precommit, and a few other things I thought might help new contributors understand what we need to get their patches reviewed faster.

Your D and E ideas are interesting. I worry about fragmenting where definitive info about changes is stored (D) - I think there is a lot of value in having a single system of record for the community.

I’d definitely be for exploring moving entirely to Github (E) - I think I said something along those lines in the lucene-solr Slack channel a few months ago - but have not spent much time figuring out all the downstream implications. I think we’d have to consider what we would gain vs what we would lose. I definitely don’t yet have a list, but I’m not initially against the idea.

Cassandra
On Jun 7, 2019, 5:53 AM -0500, Jan Høydahl <[hidden email]>, wrote:
Hi,

We have some contributors that open GitHub PRs without also opening a JIRA and linking the two. Probably because they are used to that workflow from other projects and expect someone to have a look at the contribution. There is an email sent to the dev list, and sometimes it is noticed, other times the PR just falls through the cracks and is forgotten.

Here is a list of currently open PRs without a JIRA attached, 51 in total:

https://github.com/apache/lucene-solr/pulls?utf8=✓&q=is%3Apr+is%3Aopen+NOT+LUCENE+in%3Atitle+AND+NOT+SOLR+in%3Atitle+

How can we improve on the situation? I see a few alternatives:

A. Setup a bot with a GitHub WebHook that inspects the title and auto adds a comment if LUCENE or SOLR is missing
https://developer.github.com/v3/activity/events/types/#pullrequestevent
B. Send the result of the above query to the dev@ list monthly for someone to jump in and interact
C. Add a GitHub Pull-Request Template https://help.github.com/en/articles/creating-a-pull-request-template-for-your-repository
In there put some text about the requirement for a JIRA
D. Treat PRs as first-class issues, without the need for a shadow JIRA. In that case, we'd reference PRs in CHANGES too, e.g.:
* #217: Fix bug foo
E. Migrate away from JIRA and use GitHub issues + PR instead. Some Apache projects do that already :)

Let the discussion begin :)

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Github PRs without attached JIRA issue

david.w.smiley@gmail.com
I think a PR template would be great.  Lets see yours Cassandra!

~ David Smiley
Apache Lucene/Solr Search Developer


On Fri, Jun 7, 2019 at 9:35 AM Cassandra Targett <[hidden email]> wrote:
Heh, here’s another idea I’ve had in my drafts folder for a while but thought if I suggest it I should be available to follow up on it and wasn’t sure if I’d have time to properly.

I actually started a pull request template and have a mostly complete version I could share (via a PR, I guess?). I don’t think it will 100% solve it, but it would greatly increase the number of issues that comply, for lack of a better term, with our processes/expectations for changes. In my draft I also included a short checklist to encourage people to make the patch for master, include tests with their patches, run precommit, and a few other things I thought might help new contributors understand what we need to get their patches reviewed faster.

Your D and E ideas are interesting. I worry about fragmenting where definitive info about changes is stored (D) - I think there is a lot of value in having a single system of record for the community.

I’d definitely be for exploring moving entirely to Github (E) - I think I said something along those lines in the lucene-solr Slack channel a few months ago - but have not spent much time figuring out all the downstream implications. I think we’d have to consider what we would gain vs what we would lose. I definitely don’t yet have a list, but I’m not initially against the idea.

Cassandra
On Jun 7, 2019, 5:53 AM -0500, Jan Høydahl <[hidden email]>, wrote:
Hi,

We have some contributors that open GitHub PRs without also opening a JIRA and linking the two. Probably because they are used to that workflow from other projects and expect someone to have a look at the contribution. There is an email sent to the dev list, and sometimes it is noticed, other times the PR just falls through the cracks and is forgotten.

Here is a list of currently open PRs without a JIRA attached, 51 in total:

https://github.com/apache/lucene-solr/pulls?utf8=✓&q=is%3Apr+is%3Aopen+NOT+LUCENE+in%3Atitle+AND+NOT+SOLR+in%3Atitle+

How can we improve on the situation? I see a few alternatives:

A. Setup a bot with a GitHub WebHook that inspects the title and auto adds a comment if LUCENE or SOLR is missing
https://developer.github.com/v3/activity/events/types/#pullrequestevent
B. Send the result of the above query to the dev@ list monthly for someone to jump in and interact
C. Add a GitHub Pull-Request Template https://help.github.com/en/articles/creating-a-pull-request-template-for-your-repository
In there put some text about the requirement for a JIRA
D. Treat PRs as first-class issues, without the need for a shadow JIRA. In that case, we'd reference PRs in CHANGES too, e.g.:
* #217: Fix bug foo
E. Migrate away from JIRA and use GitHub issues + PR instead. Some Apache projects do that already :)

Let the discussion begin :)

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Github PRs without attached JIRA issue

Kevin Risden-3
PR template would definitely be good. Easiest to implement with biggest impact. I like that all issues are in Jira. There is already an infra bot that will auto link Jiras and PRs if the PR has the a JIRA reference in it I think.

For reference this is also the idea of contributing guidelines in addition to the PR template [1] There are a few types of files that would help people if they stumble on the github repo [2].


Kevin Risden


On Fri, Jun 7, 2019 at 9:58 AM David Smiley <[hidden email]> wrote:
I think a PR template would be great.  Lets see yours Cassandra!

~ David Smiley
Apache Lucene/Solr Search Developer


On Fri, Jun 7, 2019 at 9:35 AM Cassandra Targett <[hidden email]> wrote:
Heh, here’s another idea I’ve had in my drafts folder for a while but thought if I suggest it I should be available to follow up on it and wasn’t sure if I’d have time to properly.

I actually started a pull request template and have a mostly complete version I could share (via a PR, I guess?). I don’t think it will 100% solve it, but it would greatly increase the number of issues that comply, for lack of a better term, with our processes/expectations for changes. In my draft I also included a short checklist to encourage people to make the patch for master, include tests with their patches, run precommit, and a few other things I thought might help new contributors understand what we need to get their patches reviewed faster.

Your D and E ideas are interesting. I worry about fragmenting where definitive info about changes is stored (D) - I think there is a lot of value in having a single system of record for the community.

I’d definitely be for exploring moving entirely to Github (E) - I think I said something along those lines in the lucene-solr Slack channel a few months ago - but have not spent much time figuring out all the downstream implications. I think we’d have to consider what we would gain vs what we would lose. I definitely don’t yet have a list, but I’m not initially against the idea.

Cassandra
On Jun 7, 2019, 5:53 AM -0500, Jan Høydahl <[hidden email]>, wrote:
Hi,

We have some contributors that open GitHub PRs without also opening a JIRA and linking the two. Probably because they are used to that workflow from other projects and expect someone to have a look at the contribution. There is an email sent to the dev list, and sometimes it is noticed, other times the PR just falls through the cracks and is forgotten.

Here is a list of currently open PRs without a JIRA attached, 51 in total:

https://github.com/apache/lucene-solr/pulls?utf8=✓&q=is%3Apr+is%3Aopen+NOT+LUCENE+in%3Atitle+AND+NOT+SOLR+in%3Atitle+

How can we improve on the situation? I see a few alternatives:

A. Setup a bot with a GitHub WebHook that inspects the title and auto adds a comment if LUCENE or SOLR is missing
https://developer.github.com/v3/activity/events/types/#pullrequestevent
B. Send the result of the above query to the dev@ list monthly for someone to jump in and interact
C. Add a GitHub Pull-Request Template https://help.github.com/en/articles/creating-a-pull-request-template-for-your-repository
In there put some text about the requirement for a JIRA
D. Treat PRs as first-class issues, without the need for a shadow JIRA. In that case, we'd reference PRs in CHANGES too, e.g.:
* #217: Fix bug foo
E. Migrate away from JIRA and use GitHub issues + PR instead. Some Apache projects do that already :)

Let the discussion begin :)

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Github PRs without attached JIRA issue

Cassandra Targett
I created an issue for this at https://issues.apache.org/jira/browse/LUCENE-8842, and I’ll use that to create a branch and push up what I have so far for a template.

Cassandra
On Jun 7, 2019, 11:31 AM -0500, Kevin Risden <[hidden email]>, wrote:
PR template would definitely be good. Easiest to implement with biggest impact. I like that all issues are in Jira. There is already an infra bot that will auto link Jiras and PRs if the PR has the a JIRA reference in it I think.

For reference this is also the idea of contributing guidelines in addition to the PR template [1] There are a few types of files that would help people if they stumble on the github repo [2].


Kevin Risden


On Fri, Jun 7, 2019 at 9:58 AM David Smiley <[hidden email]> wrote:
I think a PR template would be great.  Lets see yours Cassandra!

~ David Smiley
Apache Lucene/Solr Search Developer


On Fri, Jun 7, 2019 at 9:35 AM Cassandra Targett <[hidden email]> wrote:
Heh, here’s another idea I’ve had in my drafts folder for a while but thought if I suggest it I should be available to follow up on it and wasn’t sure if I’d have time to properly.

I actually started a pull request template and have a mostly complete version I could share (via a PR, I guess?). I don’t think it will 100% solve it, but it would greatly increase the number of issues that comply, for lack of a better term, with our processes/expectations for changes. In my draft I also included a short checklist to encourage people to make the patch for master, include tests with their patches, run precommit, and a few other things I thought might help new contributors understand what we need to get their patches reviewed faster.

Your D and E ideas are interesting. I worry about fragmenting where definitive info about changes is stored (D) - I think there is a lot of value in having a single system of record for the community.

I’d definitely be for exploring moving entirely to Github (E) - I think I said something along those lines in the lucene-solr Slack channel a few months ago - but have not spent much time figuring out all the downstream implications. I think we’d have to consider what we would gain vs what we would lose. I definitely don’t yet have a list, but I’m not initially against the idea.

Cassandra
On Jun 7, 2019, 5:53 AM -0500, Jan Høydahl <[hidden email]>, wrote:
Hi,

We have some contributors that open GitHub PRs without also opening a JIRA and linking the two. Probably because they are used to that workflow from other projects and expect someone to have a look at the contribution. There is an email sent to the dev list, and sometimes it is noticed, other times the PR just falls through the cracks and is forgotten.

Here is a list of currently open PRs without a JIRA attached, 51 in total:

https://github.com/apache/lucene-solr/pulls?utf8=✓&q=is%3Apr+is%3Aopen+NOT+LUCENE+in%3Atitle+AND+NOT+SOLR+in%3Atitle+

How can we improve on the situation? I see a few alternatives:

A. Setup a bot with a GitHub WebHook that inspects the title and auto adds a comment if LUCENE or SOLR is missing
https://developer.github.com/v3/activity/events/types/#pullrequestevent
B. Send the result of the above query to the dev@ list monthly for someone to jump in and interact
C. Add a GitHub Pull-Request Template https://help.github.com/en/articles/creating-a-pull-request-template-for-your-repository
In there put some text about the requirement for a JIRA
D. Treat PRs as first-class issues, without the need for a shadow JIRA. In that case, we'd reference PRs in CHANGES too, e.g.:
* #217: Fix bug foo
E. Migrate away from JIRA and use GitHub issues + PR instead. Some Apache projects do that already :)

Let the discussion begin :)

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Github PRs without attached JIRA issue

Gus Heck
I created an infra "wish" that relates somewhat to this as well... https://issues.apache.org/jira/browse/INFRA-18518   I also don't like D. There definitely needs to be only one place to search for issues. I don't like E either, while convenient from github their issue system has way fewer features, and I suspect even if we can port issues to it to keep the "one place" that will be lossy. As an example how would you implement the security issue visibility with original poster and PMC able to see it in github? I don't think they have a notion of roles/access control that is comparable. (or I'm simply unaware of it)

-Gus

On Fri, Jun 7, 2019 at 2:45 PM Cassandra Targett <[hidden email]> wrote:
I created an issue for this at https://issues.apache.org/jira/browse/LUCENE-8842, and I’ll use that to create a branch and push up what I have so far for a template.

Cassandra
On Jun 7, 2019, 11:31 AM -0500, Kevin Risden <[hidden email]>, wrote:
PR template would definitely be good. Easiest to implement with biggest impact. I like that all issues are in Jira. There is already an infra bot that will auto link Jiras and PRs if the PR has the a JIRA reference in it I think.

For reference this is also the idea of contributing guidelines in addition to the PR template [1] There are a few types of files that would help people if they stumble on the github repo [2].


Kevin Risden


On Fri, Jun 7, 2019 at 9:58 AM David Smiley <[hidden email]> wrote:
I think a PR template would be great.  Lets see yours Cassandra!

~ David Smiley
Apache Lucene/Solr Search Developer


On Fri, Jun 7, 2019 at 9:35 AM Cassandra Targett <[hidden email]> wrote:
Heh, here’s another idea I’ve had in my drafts folder for a while but thought if I suggest it I should be available to follow up on it and wasn’t sure if I’d have time to properly.

I actually started a pull request template and have a mostly complete version I could share (via a PR, I guess?). I don’t think it will 100% solve it, but it would greatly increase the number of issues that comply, for lack of a better term, with our processes/expectations for changes. In my draft I also included a short checklist to encourage people to make the patch for master, include tests with their patches, run precommit, and a few other things I thought might help new contributors understand what we need to get their patches reviewed faster.

Your D and E ideas are interesting. I worry about fragmenting where definitive info about changes is stored (D) - I think there is a lot of value in having a single system of record for the community.

I’d definitely be for exploring moving entirely to Github (E) - I think I said something along those lines in the lucene-solr Slack channel a few months ago - but have not spent much time figuring out all the downstream implications. I think we’d have to consider what we would gain vs what we would lose. I definitely don’t yet have a list, but I’m not initially against the idea.

Cassandra
On Jun 7, 2019, 5:53 AM -0500, Jan Høydahl <[hidden email]>, wrote:
Hi,

We have some contributors that open GitHub PRs without also opening a JIRA and linking the two. Probably because they are used to that workflow from other projects and expect someone to have a look at the contribution. There is an email sent to the dev list, and sometimes it is noticed, other times the PR just falls through the cracks and is forgotten.

Here is a list of currently open PRs without a JIRA attached, 51 in total:

https://github.com/apache/lucene-solr/pulls?utf8=✓&q=is%3Apr+is%3Aopen+NOT+LUCENE+in%3Atitle+AND+NOT+SOLR+in%3Atitle+

How can we improve on the situation? I see a few alternatives:

A. Setup a bot with a GitHub WebHook that inspects the title and auto adds a comment if LUCENE or SOLR is missing
https://developer.github.com/v3/activity/events/types/#pullrequestevent
B. Send the result of the above query to the dev@ list monthly for someone to jump in and interact
C. Add a GitHub Pull-Request Template https://help.github.com/en/articles/creating-a-pull-request-template-for-your-repository
In there put some text about the requirement for a JIRA
D. Treat PRs as first-class issues, without the need for a shadow JIRA. In that case, we'd reference PRs in CHANGES too, e.g.:
* #217: Fix bug foo
E. Migrate away from JIRA and use GitHub issues + PR instead. Some Apache projects do that already :)

Let the discussion begin :)

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



--
Reply | Threaded
Open this post in threaded view
|

Re: Github PRs without attached JIRA issue

Jan Høydahl / Cominvent
Jira has become very heavy-weight over the years and I'm not sure we need all those features.
I think Github issues are a bit too lightweight perhaps, so I'm not actively promoting option E, just lifting it up as a real alternative.

As an example how would you implement the security issue visibility with original poster and PMC able to see it in github?

Think they have something in the makings for this, see https://github.com/apache/lucene-solr/security/policy 
Have no idea if you can limit the group who sees them to PMC members though.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

Reply | Threaded
Open this post in threaded view
|

Re: Github PRs without attached JIRA issue

Varun Thacker-4
I think D is important for making the barrier low for new contributors to get started.

It won't be great as we'll have two places to look a CHANGES entry against but I'll be okay with that.

Today a new contributor creates a PR and a committer can even merge the PR from the github interface. But in between those 2 steps we have to tell the contributor to go create a placeholder Jira.

Imagine if this new contributor just wants to fix one typo from the ref guide. The overhead involved will shun quite a lot of folks?

On Sat, Jun 8, 2019 at 2:22 PM Jan Høydahl <[hidden email]> wrote:
Jira has become very heavy-weight over the years and I'm not sure we need all those features.
I think Github issues are a bit too lightweight perhaps, so I'm not actively promoting option E, just lifting it up as a real alternative.

As an example how would you implement the security issue visibility with original poster and PMC able to see it in github?

Think they have something in the makings for this, see https://github.com/apache/lucene-solr/security/policy 
Have no idea if you can limit the group who sees them to PMC members though.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

Reply | Threaded
Open this post in threaded view
|

Re: Github PRs without attached JIRA issue

Gus Heck
Or the committer can create it if the issue is truly trivial... Also, one of the things that folks who contribute may gain is learning about development process. That aspect was extremely helpful to me when I made my first contributions to Ant many years ago. Not everyone who contributes is an expert.

On Mon, Jun 10, 2019 at 3:33 AM Varun Thacker <[hidden email]> wrote:
I think D is important for making the barrier low for new contributors to get started.

It won't be great as we'll have two places to look a CHANGES entry against but I'll be okay with that.

Today a new contributor creates a PR and a committer can even merge the PR from the github interface. But in between those 2 steps we have to tell the contributor to go create a placeholder Jira.

Imagine if this new contributor just wants to fix one typo from the ref guide. The overhead involved will shun quite a lot of folks?

On Sat, Jun 8, 2019 at 2:22 PM Jan Høydahl <[hidden email]> wrote:
Jira has become very heavy-weight over the years and I'm not sure we need all those features.
I think Github issues are a bit too lightweight perhaps, so I'm not actively promoting option E, just lifting it up as a real alternative.

As an example how would you implement the security issue visibility with original poster and PMC able to see it in github?

Think they have something in the makings for this, see https://github.com/apache/lucene-solr/security/policy 
Have no idea if you can limit the group who sees them to PMC members though.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com



--
Reply | Threaded
Open this post in threaded view
|

Re: Github PRs without attached JIRA issue

Jan Høydahl / Cominvent
Once we get C in place (Github PR template), this will hopefully fix itself.
So I propose to try PR template as a first measure and then revisit if that is not enough.

Still left to do is to triage the existing open PRs and link them. Who wants to help? 


We should probably also look for PRs with a LUCENE/SOLR jira attached, where the fix is merged without auto-closing PR, and then close those.

TIP: When you merge code outside of github, add the text "fixes #123" to the commit message to automatically close PR#123.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

10. jun. 2019 kl. 15:05 skrev Gus Heck <[hidden email]>:

Or the committer can create it if the issue is truly trivial... Also, one of the things that folks who contribute may gain is learning about development process. That aspect was extremely helpful to me when I made my first contributions to Ant many years ago. Not everyone who contributes is an expert.

On Mon, Jun 10, 2019 at 3:33 AM Varun Thacker <[hidden email]> wrote:
I think D is important for making the barrier low for new contributors to get started.

It won't be great as we'll have two places to look a CHANGES entry against but I'll be okay with that.

Today a new contributor creates a PR and a committer can even merge the PR from the github interface. But in between those 2 steps we have to tell the contributor to go create a placeholder Jira.

Imagine if this new contributor just wants to fix one typo from the ref guide. The overhead involved will shun quite a lot of folks?

On Sat, Jun 8, 2019 at 2:22 PM Jan Høydahl <[hidden email]> wrote:
Jira has become very heavy-weight over the years and I'm not sure we need all those features.
I think Github issues are a bit too lightweight perhaps, so I'm not actively promoting option E, just lifting it up as a real alternative.

As an example how would you implement the security issue visibility with original poster and PMC able to see it in github?

Think they have something in the makings for this, see https://github.com/apache/lucene-solr/security/policy 
Have no idea if you can limit the group who sees them to PMC members though.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com



--

Reply | Threaded
Open this post in threaded view
|

Re: Github PRs without attached JIRA issue

Cassandra Targett
I committed the pull request template a bit ago. Let’s see if it helps.

I can help do some cleanup of existing open PRs, maybe tomorrow afternoon my time. It’s worth checking while we’re at it for PRs that are still open even though the Jira is resolved/closed.

Cassandra
On Jun 13, 2019, 6:08 AM -0500, Jan Høydahl <[hidden email]>, wrote:
Once we get C in place (Github PR template), this will hopefully fix itself.
So I propose to try PR template as a first measure and then revisit if that is not enough.

Still left to do is to triage the existing open PRs and link them. Who wants to help? 


We should probably also look for PRs with a LUCENE/SOLR jira attached, where the fix is merged without auto-closing PR, and then close those.

TIP: When you merge code outside of github, add the text "fixes #123" to the commit message to automatically close PR#123.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

10. jun. 2019 kl. 15:05 skrev Gus Heck <[hidden email]>:

Or the committer can create it if the issue is truly trivial... Also, one of the things that folks who contribute may gain is learning about development process. That aspect was extremely helpful to me when I made my first contributions to Ant many years ago. Not everyone who contributes is an expert.

On Mon, Jun 10, 2019 at 3:33 AM Varun Thacker <[hidden email]> wrote:
I think D is important for making the barrier low for new contributors to get started.

It won't be great as we'll have two places to look a CHANGES entry against but I'll be okay with that.

Today a new contributor creates a PR and a committer can even merge the PR from the github interface. But in between those 2 steps we have to tell the contributor to go create a placeholder Jira.

Imagine if this new contributor just wants to fix one typo from the ref guide. The overhead involved will shun quite a lot of folks?

On Sat, Jun 8, 2019 at 2:22 PM Jan Høydahl <[hidden email]> wrote:
Jira has become very heavy-weight over the years and I'm not sure we need all those features.
I think Github issues are a bit too lightweight perhaps, so I'm not actively promoting option E, just lifting it up as a real alternative.

As an example how would you implement the security issue visibility with original poster and PMC able to see it in github?

Think they have something in the makings for this, see https://github.com/apache/lucene-solr/security/policy 
Have no idea if you can limit the group who sees them to PMC members though.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com



--

Reply | Threaded
Open this post in threaded view
|

Re: Github PRs without attached JIRA issue

Jan Høydahl / Cominvent
I wrote a script to find PRs without JIRA in title and to find PRs where corresponding JIRA is closed. The output is below.
I could also extend the tool with options to also add a comment to the PRs lacking issue in title, and to close the PRs where JIRA is resolved :)


usage: githubPRs.py [-h] [--json] [--token TOKEN]

Find open Pull Requests that need attention

optional arguments:
  -h, --help     show this help message and exit
  --json         Output as json
  --token TOKEN  Github access token in case you query too often anonymously



Lucene/Solr Github PR report
============================
Number of open Pull Requests: 203
Processing...

PRs lacking JIRA reference in title
  #717: Code cleanup - Avoid using stream filter count where possible
  #711: Solr 12013
  #673: Replace instances of Math.random with Random.nextDouble
  #669: Facet2d
  #639: Solve the problem of highlighting Chinese inaccurately.
  #622: Update Tessellator logic to label if triangle edges belongs to the original polygon.
  #615: Intervals Query Parser
  #602: docu change: use class TopDocs instead of Hits
  #601: Adding reader settings for moving fst offheap
  #596: Under this branch, the dataDimensionCount is definitely not zero.
  #595: Load freqs lazily in Postings
  #564: prorated early termination
  #542: LuceneLevenshteinDistance computes distance values outside of interval [0, 1]
  #508: Simplified JAVA_VER_NUM to utilize single expr execution
  #507: Update jira/gradle to the latest master
  #492: Answer to TODO: Replace Manual Encoding with JSON Module
  #491: Update for multiple term's suggestion scoring
  #484: solr 7.5 suggest The recommended result is empty
  #478: Query Source Tracker custom component
  #450: Add rule exception for "imento" and "mento" suffix
  #442: Fixing an edge case bug when overriding a default PostingsSolrHighligher
  #415: Solr 12458
  #405: don't die when java prints tool options
  #404: Comment to explain how to use URLClassifyProcessorFactory
  #399: fix explicit type declaration
  #393: Lucene 8347
  #388: Update package-info.java
  #387: Solr-12421
  #383: In ContextQuery, use a more comprehensive check for an empty prefix automaton.
  #379: add ë, ö and ï to norm()
  #350: SOLR match mode change for the rouding off instead of taking floor
  #340: Add SolrConfig to SolrRequestParsers constructor in EmbeddedSolrServer
  #309: Update ZkConfigManager.java
  #308: Add a suggester that operates on tokenized values from a field
  #293: spellcheck prefix already contains a trailing dot
  #292: Removed extra whitespace
  #272: Correct inconsistency on plugin support
  #242: a little error about TopDocs
  #241: SpanishLightStemmer fix for plural words like casas
  #234: Made minor changes to docstring to fix wording errors
  #231: WordDelimiterGraphFilter: Better support for camel case splitting.
  #219: TieredMergePolicy.findMerges improvements
  #218: feat: Separate SuggestModes for WordBreak and WordJoin
  #217: added initial .travis.yml
  #201: Allocate ArrayList with exact size
  #175: Skipping merger
  #153: Fix issues reported by findbugs
  #152: Added log prior calculations in CachingNaiveBayesClassifier.
  #133: Prevent memory leaks in PerFieldAnalyzerWrapper
  #131: Fix peer sync replcation test check
  #124: fix small issue in solr shell script
  #116: fixed NPEs
  #110: Update SearchFiles.java
  #108: Minor - Fix error message
  #85: Allow updating configs like port # on forced upgrade
  #48: moved common string to constant file
  #22: Update files.js
  #8: Do not log error messages, if client has been interrupted

Open PRs with a resolved JIRA
Processing...
  #643: SOLR-13391 status=Resolved, resolution=Resolved, resolutiondate=2019-04-12T14:09:27.000+0000 (SOLR-13391: Add variance and standard deviation stream evaluators)
  #444: SOLR-12708 status=Closed, resolution=Fixed, resolutiondate=2019-03-19T03:46:31.000+0000 (SOLR-12708: Aggregate failures from downstream async jobs; add error …)
  #368: SOLR-12304 status=Resolved, resolution=Fixed, resolutiondate=2019-05-17T03:15:01.000+0000 ([SOLR-12304] More Like This component interesting term fix +tests)
  #365: SOLR-12243 status=Closed, resolution=Fixed, resolutiondate=2018-11-05T17:20:27.000+0000 ([SOLR-12243] span query generalization + query parser tests)
  #161: SOLR-9399 status=Closed, resolution=Fixed, resolutiondate=2018-04-02T16:31:06.000+0000 (Fix SOLR-9399, pass basic auth to update request)
  #93: SOLR-8754 status=Resolved, resolution=Fixed, resolutiondate=2019-06-13T10:59:41.000+0000 (SOLR-8754: Adding test cases and additional error checking)
  #651: LUCENE-8774 status=Closed, resolution=Duplicate, resolutiondate=2019-04-28T20:00:27.000+0000 (LUCENE-8774: Performance improvement for update?optimize=true)
  #648: LUCENE-8766 status=Resolved, resolution=Fixed, resolutiondate=2019-06-13T09:19:12.000+0000 (LUCENE-8766: Add Luwak as a lucene module)
  #631: LUCENE-8750 status=Resolved, resolution=Fixed, resolutiondate=2019-04-03T09:19:47.000+0000 (LUCENE-8750: implement setMissingValue for ValueSource sortFields)
  #536: LUCENE-8643 status=Resolved, resolution=Fixed, resolutiondate=2019-01-17T09:12:09.000+0000 (LUCENE-8643: Decrease test complexity in the default case. Exclude simple text codec.)
  #538: LUCENE-8640 status=Closed, resolution=Fixed, resolutiondate=2019-01-28T19:30:32.000+0000 (LUCENE-8640: added changes for the validation of valid dateString)
  #533: LUCENE-8636 status=Resolved, resolution=Fixed, resolutiondate=2019-01-15T11:02:49.000+0000 (LUCENE-8636: TestPointQueries and long execution times)
  #543: LUCENE-8474 status=Resolved, resolution=Fixed, resolutiondate=2019-01-28T12:50:00.000+0000 (LUCENE-8474: final cleanups and removal of RAMDirectory)
  #432: LUCENE-8438 status=Resolved, resolution=Fixed, resolutiondate=2019-01-28T12:52:44.000+0000 (LUCENE-8438: RAMDirectory speed improvements and cleanup)
  #146: LUCENE-7633 status=Closed, resolution=Won't Fix, resolutiondate=2017-02-01T10:27:53.000+0000 (Rename Terms to IndexedField and some related renamings, LUCENE-7633)
  #141: LUCENE-7624 status=Closed, resolution=Fixed, resolutiondate=2017-01-09T15:34:25.000+0000 (Minor corrections, see also LUCENE-7624)
  #165: LUCENE-7615 status=Resolved, resolution=Won't Fix, resolutiondate=2018-04-02T19:38:51.000+0000 (LUCENE-7615 of 8 March 2017.)
  #389: LUCENE-6687 status=Resolved, resolution=Fixed, resolutiondate=2019-05-10T10:25:58.000+0000 ([LUCENE-6687] not necessary nested for loop removed for terms retriev…)
  #582: LUCENE-582 status=Closed, resolution=Fixed, resolutiondate=2008-11-13T00:04:45.000+0000 (LUCENE-582: change heap array init index to 1)

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

13. jun. 2019 kl. 22:56 skrev Cassandra Targett <[hidden email]>:

I committed the pull request template a bit ago. Let’s see if it helps.

I can help do some cleanup of existing open PRs, maybe tomorrow afternoon my time. It’s worth checking while we’re at it for PRs that are still open even though the Jira is resolved/closed.

Cassandra
On Jun 13, 2019, 6:08 AM -0500, Jan Høydahl <[hidden email]>, wrote:
Once we get C in place (Github PR template), this will hopefully fix itself.
So I propose to try PR template as a first measure and then revisit if that is not enough.

Still left to do is to triage the existing open PRs and link them. Who wants to help? 


We should probably also look for PRs with a LUCENE/SOLR jira attached, where the fix is merged without auto-closing PR, and then close those.

TIP: When you merge code outside of github, add the text "fixes #123" to the commit message to automatically close PR#123.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

10. jun. 2019 kl. 15:05 skrev Gus Heck <[hidden email]>:

Or the committer can create it if the issue is truly trivial... Also, one of the things that folks who contribute may gain is learning about development process. That aspect was extremely helpful to me when I made my first contributions to Ant many years ago. Not everyone who contributes is an expert.

On Mon, Jun 10, 2019 at 3:33 AM Varun Thacker <[hidden email]> wrote:
I think D is important for making the barrier low for new contributors to get started.

It won't be great as we'll have two places to look a CHANGES entry against but I'll be okay with that.

Today a new contributor creates a PR and a committer can even merge the PR from the github interface. But in between those 2 steps we have to tell the contributor to go create a placeholder Jira.

Imagine if this new contributor just wants to fix one typo from the ref guide. The overhead involved will shun quite a lot of folks?

On Sat, Jun 8, 2019 at 2:22 PM Jan Høydahl <[hidden email]> wrote:
Jira has become very heavy-weight over the years and I'm not sure we need all those features.
I think Github issues are a bit too lightweight perhaps, so I'm not actively promoting option E, just lifting it up as a real alternative.

As an example how would you implement the security issue visibility with original poster and PMC able to see it in github?

Think they have something in the makings for this, see https://github.com/apache/lucene-solr/security/policy 
Have no idea if you can limit the group who sees them to PMC members though.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com



--


Reply | Threaded
Open this post in threaded view
|

Re: Github PRs without attached JIRA issue

Jan Høydahl / Cominvent
I closed PR #165, #146, #444, #711 and #651

I checked in the python script so you may try to run it for yourself

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

14. jun. 2019 kl. 13:20 skrev Jan Høydahl <[hidden email]>:

I wrote a script to find PRs without JIRA in title and to find PRs where corresponding JIRA is closed. The output is below.
I could also extend the tool with options to also add a comment to the PRs lacking issue in title, and to close the PRs where JIRA is resolved :)


usage: githubPRs.py [-h] [--json] [--token TOKEN]

Find open Pull Requests that need attention

optional arguments:
  -h, --help     show this help message and exit
  --json         Output as json
  --token TOKEN  Github access token in case you query too often anonymously



Lucene/Solr Github PR report
============================
Number of open Pull Requests: 203
Processing...

PRs lacking JIRA reference in title
  #717: Code cleanup - Avoid using stream filter count where possible
  #711: Solr 12013
  #673: Replace instances of Math.random with Random.nextDouble
  #669: Facet2d
  #639: Solve the problem of highlighting Chinese inaccurately.
  #622: Update Tessellator logic to label if triangle edges belongs to the original polygon.
  #615: Intervals Query Parser
  #602: docu change: use class TopDocs instead of Hits
  #601: Adding reader settings for moving fst offheap
  #596: Under this branch, the dataDimensionCount is definitely not zero.
  #595: Load freqs lazily in Postings
  #564: prorated early termination
  #542: LuceneLevenshteinDistance computes distance values outside of interval [0, 1]
  #508: Simplified JAVA_VER_NUM to utilize single expr execution
  #507: Update jira/gradle to the latest master
  #492: Answer to TODO: Replace Manual Encoding with JSON Module
  #491: Update for multiple term's suggestion scoring
  #484: solr 7.5 suggest The recommended result is empty
  #478: Query Source Tracker custom component
  #450: Add rule exception for "imento" and "mento" suffix
  #442: Fixing an edge case bug when overriding a default PostingsSolrHighligher
  #415: Solr 12458
  #405: don't die when java prints tool options
  #404: Comment to explain how to use URLClassifyProcessorFactory
  #399: fix explicit type declaration
  #393: Lucene 8347
  #388: Update package-info.java
  #387: Solr-12421
  #383: In ContextQuery, use a more comprehensive check for an empty prefix automaton.
  #379: add ë, ö and ï to norm()
  #350: SOLR match mode change for the rouding off instead of taking floor
  #340: Add SolrConfig to SolrRequestParsers constructor in EmbeddedSolrServer
  #309: Update ZkConfigManager.java
  #308: Add a suggester that operates on tokenized values from a field
  #293: spellcheck prefix already contains a trailing dot
  #292: Removed extra whitespace
  #272: Correct inconsistency on plugin support
  #242: a little error about TopDocs
  #241: SpanishLightStemmer fix for plural words like casas
  #234: Made minor changes to docstring to fix wording errors
  #231: WordDelimiterGraphFilter: Better support for camel case splitting.
  #219: TieredMergePolicy.findMerges improvements
  #218: feat: Separate SuggestModes for WordBreak and WordJoin
  #217: added initial .travis.yml
  #201: Allocate ArrayList with exact size
  #175: Skipping merger
  #153: Fix issues reported by findbugs
  #152: Added log prior calculations in CachingNaiveBayesClassifier.
  #133: Prevent memory leaks in PerFieldAnalyzerWrapper
  #131: Fix peer sync replcation test check
  #124: fix small issue in solr shell script
  #116: fixed NPEs
  #110: Update SearchFiles.java
  #108: Minor - Fix error message
  #85: Allow updating configs like port # on forced upgrade
  #48: moved common string to constant file
  #22: Update files.js
  #8: Do not log error messages, if client has been interrupted

Open PRs with a resolved JIRA
Processing...
  #643: SOLR-13391 status=Resolved, resolution=Resolved, resolutiondate=2019-04-12T14:09:27.000+0000 (SOLR-13391: Add variance and standard deviation stream evaluators)
  #444: SOLR-12708 status=Closed, resolution=Fixed, resolutiondate=2019-03-19T03:46:31.000+0000 (SOLR-12708: Aggregate failures from downstream async jobs; add error …)
  #368: SOLR-12304 status=Resolved, resolution=Fixed, resolutiondate=2019-05-17T03:15:01.000+0000 ([SOLR-12304] More Like This component interesting term fix +tests)
  #365: SOLR-12243 status=Closed, resolution=Fixed, resolutiondate=2018-11-05T17:20:27.000+0000 ([SOLR-12243] span query generalization + query parser tests)
  #161: SOLR-9399 status=Closed, resolution=Fixed, resolutiondate=2018-04-02T16:31:06.000+0000 (Fix SOLR-9399, pass basic auth to update request)
  #93: SOLR-8754 status=Resolved, resolution=Fixed, resolutiondate=2019-06-13T10:59:41.000+0000 (SOLR-8754: Adding test cases and additional error checking)
  #651: LUCENE-8774 status=Closed, resolution=Duplicate, resolutiondate=2019-04-28T20:00:27.000+0000 (LUCENE-8774: Performance improvement for update?optimize=true)
  #648: LUCENE-8766 status=Resolved, resolution=Fixed, resolutiondate=2019-06-13T09:19:12.000+0000 (LUCENE-8766: Add Luwak as a lucene module)
  #631: LUCENE-8750 status=Resolved, resolution=Fixed, resolutiondate=2019-04-03T09:19:47.000+0000 (LUCENE-8750: implement setMissingValue for ValueSource sortFields)
  #536: LUCENE-8643 status=Resolved, resolution=Fixed, resolutiondate=2019-01-17T09:12:09.000+0000 (LUCENE-8643: Decrease test complexity in the default case. Exclude simple text codec.)
  #538: LUCENE-8640 status=Closed, resolution=Fixed, resolutiondate=2019-01-28T19:30:32.000+0000 (LUCENE-8640: added changes for the validation of valid dateString)
  #533: LUCENE-8636 status=Resolved, resolution=Fixed, resolutiondate=2019-01-15T11:02:49.000+0000 (LUCENE-8636: TestPointQueries and long execution times)
  #543: LUCENE-8474 status=Resolved, resolution=Fixed, resolutiondate=2019-01-28T12:50:00.000+0000 (LUCENE-8474: final cleanups and removal of RAMDirectory)
  #432: LUCENE-8438 status=Resolved, resolution=Fixed, resolutiondate=2019-01-28T12:52:44.000+0000 (LUCENE-8438: RAMDirectory speed improvements and cleanup)
  #146: LUCENE-7633 status=Closed, resolution=Won't Fix, resolutiondate=2017-02-01T10:27:53.000+0000 (Rename Terms to IndexedField and some related renamings, LUCENE-7633)
  #141: LUCENE-7624 status=Closed, resolution=Fixed, resolutiondate=2017-01-09T15:34:25.000+0000 (Minor corrections, see also LUCENE-7624)
  #165: LUCENE-7615 status=Resolved, resolution=Won't Fix, resolutiondate=2018-04-02T19:38:51.000+0000 (LUCENE-7615 of 8 March 2017.)
  #389: LUCENE-6687 status=Resolved, resolution=Fixed, resolutiondate=2019-05-10T10:25:58.000+0000 ([LUCENE-6687] not necessary nested for loop removed for terms retriev…)
  #582: LUCENE-582 status=Closed, resolution=Fixed, resolutiondate=2008-11-13T00:04:45.000+0000 (LUCENE-582: change heap array init index to 1)

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

13. jun. 2019 kl. 22:56 skrev Cassandra Targett <[hidden email]>:

I committed the pull request template a bit ago. Let’s see if it helps.

I can help do some cleanup of existing open PRs, maybe tomorrow afternoon my time. It’s worth checking while we’re at it for PRs that are still open even though the Jira is resolved/closed.

Cassandra
On Jun 13, 2019, 6:08 AM -0500, Jan Høydahl <[hidden email]>, wrote:
Once we get C in place (Github PR template), this will hopefully fix itself.
So I propose to try PR template as a first measure and then revisit if that is not enough.

Still left to do is to triage the existing open PRs and link them. Who wants to help? 


We should probably also look for PRs with a LUCENE/SOLR jira attached, where the fix is merged without auto-closing PR, and then close those.

TIP: When you merge code outside of github, add the text "fixes #123" to the commit message to automatically close PR#123.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

10. jun. 2019 kl. 15:05 skrev Gus Heck <[hidden email]>:

Or the committer can create it if the issue is truly trivial... Also, one of the things that folks who contribute may gain is learning about development process. That aspect was extremely helpful to me when I made my first contributions to Ant many years ago. Not everyone who contributes is an expert.

On Mon, Jun 10, 2019 at 3:33 AM Varun Thacker <[hidden email]> wrote:
I think D is important for making the barrier low for new contributors to get started.

It won't be great as we'll have two places to look a CHANGES entry against but I'll be okay with that.

Today a new contributor creates a PR and a committer can even merge the PR from the github interface. But in between those 2 steps we have to tell the contributor to go create a placeholder Jira.

Imagine if this new contributor just wants to fix one typo from the ref guide. The overhead involved will shun quite a lot of folks?

On Sat, Jun 8, 2019 at 2:22 PM Jan Høydahl <[hidden email]> wrote:
Jira has become very heavy-weight over the years and I'm not sure we need all those features.
I think Github issues are a bit too lightweight perhaps, so I'm not actively promoting option E, just lifting it up as a real alternative.

As an example how would you implement the security issue visibility with original poster and PMC able to see it in github?

Think they have something in the makings for this, see https://github.com/apache/lucene-solr/security/policy 
Have no idea if you can limit the group who sees them to PMC members though.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com



--



Reply | Threaded
Open this post in threaded view
|

Re: Github PRs without attached JIRA issue

Cassandra Targett
Nice script Jan, thanks.

Just a note for others who may have a less than complete python setup already, I needed to install pygithub and jira modules to get it to run:

pip install pygithub
pip install jira

Cassandra
On Jun 14, 2019, 7:11 AM -0500, Jan Høydahl <[hidden email]>, wrote:
I closed PR #165, #146, #444, #711 and #651

I checked in the python script so you may try to run it for yourself

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

14. jun. 2019 kl. 13:20 skrev Jan Høydahl <[hidden email]>:

I wrote a script to find PRs without JIRA in title and to find PRs where corresponding JIRA is closed. The output is below.
I could also extend the tool with options to also add a comment to the PRs lacking issue in title, and to close the PRs where JIRA is resolved :)


usage: githubPRs.py [-h] [--json] [--token TOKEN]

Find open Pull Requests that need attention

optional arguments:
  -h, --help     show this help message and exit
  --json         Output as json
  --token TOKEN  Github access token in case you query too often anonymously



Lucene/Solr Github PR report
============================
Number of open Pull Requests: 203
Processing...

PRs lacking JIRA reference in title
  #717: Code cleanup - Avoid using stream filter count where possible
  #711: Solr 12013
  #673: Replace instances of Math.random with Random.nextDouble
  #669: Facet2d
  #639: Solve the problem of highlighting Chinese inaccurately.
  #622: Update Tessellator logic to label if triangle edges belongs to the original polygon.
  #615: Intervals Query Parser
  #602: docu change: use class TopDocs instead of Hits
  #601: Adding reader settings for moving fst offheap
  #596: Under this branch, the dataDimensionCount is definitely not zero.
  #595: Load freqs lazily in Postings
  #564: prorated early termination
  #542: LuceneLevenshteinDistance computes distance values outside of interval [0, 1]
  #508: Simplified JAVA_VER_NUM to utilize single expr execution
  #507: Update jira/gradle to the latest master
  #492: Answer to TODO: Replace Manual Encoding with JSON Module
  #491: Update for multiple term's suggestion scoring
  #484: solr 7.5 suggest The recommended result is empty
  #478: Query Source Tracker custom component
  #450: Add rule exception for "imento" and "mento" suffix
  #442: Fixing an edge case bug when overriding a default PostingsSolrHighligher
  #415: Solr 12458
  #405: don't die when java prints tool options
  #404: Comment to explain how to use URLClassifyProcessorFactory
  #399: fix explicit type declaration
  #393: Lucene 8347
  #388: Update package-info.java
  #387: Solr-12421
  #383: In ContextQuery, use a more comprehensive check for an empty prefix automaton.
  #379: add ë, ö and ï to norm()
  #350: SOLR match mode change for the rouding off instead of taking floor
  #340: Add SolrConfig to SolrRequestParsers constructor in EmbeddedSolrServer
  #309: Update ZkConfigManager.java
  #308: Add a suggester that operates on tokenized values from a field
  #293: spellcheck prefix already contains a trailing dot
  #292: Removed extra whitespace
  #272: Correct inconsistency on plugin support
  #242: a little error about TopDocs
  #241: SpanishLightStemmer fix for plural words like casas
  #234: Made minor changes to docstring to fix wording errors
  #231: WordDelimiterGraphFilter: Better support for camel case splitting.
  #219: TieredMergePolicy.findMerges improvements
  #218: feat: Separate SuggestModes for WordBreak and WordJoin
  #217: added initial .travis.yml
  #201: Allocate ArrayList with exact size
  #175: Skipping merger
  #153: Fix issues reported by findbugs
  #152: Added log prior calculations in CachingNaiveBayesClassifier.
  #133: Prevent memory leaks in PerFieldAnalyzerWrapper
  #131: Fix peer sync replcation test check
  #124: fix small issue in solr shell script
  #116: fixed NPEs
  #110: Update SearchFiles.java
  #108: Minor - Fix error message
  #85: Allow updating configs like port # on forced upgrade
  #48: moved common string to constant file
  #22: Update files.js
  #8: Do not log error messages, if client has been interrupted

Open PRs with a resolved JIRA
Processing...
  #643: SOLR-13391 status=Resolved, resolution=Resolved, resolutiondate=2019-04-12T14:09:27.000+0000 (SOLR-13391: Add variance and standard deviation stream evaluators)
  #444: SOLR-12708 status=Closed, resolution=Fixed, resolutiondate=2019-03-19T03:46:31.000+0000 (SOLR-12708: Aggregate failures from downstream async jobs; add error …)
  #368: SOLR-12304 status=Resolved, resolution=Fixed, resolutiondate=2019-05-17T03:15:01.000+0000 ([SOLR-12304] More Like This component interesting term fix +tests)
  #365: SOLR-12243 status=Closed, resolution=Fixed, resolutiondate=2018-11-05T17:20:27.000+0000 ([SOLR-12243] span query generalization + query parser tests)
  #161: SOLR-9399 status=Closed, resolution=Fixed, resolutiondate=2018-04-02T16:31:06.000+0000 (Fix SOLR-9399, pass basic auth to update request)
  #93: SOLR-8754 status=Resolved, resolution=Fixed, resolutiondate=2019-06-13T10:59:41.000+0000 (SOLR-8754: Adding test cases and additional error checking)
  #651: LUCENE-8774 status=Closed, resolution=Duplicate, resolutiondate=2019-04-28T20:00:27.000+0000 (LUCENE-8774: Performance improvement for update?optimize=true)
  #648: LUCENE-8766 status=Resolved, resolution=Fixed, resolutiondate=2019-06-13T09:19:12.000+0000 (LUCENE-8766: Add Luwak as a lucene module)
  #631: LUCENE-8750 status=Resolved, resolution=Fixed, resolutiondate=2019-04-03T09:19:47.000+0000 (LUCENE-8750: implement setMissingValue for ValueSource sortFields)
  #536: LUCENE-8643 status=Resolved, resolution=Fixed, resolutiondate=2019-01-17T09:12:09.000+0000 (LUCENE-8643: Decrease test complexity in the default case. Exclude simple text codec.)
  #538: LUCENE-8640 status=Closed, resolution=Fixed, resolutiondate=2019-01-28T19:30:32.000+0000 (LUCENE-8640: added changes for the validation of valid dateString)
  #533: LUCENE-8636 status=Resolved, resolution=Fixed, resolutiondate=2019-01-15T11:02:49.000+0000 (LUCENE-8636: TestPointQueries and long execution times)
  #543: LUCENE-8474 status=Resolved, resolution=Fixed, resolutiondate=2019-01-28T12:50:00.000+0000 (LUCENE-8474: final cleanups and removal of RAMDirectory)
  #432: LUCENE-8438 status=Resolved, resolution=Fixed, resolutiondate=2019-01-28T12:52:44.000+0000 (LUCENE-8438: RAMDirectory speed improvements and cleanup)
  #146: LUCENE-7633 status=Closed, resolution=Won't Fix, resolutiondate=2017-02-01T10:27:53.000+0000 (Rename Terms to IndexedField and some related renamings, LUCENE-7633)
  #141: LUCENE-7624 status=Closed, resolution=Fixed, resolutiondate=2017-01-09T15:34:25.000+0000 (Minor corrections, see also LUCENE-7624)
  #165: LUCENE-7615 status=Resolved, resolution=Won't Fix, resolutiondate=2018-04-02T19:38:51.000+0000 (LUCENE-7615 of 8 March 2017.)
  #389: LUCENE-6687 status=Resolved, resolution=Fixed, resolutiondate=2019-05-10T10:25:58.000+0000 ([LUCENE-6687] not necessary nested for loop removed for terms retriev…)
  #582: LUCENE-582 status=Closed, resolution=Fixed, resolutiondate=2008-11-13T00:04:45.000+0000 (LUCENE-582: change heap array init index to 1)

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

13. jun. 2019 kl. 22:56 skrev Cassandra Targett <[hidden email]>:

I committed the pull request template a bit ago. Let’s see if it helps.

I can help do some cleanup of existing open PRs, maybe tomorrow afternoon my time. It’s worth checking while we’re at it for PRs that are still open even though the Jira is resolved/closed.

Cassandra
On Jun 13, 2019, 6:08 AM -0500, Jan Høydahl <[hidden email]>, wrote:
Once we get C in place (Github PR template), this will hopefully fix itself.
So I propose to try PR template as a first measure and then revisit if that is not enough.

Still left to do is to triage the existing open PRs and link them. Who wants to help? 


We should probably also look for PRs with a LUCENE/SOLR jira attached, where the fix is merged without auto-closing PR, and then close those.

TIP: When you merge code outside of github, add the text "fixes #123" to the commit message to automatically close PR#123.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

10. jun. 2019 kl. 15:05 skrev Gus Heck <[hidden email]>:

Or the committer can create it if the issue is truly trivial... Also, one of the things that folks who contribute may gain is learning about development process. That aspect was extremely helpful to me when I made my first contributions to Ant many years ago. Not everyone who contributes is an expert.

On Mon, Jun 10, 2019 at 3:33 AM Varun Thacker <[hidden email]> wrote:
I think D is important for making the barrier low for new contributors to get started.

It won't be great as we'll have two places to look a CHANGES entry against but I'll be okay with that.

Today a new contributor creates a PR and a committer can even merge the PR from the github interface. But in between those 2 steps we have to tell the contributor to go create a placeholder Jira.

Imagine if this new contributor just wants to fix one typo from the ref guide. The overhead involved will shun quite a lot of folks?

On Sat, Jun 8, 2019 at 2:22 PM Jan Høydahl <[hidden email]> wrote:
Jira has become very heavy-weight over the years and I'm not sure we need all those features.
I think Github issues are a bit too lightweight perhaps, so I'm not actively promoting option E, just lifting it up as a real alternative.

As an example how would you implement the security issue visibility with original poster and PMC able to see it in github?

Think they have something in the makings for this, see https://github.com/apache/lucene-solr/security/policy 
Have no idea if you can limit the group who sees them to PMC members though.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com



--



Reply | Threaded
Open this post in threaded view
|

Re: Github PRs without attached JIRA issue

Jan Høydahl / Cominvent
Thanks for mentioning. I’m adding a README.md to the scripts folder soon. It will mention this prerequisite:

pip3 install -r requirements.txt

In the requirements file we’ll also gather dependencies for other scripts in the folder.

Jan Høydahl

14. jun. 2019 kl. 22:26 skrev Cassandra Targett <[hidden email]>:

Nice script Jan, thanks.

Just a note for others who may have a less than complete python setup already, I needed to install pygithub and jira modules to get it to run:

pip install pygithub
pip install jira

Cassandra
On Jun 14, 2019, 7:11 AM -0500, Jan Høydahl <[hidden email]>, wrote:
I closed PR #165, #146, #444, #711 and #651

I checked in the python script so you may try to run it for yourself

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

14. jun. 2019 kl. 13:20 skrev Jan Høydahl <[hidden email]>:

I wrote a script to find PRs without JIRA in title and to find PRs where corresponding JIRA is closed. The output is below.
I could also extend the tool with options to also add a comment to the PRs lacking issue in title, and to close the PRs where JIRA is resolved :)


usage: githubPRs.py [-h] [--json] [--token TOKEN]

Find open Pull Requests that need attention

optional arguments:
  -h, --help     show this help message and exit
  --json         Output as json
  --token TOKEN  Github access token in case you query too often anonymously



Lucene/Solr Github PR report
============================
Number of open Pull Requests: 203
Processing...

PRs lacking JIRA reference in title
  #717: Code cleanup - Avoid using stream filter count where possible
  #711: Solr 12013
  #673: Replace instances of Math.random with Random.nextDouble
  #669: Facet2d
  #639: Solve the problem of highlighting Chinese inaccurately.
  #622: Update Tessellator logic to label if triangle edges belongs to the original polygon.
  #615: Intervals Query Parser
  #602: docu change: use class TopDocs instead of Hits
  #601: Adding reader settings for moving fst offheap
  #596: Under this branch, the dataDimensionCount is definitely not zero.
  #595: Load freqs lazily in Postings
  #564: prorated early termination
  #542: LuceneLevenshteinDistance computes distance values outside of interval [0, 1]
  #508: Simplified JAVA_VER_NUM to utilize single expr execution
  #507: Update jira/gradle to the latest master
  #492: Answer to TODO: Replace Manual Encoding with JSON Module
  #491: Update for multiple term's suggestion scoring
  #484: solr 7.5 suggest The recommended result is empty
  #478: Query Source Tracker custom component
  #450: Add rule exception for "imento" and "mento" suffix
  #442: Fixing an edge case bug when overriding a default PostingsSolrHighligher
  #415: Solr 12458
  #405: don't die when java prints tool options
  #404: Comment to explain how to use URLClassifyProcessorFactory
  #399: fix explicit type declaration
  #393: Lucene 8347
  #388: Update package-info.java
  #387: Solr-12421
  #383: In ContextQuery, use a more comprehensive check for an empty prefix automaton.
  #379: add ë, ö and ï to norm()
  #350: SOLR match mode change for the rouding off instead of taking floor
  #340: Add SolrConfig to SolrRequestParsers constructor in EmbeddedSolrServer
  #309: Update ZkConfigManager.java
  #308: Add a suggester that operates on tokenized values from a field
  #293: spellcheck prefix already contains a trailing dot
  #292: Removed extra whitespace
  #272: Correct inconsistency on plugin support
  #242: a little error about TopDocs
  #241: SpanishLightStemmer fix for plural words like casas
  #234: Made minor changes to docstring to fix wording errors
  #231: WordDelimiterGraphFilter: Better support for camel case splitting.
  #219: TieredMergePolicy.findMerges improvements
  #218: feat: Separate SuggestModes for WordBreak and WordJoin
  #217: added initial .travis.yml
  #201: Allocate ArrayList with exact size
  #175: Skipping merger
  #153: Fix issues reported by findbugs
  #152: Added log prior calculations in CachingNaiveBayesClassifier.
  #133: Prevent memory leaks in PerFieldAnalyzerWrapper
  #131: Fix peer sync replcation test check
  #124: fix small issue in solr shell script
  #116: fixed NPEs
  #110: Update SearchFiles.java
  #108: Minor - Fix error message
  #85: Allow updating configs like port # on forced upgrade
  #48: moved common string to constant file
  #22: Update files.js
  #8: Do not log error messages, if client has been interrupted

Open PRs with a resolved JIRA
Processing...
  #643: SOLR-13391 status=Resolved, resolution=Resolved, resolutiondate=2019-04-12T14:09:27.000+0000 (SOLR-13391: Add variance and standard deviation stream evaluators)
  #444: SOLR-12708 status=Closed, resolution=Fixed, resolutiondate=2019-03-19T03:46:31.000+0000 (SOLR-12708: Aggregate failures from downstream async jobs; add error …)
  #368: SOLR-12304 status=Resolved, resolution=Fixed, resolutiondate=2019-05-17T03:15:01.000+0000 ([SOLR-12304] More Like This component interesting term fix +tests)
  #365: SOLR-12243 status=Closed, resolution=Fixed, resolutiondate=2018-11-05T17:20:27.000+0000 ([SOLR-12243] span query generalization + query parser tests)
  #161: SOLR-9399 status=Closed, resolution=Fixed, resolutiondate=2018-04-02T16:31:06.000+0000 (Fix SOLR-9399, pass basic auth to update request)
  #93: SOLR-8754 status=Resolved, resolution=Fixed, resolutiondate=2019-06-13T10:59:41.000+0000 (SOLR-8754: Adding test cases and additional error checking)
  #651: LUCENE-8774 status=Closed, resolution=Duplicate, resolutiondate=2019-04-28T20:00:27.000+0000 (LUCENE-8774: Performance improvement for update?optimize=true)
  #648: LUCENE-8766 status=Resolved, resolution=Fixed, resolutiondate=2019-06-13T09:19:12.000+0000 (LUCENE-8766: Add Luwak as a lucene module)
  #631: LUCENE-8750 status=Resolved, resolution=Fixed, resolutiondate=2019-04-03T09:19:47.000+0000 (LUCENE-8750: implement setMissingValue for ValueSource sortFields)
  #536: LUCENE-8643 status=Resolved, resolution=Fixed, resolutiondate=2019-01-17T09:12:09.000+0000 (LUCENE-8643: Decrease test complexity in the default case. Exclude simple text codec.)
  #538: LUCENE-8640 status=Closed, resolution=Fixed, resolutiondate=2019-01-28T19:30:32.000+0000 (LUCENE-8640: added changes for the validation of valid dateString)
  #533: LUCENE-8636 status=Resolved, resolution=Fixed, resolutiondate=2019-01-15T11:02:49.000+0000 (LUCENE-8636: TestPointQueries and long execution times)
  #543: LUCENE-8474 status=Resolved, resolution=Fixed, resolutiondate=2019-01-28T12:50:00.000+0000 (LUCENE-8474: final cleanups and removal of RAMDirectory)
  #432: LUCENE-8438 status=Resolved, resolution=Fixed, resolutiondate=2019-01-28T12:52:44.000+0000 (LUCENE-8438: RAMDirectory speed improvements and cleanup)
  #146: LUCENE-7633 status=Closed, resolution=Won't Fix, resolutiondate=2017-02-01T10:27:53.000+0000 (Rename Terms to IndexedField and some related renamings, LUCENE-7633)
  #141: LUCENE-7624 status=Closed, resolution=Fixed, resolutiondate=2017-01-09T15:34:25.000+0000 (Minor corrections, see also LUCENE-7624)
  #165: LUCENE-7615 status=Resolved, resolution=Won't Fix, resolutiondate=2018-04-02T19:38:51.000+0000 (LUCENE-7615 of 8 March 2017.)
  #389: LUCENE-6687 status=Resolved, resolution=Fixed, resolutiondate=2019-05-10T10:25:58.000+0000 ([LUCENE-6687] not necessary nested for loop removed for terms retriev…)
  #582: LUCENE-582 status=Closed, resolution=Fixed, resolutiondate=2008-11-13T00:04:45.000+0000 (LUCENE-582: change heap array init index to 1)

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

13. jun. 2019 kl. 22:56 skrev Cassandra Targett <[hidden email]>:

I committed the pull request template a bit ago. Let’s see if it helps.

I can help do some cleanup of existing open PRs, maybe tomorrow afternoon my time. It’s worth checking while we’re at it for PRs that are still open even though the Jira is resolved/closed.

Cassandra
On Jun 13, 2019, 6:08 AM -0500, Jan Høydahl <[hidden email]>, wrote:
Once we get C in place (Github PR template), this will hopefully fix itself.
So I propose to try PR template as a first measure and then revisit if that is not enough.

Still left to do is to triage the existing open PRs and link them. Who wants to help? 


We should probably also look for PRs with a LUCENE/SOLR jira attached, where the fix is merged without auto-closing PR, and then close those.

TIP: When you merge code outside of github, add the text "fixes #123" to the commit message to automatically close PR#123.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

10. jun. 2019 kl. 15:05 skrev Gus Heck <[hidden email]>:

Or the committer can create it if the issue is truly trivial... Also, one of the things that folks who contribute may gain is learning about development process. That aspect was extremely helpful to me when I made my first contributions to Ant many years ago. Not everyone who contributes is an expert.

On Mon, Jun 10, 2019 at 3:33 AM Varun Thacker <[hidden email]> wrote:
I think D is important for making the barrier low for new contributors to get started.

It won't be great as we'll have two places to look a CHANGES entry against but I'll be okay with that.

Today a new contributor creates a PR and a committer can even merge the PR from the github interface. But in between those 2 steps we have to tell the contributor to go create a placeholder Jira.

Imagine if this new contributor just wants to fix one typo from the ref guide. The overhead involved will shun quite a lot of folks?

On Sat, Jun 8, 2019 at 2:22 PM Jan Høydahl <[hidden email]> wrote:
Jira has become very heavy-weight over the years and I'm not sure we need all those features.
I think Github issues are a bit too lightweight perhaps, so I'm not actively promoting option E, just lifting it up as a real alternative.

As an example how would you implement the security issue visibility with original poster and PMC able to see it in github?

Think they have something in the makings for this, see https://github.com/apache/lucene-solr/security/policy 
Have no idea if you can limit the group who sees them to PMC members though.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com



--