JIRA Status - Finding Patch Submissions

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

JIRA Status - Finding Patch Submissions

Mike Drob-3
Devs,

Does anybody have good JIRA filters or processes for finding issues with patches available and attached, or maybe with open pull requests for them? I was talking to a few folks and we remarked how patches can sometimes sit on issues for a long time, and this seems like a wasted opportunity when it happens.

If the patch sits for too long, it can be discouraging to new contributors. But it is also undesirable for us to let code rot happen like this, since they may be fixes for bugs that we haven't run into ourselves yet.

Other projects use a Jira "patch available" status, or rely mostly on GitHub PRs, or have other mechanisms for improving visibility of pending contributions. I don't know which method is best, and am curious what the rest of the community thinks. Maybe this is already a solved issue.

Mike
Reply | Threaded
Open this post in threaded view
|

Re: JIRA Status - Finding Patch Submissions

Alexandre Rafalovitch
There is an "Attachment count" filter, you can say it to be 1+. Not
everything will be a patch, but it is a good first pass. It is under
"More" dropdown.

We also have some Github Integration fields in there, but they don't
seem to be actually doing anything for Solr project.

Regards,
   Alex.
----
http://www.solr-start.com/ - Resources for Solr users, new and experienced


On 27 April 2017 at 16:15, Mike Drob <[hidden email]> wrote:

> Devs,
>
> Does anybody have good JIRA filters or processes for finding issues with
> patches available and attached, or maybe with open pull requests for them? I
> was talking to a few folks and we remarked how patches can sometimes sit on
> issues for a long time, and this seems like a wasted opportunity when it
> happens.
>
> If the patch sits for too long, it can be discouraging to new contributors.
> But it is also undesirable for us to let code rot happen like this, since
> they may be fixes for bugs that we haven't run into ourselves yet.
>
> Other projects use a Jira "patch available" status, or rely mostly on GitHub
> PRs, or have other mechanisms for improving visibility of pending
> contributions. I don't know which method is best, and am curious what the
> rest of the community thinks. Maybe this is already a solved issue.
>
> Mike

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

Reply | Threaded
Open this post in threaded view
|

Re: JIRA Status - Finding Patch Submissions

Mike Drob-3
Thanks for this hint, Alex.

I ran the following JQL to get some idea of our current status:
    project in (lucene, solr) and "Attachment count" > 0 and status = Open

There were 1500 results.

1500. I couldn't believe it. This is a huge number of patches that are out there.

I did a spot check, thinking that a lot of these might be bug reports with error logs or screen shots attached, but nope. These are mostly patches. I'm going to try starting with the oldest ones to see if they can be rebase, have already been committed, or generally try to triage them. Would appreciate any volunteers that want to help.

Mike

On Thu, Apr 27, 2017 at 3:21 PM, Alexandre Rafalovitch <[hidden email]> wrote:
There is an "Attachment count" filter, you can say it to be 1+. Not
everything will be a patch, but it is a good first pass. It is under
"More" dropdown.

We also have some Github Integration fields in there, but they don't
seem to be actually doing anything for Solr project.

Regards,
   Alex.
----
http://www.solr-start.com/ - Resources for Solr users, new and experienced


On 27 April 2017 at 16:15, Mike Drob <[hidden email]> wrote:
> Devs,
>
> Does anybody have good JIRA filters or processes for finding issues with
> patches available and attached, or maybe with open pull requests for them? I
> was talking to a few folks and we remarked how patches can sometimes sit on
> issues for a long time, and this seems like a wasted opportunity when it
> happens.
>
> If the patch sits for too long, it can be discouraging to new contributors.
> But it is also undesirable for us to let code rot happen like this, since
> they may be fixes for bugs that we haven't run into ourselves yet.
>
> Other projects use a Jira "patch available" status, or rely mostly on GitHub
> PRs, or have other mechanisms for improving visibility of pending
> contributions. I don't know which method is best, and am curious what the
> rest of the community thinks. Maybe this is already a solved issue.
>
> Mike

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


Reply | Threaded
Open this post in threaded view
|

Re: JIRA Status - Finding Patch Submissions

Mike Drob-3
So I started going through old JIRAs, and realized I don't have permission to close duplicates. Could I have more JIRA permissions to complete this task? I know some projects have given non-committers additional JIRA roles for those willing to do JIRA maintenance as a contribution.

Alternatively, I can leave notes on them and somebody with more JIRA karma can do a second pass to handle the cleanup.

Thanks,
Mike

On Fri, Apr 28, 2017 at 10:42 AM, Mike Drob <[hidden email]> wrote:
Thanks for this hint, Alex.

I ran the following JQL to get some idea of our current status:
    project in (lucene, solr) and "Attachment count" > 0 and status = Open

There were 1500 results.

1500. I couldn't believe it. This is a huge number of patches that are out there.

I did a spot check, thinking that a lot of these might be bug reports with error logs or screen shots attached, but nope. These are mostly patches. I'm going to try starting with the oldest ones to see if they can be rebase, have already been committed, or generally try to triage them. Would appreciate any volunteers that want to help.

Mike

On Thu, Apr 27, 2017 at 3:21 PM, Alexandre Rafalovitch <[hidden email]> wrote:
There is an "Attachment count" filter, you can say it to be 1+. Not
everything will be a patch, but it is a good first pass. It is under
"More" dropdown.

We also have some Github Integration fields in there, but they don't
seem to be actually doing anything for Solr project.

Regards,
   Alex.
----
http://www.solr-start.com/ - Resources for Solr users, new and experienced


On 27 April 2017 at 16:15, Mike Drob <[hidden email]> wrote:
> Devs,
>
> Does anybody have good JIRA filters or processes for finding issues with
> patches available and attached, or maybe with open pull requests for them? I
> was talking to a few folks and we remarked how patches can sometimes sit on
> issues for a long time, and this seems like a wasted opportunity when it
> happens.
>
> If the patch sits for too long, it can be discouraging to new contributors.
> But it is also undesirable for us to let code rot happen like this, since
> they may be fixes for bugs that we haven't run into ourselves yet.
>
> Other projects use a Jira "patch available" status, or rely mostly on GitHub
> PRs, or have other mechanisms for improving visibility of pending
> contributions. I don't know which method is best, and am curious what the
> rest of the community thinks. Maybe this is already a solved issue.
>
> Mike

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



Reply | Threaded
Open this post in threaded view
|

Re: JIRA Status - Finding Patch Submissions

Shawn Heisey-2
In reply to this post by Mike Drob-3
On 4/28/2017 9:42 AM, Mike Drob wrote:

> Thanks for this hint, Alex.
>
> I ran the following JQL to get some idea of our current status:
>     project in (lucene, solr) and "Attachment count" > 0 and status = Open
>
> There were 1500 results.
>
> 1500. I couldn't believe it. This is a huge number of patches that are
> out there.
>
> I did a spot check, thinking that a lot of these might be bug reports
> with error logs or screen shots attached, but nope. These are mostly
> patches. I'm going to try starting with the oldest ones to see if they
> can be rebase, have already been committed, or generally try to triage
> them. Would appreciate any volunteers that want to help.

This doesn't surprise me at all.  Many users submit patches for issues
they encounter, but for one reason or another, no committer action ever
happens.  There are many possible reasons.

1) The patch has bugs or some other problem that makes it unacceptable.
2) When the issue/patch is reviewed, one of these situations exists:
 a) Committers don't think it's worth pursuing.
 b) The code is behaving as designed.
 c) The committer cannot reproduce the problem.
 d) The committer doesn't understand the problem.
 e) The committer doesn't think it's actually a problem.
 f) A workaround exists that is just as effective as the patch.
3) Nobody has had time to review the issue/patch.

In some of these situations, the reviewing committer should probably
close the issue with an appropriate reason ... but issue triage is a
difficult and unrewarding job.  Sometimes it just doesn't happen.

Thanks,
Shawn


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

Reply | Threaded
Open this post in threaded view
|

Re: JIRA Status - Finding Patch Submissions

Mike Drob-3
Wanted to follow up on this, since I've been steadily working away at old JIRA issues when I have some time for them. I think read through 100s of issues and closed about 20 as either duplicates or already committed, which is a tiny drop in the ocean of what we have open. In an attempt to cut the task to a more manageable size, I only looked at Solr issues.

I'd like to adjust my earlier statement that most of the attachments are patches. Most of the really old attachments are patches, the mid-age ones are bug reports (indices, screen captures, logs) and the recent ones being actively worked are patches again. So, the situation isn't as bad as I imagined it at first. For a lot of these old issues, there's not much to be done going forward. I don't expect to have much traction asking contributors to rebase their patches from 1.x, 3.x or even 4.x onto the current code line, and without that many of them are just unworkable.

For current patches, I think we could really benefit from a Patch Available JIRA state. It would be a bright big flag for committers, instead of making contributors have to hound us periodically to look. Additionally, we could use that to start running precommit checks on Jenkins whenever a new patch is put up. See Apache Yetus for how this might work.

Is there interest in the community for this path? I'm personally a big fan of enabling static analysis and always like to explore ways to improve in that area.

Mike

On Fri, Apr 28, 2017 at 3:33 PM, Shawn Heisey <[hidden email]> wrote:
On 4/28/2017 9:42 AM, Mike Drob wrote:
> Thanks for this hint, Alex.
>
> I ran the following JQL to get some idea of our current status:
>     project in (lucene, solr) and "Attachment count" > 0 and status = Open
>
> There were 1500 results.
>
> 1500. I couldn't believe it. This is a huge number of patches that are
> out there.
>
> I did a spot check, thinking that a lot of these might be bug reports
> with error logs or screen shots attached, but nope. These are mostly
> patches. I'm going to try starting with the oldest ones to see if they
> can be rebase, have already been committed, or generally try to triage
> them. Would appreciate any volunteers that want to help.

This doesn't surprise me at all.  Many users submit patches for issues
they encounter, but for one reason or another, no committer action ever
happens.  There are many possible reasons.

1) The patch has bugs or some other problem that makes it unacceptable.
2) When the issue/patch is reviewed, one of these situations exists:
 a) Committers don't think it's worth pursuing.
 b) The code is behaving as designed.
 c) The committer cannot reproduce the problem.
 d) The committer doesn't understand the problem.
 e) The committer doesn't think it's actually a problem.
 f) A workaround exists that is just as effective as the patch.
3) Nobody has had time to review the issue/patch.

In some of these situations, the reviewing committer should probably
close the issue with an appropriate reason ... but issue triage is a
difficult and unrewarding job.  Sometimes it just doesn't happen.

Thanks,
Shawn


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


Reply | Threaded
Open this post in threaded view
|

Re: JIRA Status - Finding Patch Submissions

Hrishikesh Gadre-3
>>For current patches, I think we could really benefit from a Patch Available JIRA state. It would be a bright big flag for committers, instead of making contributors have to hound us periodically to look. Additionally, we could use that to start running precommit checks on Jenkins whenever a new patch is put up. See Apache Yetus for how this might work.

+1. We should also consider running unit tests as part of the process.


On Thu, May 11, 2017 at 1:54 PM, Mike Drob <[hidden email]> wrote:
Wanted to follow up on this, since I've been steadily working away at old JIRA issues when I have some time for them. I think read through 100s of issues and closed about 20 as either duplicates or already committed, which is a tiny drop in the ocean of what we have open. In an attempt to cut the task to a more manageable size, I only looked at Solr issues.

I'd like to adjust my earlier statement that most of the attachments are patches. Most of the really old attachments are patches, the mid-age ones are bug reports (indices, screen captures, logs) and the recent ones being actively worked are patches again. So, the situation isn't as bad as I imagined it at first. For a lot of these old issues, there's not much to be done going forward. I don't expect to have much traction asking contributors to rebase their patches from 1.x, 3.x or even 4.x onto the current code line, and without that many of them are just unworkable.

For current patches, I think we could really benefit from a Patch Available JIRA state. It would be a bright big flag for committers, instead of making contributors have to hound us periodically to look. Additionally, we could use that to start running precommit checks on Jenkins whenever a new patch is put up. See Apache Yetus for how this might work.

Is there interest in the community for this path? I'm personally a big fan of enabling static analysis and always like to explore ways to improve in that area.

Mike

On Fri, Apr 28, 2017 at 3:33 PM, Shawn Heisey <[hidden email]> wrote:
On 4/28/2017 9:42 AM, Mike Drob wrote:
> Thanks for this hint, Alex.
>
> I ran the following JQL to get some idea of our current status:
>     project in (lucene, solr) and "Attachment count" > 0 and status = Open
>
> There were 1500 results.
>
> 1500. I couldn't believe it. This is a huge number of patches that are
> out there.
>
> I did a spot check, thinking that a lot of these might be bug reports
> with error logs or screen shots attached, but nope. These are mostly
> patches. I'm going to try starting with the oldest ones to see if they
> can be rebase, have already been committed, or generally try to triage
> them. Would appreciate any volunteers that want to help.

This doesn't surprise me at all.  Many users submit patches for issues
they encounter, but for one reason or another, no committer action ever
happens.  There are many possible reasons.

1) The patch has bugs or some other problem that makes it unacceptable.
2) When the issue/patch is reviewed, one of these situations exists:
 a) Committers don't think it's worth pursuing.
 b) The code is behaving as designed.
 c) The committer cannot reproduce the problem.
 d) The committer doesn't understand the problem.
 e) The committer doesn't think it's actually a problem.
 f) A workaround exists that is just as effective as the patch.
3) Nobody has had time to review the issue/patch.

In some of these situations, the reviewing committer should probably
close the issue with an appropriate reason ... but issue triage is a
difficult and unrewarding job.  Sometimes it just doesn't happen.

Thanks,
Shawn


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



Reply | Threaded
Open this post in threaded view
|

Re: JIRA Status - Finding Patch Submissions

david.w.smiley@gmail.com
Thanks for researching the state of our JIRA issues and summarizing the situation for us.

> Patch Available JIRA state

+1

We should also consider running unit tests as part of the process.

+1 That'd be cool!  Hopefully without generating comments that trigger email/watcher notifications and thus no more dev list traffic.

> Apache Yetus

I'm not sure what to make of it... perhaps you can make a specific proposal.

~ David

On Fri, May 12, 2017 at 12:31 PM Hrishikesh Gadre <[hidden email]> wrote:
>>For current patches, I think we could really benefit from a Patch Available JIRA state. It would be a bright big flag for committers, instead of making contributors have to hound us periodically to look. Additionally, we could use that to start running precommit checks on Jenkins whenever a new patch is put up. See Apache Yetus for how this might work.

+1. We should also consider running unit tests as part of the process.


On Thu, May 11, 2017 at 1:54 PM, Mike Drob <[hidden email]> wrote:
Wanted to follow up on this, since I've been steadily working away at old JIRA issues when I have some time for them. I think read through 100s of issues and closed about 20 as either duplicates or already committed, which is a tiny drop in the ocean of what we have open. In an attempt to cut the task to a more manageable size, I only looked at Solr issues.

I'd like to adjust my earlier statement that most of the attachments are patches. Most of the really old attachments are patches, the mid-age ones are bug reports (indices, screen captures, logs) and the recent ones being actively worked are patches again. So, the situation isn't as bad as I imagined it at first. For a lot of these old issues, there's not much to be done going forward. I don't expect to have much traction asking contributors to rebase their patches from 1.x, 3.x or even 4.x onto the current code line, and without that many of them are just unworkable.

For current patches, I think we could really benefit from a Patch Available JIRA state. It would be a bright big flag for committers, instead of making contributors have to hound us periodically to look. Additionally, we could use that to start running precommit checks on Jenkins whenever a new patch is put up. See Apache Yetus for how this might work.

Is there interest in the community for this path? I'm personally a big fan of enabling static analysis and always like to explore ways to improve in that area.

Mike

On Fri, Apr 28, 2017 at 3:33 PM, Shawn Heisey <[hidden email]> wrote:
On 4/28/2017 9:42 AM, Mike Drob wrote:
> Thanks for this hint, Alex.
>
> I ran the following JQL to get some idea of our current status:
>     project in (lucene, solr) and "Attachment count" > 0 and status = Open
>
> There were 1500 results.
>
> 1500. I couldn't believe it. This is a huge number of patches that are
> out there.
>
> I did a spot check, thinking that a lot of these might be bug reports
> with error logs or screen shots attached, but nope. These are mostly
> patches. I'm going to try starting with the oldest ones to see if they
> can be rebase, have already been committed, or generally try to triage
> them. Would appreciate any volunteers that want to help.

This doesn't surprise me at all.  Many users submit patches for issues
they encounter, but for one reason or another, no committer action ever
happens.  There are many possible reasons.

1) The patch has bugs or some other problem that makes it unacceptable.
2) When the issue/patch is reviewed, one of these situations exists:
 a) Committers don't think it's worth pursuing.
 b) The code is behaving as designed.
 c) The committer cannot reproduce the problem.
 d) The committer doesn't understand the problem.
 e) The committer doesn't think it's actually a problem.
 f) A workaround exists that is just as effective as the patch.
3) Nobody has had time to review the issue/patch.

In some of these situations, the reviewing committer should probably
close the issue with an appropriate reason ... but issue triage is a
difficult and unrewarding job.  Sometimes it just doesn't happen.

Thanks,
Shawn


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



--
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
Reply | Threaded
Open this post in threaded view
|

Re: JIRA Status - Finding Patch Submissions

Tomás Fernández Löbbe
> Additionally, we could use that to start running precommit checks on Jenkins whenever a new patch is put up.
This is a good idea, but we don't want to do this for every patch I'd say. We encourage people to submit patches early, probably with failing tests and nocommits. We probably want an explicit trigger.
> Patch Available JIRA state
In your mind, who is setting this state? automatically or by the user? I fear this could just become an extra step that could complicate the process
> See Apache Yetus for how this might work
Didn't know it, it looks like the right tool. +1



On Sat, May 13, 2017 at 8:06 PM, David Smiley <[hidden email]> wrote:
Thanks for researching the state of our JIRA issues and summarizing the situation for us.

> Patch Available JIRA state

+1

We should also consider running unit tests as part of the process.

+1 That'd be cool!  Hopefully without generating comments that trigger email/watcher notifications and thus no more dev list traffic.

> Apache Yetus

I'm not sure what to make of it... perhaps you can make a specific proposal.

~ David

On Fri, May 12, 2017 at 12:31 PM Hrishikesh Gadre <[hidden email]> wrote:
>>For current patches, I think we could really benefit from a Patch Available JIRA state. It would be a bright big flag for committers, instead of making contributors have to hound us periodically to look. Additionally, we could use that to start running precommit checks on Jenkins whenever a new patch is put up. See Apache Yetus for how this might work.

+1. We should also consider running unit tests as part of the process.


On Thu, May 11, 2017 at 1:54 PM, Mike Drob <[hidden email]> wrote:
Wanted to follow up on this, since I've been steadily working away at old JIRA issues when I have some time for them. I think read through 100s of issues and closed about 20 as either duplicates or already committed, which is a tiny drop in the ocean of what we have open. In an attempt to cut the task to a more manageable size, I only looked at Solr issues.

I'd like to adjust my earlier statement that most of the attachments are patches. Most of the really old attachments are patches, the mid-age ones are bug reports (indices, screen captures, logs) and the recent ones being actively worked are patches again. So, the situation isn't as bad as I imagined it at first. For a lot of these old issues, there's not much to be done going forward. I don't expect to have much traction asking contributors to rebase their patches from 1.x, 3.x or even 4.x onto the current code line, and without that many of them are just unworkable.

For current patches, I think we could really benefit from a Patch Available JIRA state. It would be a bright big flag for committers, instead of making contributors have to hound us periodically to look. Additionally, we could use that to start running precommit checks on Jenkins whenever a new patch is put up. See Apache Yetus for how this might work.

Is there interest in the community for this path? I'm personally a big fan of enabling static analysis and always like to explore ways to improve in that area.

Mike

On Fri, Apr 28, 2017 at 3:33 PM, Shawn Heisey <[hidden email]> wrote:
On 4/28/2017 9:42 AM, Mike Drob wrote:
> Thanks for this hint, Alex.
>
> I ran the following JQL to get some idea of our current status:
>     project in (lucene, solr) and "Attachment count" > 0 and status = Open
>
> There were 1500 results.
>
> 1500. I couldn't believe it. This is a huge number of patches that are
> out there.
>
> I did a spot check, thinking that a lot of these might be bug reports
> with error logs or screen shots attached, but nope. These are mostly
> patches. I'm going to try starting with the oldest ones to see if they
> can be rebase, have already been committed, or generally try to triage
> them. Would appreciate any volunteers that want to help.

This doesn't surprise me at all.  Many users submit patches for issues
they encounter, but for one reason or another, no committer action ever
happens.  There are many possible reasons.

1) The patch has bugs or some other problem that makes it unacceptable.
2) When the issue/patch is reviewed, one of these situations exists:
 a) Committers don't think it's worth pursuing.
 b) The code is behaving as designed.
 c) The committer cannot reproduce the problem.
 d) The committer doesn't understand the problem.
 e) The committer doesn't think it's actually a problem.
 f) A workaround exists that is just as effective as the patch.
3) Nobody has had time to review the issue/patch.

In some of these situations, the reviewing committer should probably
close the issue with an appropriate reason ... but issue triage is a
difficult and unrewarding job.  Sometimes it just doesn't happen.

Thanks,
Shawn


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



--
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker

Reply | Threaded
Open this post in threaded view
|

Re: JIRA Status - Finding Patch Submissions

Mike Drob-3
David, what do you mean by

Hopefully without generating comments that trigger email/watcher notifications and thus no more dev list traffic.

How else other than a comment could the system communicate results back to the user? Or do you mean that whatever runs should post a comment, but suppress email notification somehow. I'm not sure that last bit is possible... would have to talk to INFRA about it maybe.

I'm not sure what to make of it... perhaps you can make a specific proposal.

Nothing concrete yet, but it's likely a good candidate tool for the job here. There are already ASF Jenkins jobs to look for JIRA updates on other projects, download patches, and try to run precommit checks. If this is something we were interested in, I think it wouldn't be too hard to add ourselves to the list. I'd much rather use an existing tool than worry abotu coming up with something myself.


Tomas,

I think you're asking for two opposed things here. If we encourage people to submit lots of patches, some of which may not be ready for automated verification, then it seems like we must have a step for them to take to indicate that a specific patch is "ready"

This could be a submitter changing state to "Patch Available" or could be a naming convention (PATCH-XXX v PATCH-XXX-WIP?) or could be something else that I haven't imagined. I'm totally in agreement though that if somebody posts a knowingly incomplete patch there's very little benefit from getting scolded by an automated tool (and potentially even some harm).

If the state is set automatically, how do we know when to set it?

Maybe this could be an extra (optional?) step for the committer looking at the issue? Change to "Patch Available" triggers a run on the most recent attached patch?

Mike

On Wed, May 17, 2017 at 12:28 PM, Tomás Fernández Löbbe <[hidden email]> wrote:
> Additionally, we could use that to start running precommit checks on Jenkins whenever a new patch is put up.
This is a good idea, but we don't want to do this for every patch I'd say. We encourage people to submit patches early, probably with failing tests and nocommits. We probably want an explicit trigger.
> Patch Available JIRA state
In your mind, who is setting this state? automatically or by the user? I fear this could just become an extra step that could complicate the process
> See Apache Yetus for how this might work
Didn't know it, it looks like the right tool. +1



On Sat, May 13, 2017 at 8:06 PM, David Smiley <[hidden email]> wrote:
Thanks for researching the state of our JIRA issues and summarizing the situation for us.

> Patch Available JIRA state

+1

We should also consider running unit tests as part of the process.

+1 That'd be cool!  Hopefully without generating comments that trigger email/watcher notifications and thus no more dev list traffic.

> Apache Yetus

I'm not sure what to make of it... perhaps you can make a specific proposal.

~ David

On Fri, May 12, 2017 at 12:31 PM Hrishikesh Gadre <[hidden email]> wrote:
>>For current patches, I think we could really benefit from a Patch Available JIRA state. It would be a bright big flag for committers, instead of making contributors have to hound us periodically to look. Additionally, we could use that to start running precommit checks on Jenkins whenever a new patch is put up. See Apache Yetus for how this might work.

+1. We should also consider running unit tests as part of the process.


On Thu, May 11, 2017 at 1:54 PM, Mike Drob <[hidden email]> wrote:
Wanted to follow up on this, since I've been steadily working away at old JIRA issues when I have some time for them. I think read through 100s of issues and closed about 20 as either duplicates or already committed, which is a tiny drop in the ocean of what we have open. In an attempt to cut the task to a more manageable size, I only looked at Solr issues.

I'd like to adjust my earlier statement that most of the attachments are patches. Most of the really old attachments are patches, the mid-age ones are bug reports (indices, screen captures, logs) and the recent ones being actively worked are patches again. So, the situation isn't as bad as I imagined it at first. For a lot of these old issues, there's not much to be done going forward. I don't expect to have much traction asking contributors to rebase their patches from 1.x, 3.x or even 4.x onto the current code line, and without that many of them are just unworkable.

For current patches, I think we could really benefit from a Patch Available JIRA state. It would be a bright big flag for committers, instead of making contributors have to hound us periodically to look. Additionally, we could use that to start running precommit checks on Jenkins whenever a new patch is put up. See Apache Yetus for how this might work.

Is there interest in the community for this path? I'm personally a big fan of enabling static analysis and always like to explore ways to improve in that area.

Mike

On Fri, Apr 28, 2017 at 3:33 PM, Shawn Heisey <[hidden email]> wrote:
On 4/28/2017 9:42 AM, Mike Drob wrote:
> Thanks for this hint, Alex.
>
> I ran the following JQL to get some idea of our current status:
>     project in (lucene, solr) and "Attachment count" > 0 and status = Open
>
> There were 1500 results.
>
> 1500. I couldn't believe it. This is a huge number of patches that are
> out there.
>
> I did a spot check, thinking that a lot of these might be bug reports
> with error logs or screen shots attached, but nope. These are mostly
> patches. I'm going to try starting with the oldest ones to see if they
> can be rebase, have already been committed, or generally try to triage
> them. Would appreciate any volunteers that want to help.

This doesn't surprise me at all.  Many users submit patches for issues
they encounter, but for one reason or another, no committer action ever
happens.  There are many possible reasons.

1) The patch has bugs or some other problem that makes it unacceptable.
2) When the issue/patch is reviewed, one of these situations exists:
 a) Committers don't think it's worth pursuing.
 b) The code is behaving as designed.
 c) The committer cannot reproduce the problem.
 d) The committer doesn't understand the problem.
 e) The committer doesn't think it's actually a problem.
 f) A workaround exists that is just as effective as the patch.
3) Nobody has had time to review the issue/patch.

In some of these situations, the reviewing committer should probably
close the issue with an appropriate reason ... but issue triage is a
difficult and unrewarding job.  Sometimes it just doesn't happen.

Thanks,
Shawn


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



--
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker


Reply | Threaded
Open this post in threaded view
|

Re: JIRA Status - Finding Patch Submissions

Tomás Fernández Löbbe
> This could be a submitter changing state to "Patch Available" or could be a naming convention
Yes, I was thinking on something along those lines too. I've also seen tools triggering by specific comments in Jira. Any way is fine with me.
> If the state is set automatically, how do we know when to set it?
I was just trying to understand what you were proposing really. If we use that as an optional step to trigger the validation it makes sense (although since it's optional, filtering by this state to find issues with patches will not give you a complete view)

On Wed, May 17, 2017 at 4:35 PM, Mike Drob <[hidden email]> wrote:
David, what do you mean by

Hopefully without generating comments that trigger email/watcher notifications and thus no more dev list traffic.

How else other than a comment could the system communicate results back to the user? Or do you mean that whatever runs should post a comment, but suppress email notification somehow. I'm not sure that last bit is possible... would have to talk to INFRA about it maybe.

I'm not sure what to make of it... perhaps you can make a specific proposal.

Nothing concrete yet, but it's likely a good candidate tool for the job here. There are already ASF Jenkins jobs to look for JIRA updates on other projects, download patches, and try to run precommit checks. If this is something we were interested in, I think it wouldn't be too hard to add ourselves to the list. I'd much rather use an existing tool than worry abotu coming up with something myself.


Tomas,

I think you're asking for two opposed things here. If we encourage people to submit lots of patches, some of which may not be ready for automated verification, then it seems like we must have a step for them to take to indicate that a specific patch is "ready"

This could be a submitter changing state to "Patch Available" or could be a naming convention (PATCH-XXX v PATCH-XXX-WIP?) or could be something else that I haven't imagined. I'm totally in agreement though that if somebody posts a knowingly incomplete patch there's very little benefit from getting scolded by an automated tool (and potentially even some harm).

If the state is set automatically, how do we know when to set it?

Maybe this could be an extra (optional?) step for the committer looking at the issue? Change to "Patch Available" triggers a run on the most recent attached patch?

Mike

On Wed, May 17, 2017 at 12:28 PM, Tomás Fernández Löbbe <[hidden email]> wrote:
> Additionally, we could use that to start running precommit checks on Jenkins whenever a new patch is put up.
This is a good idea, but we don't want to do this for every patch I'd say. We encourage people to submit patches early, probably with failing tests and nocommits. We probably want an explicit trigger.
> Patch Available JIRA state
In your mind, who is setting this state? automatically or by the user? I fear this could just become an extra step that could complicate the process
> See Apache Yetus for how this might work
Didn't know it, it looks like the right tool. +1



On Sat, May 13, 2017 at 8:06 PM, David Smiley <[hidden email]> wrote:
Thanks for researching the state of our JIRA issues and summarizing the situation for us.

> Patch Available JIRA state

+1

We should also consider running unit tests as part of the process.

+1 That'd be cool!  Hopefully without generating comments that trigger email/watcher notifications and thus no more dev list traffic.

> Apache Yetus

I'm not sure what to make of it... perhaps you can make a specific proposal.

~ David

On Fri, May 12, 2017 at 12:31 PM Hrishikesh Gadre <[hidden email]> wrote:
>>For current patches, I think we could really benefit from a Patch Available JIRA state. It would be a bright big flag for committers, instead of making contributors have to hound us periodically to look. Additionally, we could use that to start running precommit checks on Jenkins whenever a new patch is put up. See Apache Yetus for how this might work.

+1. We should also consider running unit tests as part of the process.


On Thu, May 11, 2017 at 1:54 PM, Mike Drob <[hidden email]> wrote:
Wanted to follow up on this, since I've been steadily working away at old JIRA issues when I have some time for them. I think read through 100s of issues and closed about 20 as either duplicates or already committed, which is a tiny drop in the ocean of what we have open. In an attempt to cut the task to a more manageable size, I only looked at Solr issues.

I'd like to adjust my earlier statement that most of the attachments are patches. Most of the really old attachments are patches, the mid-age ones are bug reports (indices, screen captures, logs) and the recent ones being actively worked are patches again. So, the situation isn't as bad as I imagined it at first. For a lot of these old issues, there's not much to be done going forward. I don't expect to have much traction asking contributors to rebase their patches from 1.x, 3.x or even 4.x onto the current code line, and without that many of them are just unworkable.

For current patches, I think we could really benefit from a Patch Available JIRA state. It would be a bright big flag for committers, instead of making contributors have to hound us periodically to look. Additionally, we could use that to start running precommit checks on Jenkins whenever a new patch is put up. See Apache Yetus for how this might work.

Is there interest in the community for this path? I'm personally a big fan of enabling static analysis and always like to explore ways to improve in that area.

Mike

On Fri, Apr 28, 2017 at 3:33 PM, Shawn Heisey <[hidden email]> wrote:
On 4/28/2017 9:42 AM, Mike Drob wrote:
> Thanks for this hint, Alex.
>
> I ran the following JQL to get some idea of our current status:
>     project in (lucene, solr) and "Attachment count" > 0 and status = Open
>
> There were 1500 results.
>
> 1500. I couldn't believe it. This is a huge number of patches that are
> out there.
>
> I did a spot check, thinking that a lot of these might be bug reports
> with error logs or screen shots attached, but nope. These are mostly
> patches. I'm going to try starting with the oldest ones to see if they
> can be rebase, have already been committed, or generally try to triage
> them. Would appreciate any volunteers that want to help.

This doesn't surprise me at all.  Many users submit patches for issues
they encounter, but for one reason or another, no committer action ever
happens.  There are many possible reasons.

1) The patch has bugs or some other problem that makes it unacceptable.
2) When the issue/patch is reviewed, one of these situations exists:
 a) Committers don't think it's worth pursuing.
 b) The code is behaving as designed.
 c) The committer cannot reproduce the problem.
 d) The committer doesn't understand the problem.
 e) The committer doesn't think it's actually a problem.
 f) A workaround exists that is just as effective as the patch.
3) Nobody has had time to review the issue/patch.

In some of these situations, the reviewing committer should probably
close the issue with an appropriate reason ... but issue triage is a
difficult and unrewarding job.  Sometimes it just doesn't happen.

Thanks,
Shawn


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



--
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker



Reply | Threaded
Open this post in threaded view
|

Re: JIRA Status - Finding Patch Submissions

david.w.smiley@gmail.com
In reply to this post by Mike Drob-3
On Wed, May 17, 2017 at 7:36 PM Mike Drob <[hidden email]> wrote:
David, what do you mean by

Hopefully without generating comments that trigger email/watcher notifications and thus no more dev list traffic.

How else other than a comment could the system communicate results back to the user? Or do you mean that whatever runs should post a comment, but suppress email notification somehow.

Yes; that.  The rationale being that if someone posts a patch, it'll become inevitable that there will be a follow-up bot comment.  It's not a big deal though.
 
I'm not sure that last bit is possible... would have to talk to INFRA about it maybe.

I'm not sure what to make of it... perhaps you can make a specific proposal.

Nothing concrete yet, but it's likely a good candidate tool for the job here. There are already ASF Jenkins jobs to look for JIRA updates on other projects, download patches, and try to run precommit checks. If this is something we were interested in, I think it wouldn't be too hard to add ourselves to the list. I'd much rather use an existing tool than worry abotu coming up with something myself.

+1 to that last bit especially.  No reason to reinvent any wheels here.
 
<snip>
If the state is set automatically, how do we know when to set it?

Maybe this could be an extra (optional?) step for the committer looking at the issue? Change to "Patch Available" triggers a run on the most recent attached patch?

+1 nice idea; seems straight-forward compared to other ideas.  I don't think we need to limit this transition to only committers though; even the submitter might do it to demonstrate their patch is ready.
 
Cheers,
~ David
--
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
Reply | Threaded
Open this post in threaded view
|

Re: JIRA Status - Finding Patch Submissions

Mano Kovacs
Hi,

Mike pointed to this thread after I created SOLR-10912 (I missed this conversation). I am for running validations automatically against patches, similarly what Hadoop or Oziee (and probably others) have. I don't have strong opinion what and when to check, but I believe that it could be finalized or adjusted later.

If that is ok with you, I would create a pilot using Yetus and some of our existing validations, running on sample jiras. That would give us opportunity to workout the details of the ideal solution.

Regards,
Mano



On Thu, May 18, 2017 at 4:10 AM, David Smiley <[hidden email]> wrote:
On Wed, May 17, 2017 at 7:36 PM Mike Drob <[hidden email]> wrote:
David, what do you mean by

Hopefully without generating comments that trigger email/watcher notifications and thus no more dev list traffic.

How else other than a comment could the system communicate results back to the user? Or do you mean that whatever runs should post a comment, but suppress email notification somehow.

Yes; that.  The rationale being that if someone posts a patch, it'll become inevitable that there will be a follow-up bot comment.  It's not a big deal though.
 
I'm not sure that last bit is possible... would have to talk to INFRA about it maybe.

I'm not sure what to make of it... perhaps you can make a specific proposal.

Nothing concrete yet, but it's likely a good candidate tool for the job here. There are already ASF Jenkins jobs to look for JIRA updates on other projects, download patches, and try to run precommit checks. If this is something we were interested in, I think it wouldn't be too hard to add ourselves to the list. I'd much rather use an existing tool than worry abotu coming up with something myself.

+1 to that last bit especially.  No reason to reinvent any wheels here.
 
<snip>
If the state is set automatically, how do we know when to set it?

Maybe this could be an extra (optional?) step for the committer looking at the issue? Change to "Patch Available" triggers a run on the most recent attached patch?

+1 nice idea; seems straight-forward compared to other ideas.  I don't think we need to limit this transition to only committers though; even the submitter might do it to demonstrate their patch is ready.
 
Cheers,
~ David
--
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker

Reply | Threaded
Open this post in threaded view
|

Re: JIRA Status - Finding Patch Submissions

Allen Wittenauer-2
In reply to this post by Mike Drob-3
On 2017-05-17 19:10 (-0700), David Smiley <[hidden email]> wrote:
> > How else other than a comment could the system communicate results back to
> > the user? Or do you mean that whatever runs should post a comment, but
> > suppress email notification somehow.
> >
>
> Yes; that.  The rationale being that if someone posts a patch, it'll become
> inevitable that there will be a follow-up bot comment.  It's not a big deal
> though.

        Hi.  I hope you don't mind if I chime in here. :)

        When the original JIRA support for Apache Yetus was written, we actually looked at a way to prevent comments from getting emailed out.  At that point in time, the REST interface lacked the functionality. Much sadness. But good news: JIRA 7.2.0 does include the necessary magic:  https://jira.atlassian.com/browse/JRASERVER-34423  .  Now we just have to wait until the ASF instance gets upgraded.

> > If the state is set automatically, how do we know when to set it?
> >
> > Maybe this could be an extra (optional?) step for the committer looking at
> > the issue? Change to "Patch Available" triggers a run on the most recent
> > attached patch?
> >
>
> +1 nice idea; seems straight-forward compared to other ideas.  I don't
> think we need to limit this transition to only committers though; even the
> submitter might do it to demonstrate their patch is ready.

        Just to fill in some blanks as to how the current projects are using it....  

        Submitter sets JIRA issue to Patch Available. There is a job on ASF Jenkins called "Precommit-Admin" that uses a JIRA filter to look for (group of projects)+"Patch Available"+(updated time frame).  It then submits any found issues to Precommit-(project)-build with the issue id.  For Solr, Lucene, or any other project, it's just a matter of adding your project to the JIRA filter and creating the precommit job.  Manually running a job is simple, because you just use that project's dedicated precommit job and a supplied id.

        [I'm in the process of "rescuing" the precommit-admin codebase from within the (old) Hadoop svn tree into the much more public Yetus source tree, writing documentation, etc.  Right now, this is all tribal knowledge. :( ]

         


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

Reply | Threaded
Open this post in threaded view
|

Re: JIRA Status - Finding Patch Submissions

Mano Kovacs
Thank you Allen for the info!

I made some progress with the integration for Solr and had several test-runs on SOLR-10912 and SOLR-10783.

I have a WIP script [1] that can executed on a single issue id so it could be used for Precommit jenkins jobs. It...
- runs test4tests, notification if no tests were added or updated (comes with Yetus)
- runs "@author" tag check (comes with Yetus)
- runs the subtasks of "validate" ant action (check lucene version, rat, license check, forbidden apis) for solr and lucene folder, depending on the changed files
- runs tests in the modules that were affected. It is still an open discussion what should be tested.

1. I am looking forward to getting feedback, input, ideas!
2. If this is something that we want to pursuit, is there someone who could help me with Jenkins and Jira setup?

Thanks,
Mano


On Tue, Jun 20, 2017 at 8:25 AM, Allen Wittenauer <[hidden email]> wrote:
On 2017-05-17 19:10 (-0700), David Smiley <[hidden email]> wrote:
> > How else other than a comment could the system communicate results back to
> > the user? Or do you mean that whatever runs should post a comment, but
> > suppress email notification somehow.
> >
>
> Yes; that.  The rationale being that if someone posts a patch, it'll become
> inevitable that there will be a follow-up bot comment.  It's not a big deal
> though.

        Hi.  I hope you don't mind if I chime in here. :)

        When the original JIRA support for Apache Yetus was written, we actually looked at a way to prevent comments from getting emailed out.  At that point in time, the REST interface lacked the functionality. Much sadness. But good news: JIRA 7.2.0 does include the necessary magic:  https://jira.atlassian.com/browse/JRASERVER-34423  .  Now we just have to wait until the ASF instance gets upgraded.

> > If the state is set automatically, how do we know when to set it?
> >
> > Maybe this could be an extra (optional?) step for the committer looking at
> > the issue? Change to "Patch Available" triggers a run on the most recent
> > attached patch?
> >
>
> +1 nice idea; seems straight-forward compared to other ideas.  I don't
> think we need to limit this transition to only committers though; even the
> submitter might do it to demonstrate their patch is ready.

        Just to fill in some blanks as to how the current projects are using it....

        Submitter sets JIRA issue to Patch Available. There is a job on ASF Jenkins called "Precommit-Admin" that uses a JIRA filter to look for (group of projects)+"Patch Available"+(updated time frame).  It then submits any found issues to Precommit-(project)-build with the issue id.  For Solr, Lucene, or any other project, it's just a matter of adding your project to the JIRA filter and creating the precommit job.  Manually running a job is simple, because you just use that project's dedicated precommit job and a supplied id.

        [I'm in the process of "rescuing" the precommit-admin codebase from within the (old) Hadoop svn tree into the much more public Yetus source tree, writing documentation, etc.  Right now, this is all tribal knowledge. :( ]




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