>>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 <md...@apache.org> 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 <apa...@elyograg.org> 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: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> >
