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 <[EMAIL PROTECTED]> wrote:
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB