Thanks for researching the state of our JIRA issues and summarizing the
situation for us.
> Patch Available JIRA state
> 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.
On Fri, May 12, 2017 at 12:31 PM Hrishikesh Gadre <[EMAIL PROTECTED]>
> >>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 <[EMAIL PROTECTED]> 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.
>> On Fri, Apr 28, 2017 at 3:33 PM, Shawn Heisey <[EMAIL PROTECTED]>
>>> 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 =
>>> > 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.
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker