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 <gadre.s...@gmail.com> 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 <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 >>> >>> >> > -- Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com
