There will be a few false positives for these two JIRA queries (commits that didn't fully fix the issue) but the three I listed above are there:
Check for Git commit: project in (SOLR, LUCENE) AND status in (Open) and fixVersion is not empty and text ~ "in lucene-solr's branch refs/heads/" order by updated Check for older SVN commit: project in (SOLR, LUCENE) AND status in (Open) and fixVersion is not empty and text ~ "in branch 'dev/trunk'" order by updated Kevin Risden On Wed, May 11, 2016 at 12:07 PM, Kevin Risden <compuwizard...@gmail.com> wrote: > Here are three that I just happened upon and was semi familiar with: > * SOLR-8097 > * SOLR-9058 > * SOLR-8878 > > Looks like they just need to be resolved properly and fix the fixVersion. > > there might be just as many open issues w/o a fixVersion that warrant >> equal review/edits. > > > Yea that is probably true. I The recent work on JIRA and "Street Light > Effect" as you say can be good to get JIRA cleaned up further :) > > I don't plan on putting much effort into it currently but definitely > opened my eyes to what more can be done. > > Kevin Risden > > On Wed, May 11, 2016 at 11:49 AM, Chris Hostetter < > hossman_luc...@fucit.org> wrote: > >> >> : I wasn't suggesting a blanket resolve of issues. There are a few that I >> : looked at that should have been resolved and weren't. This would require >> : some manual effort. >> >> can you give some examples? >> >> I was reading "resolved" as "FIXED" but if you're talking about issues >> that could/should be marked WONT_FIX or CANT_REPRO or DUP then i suspect >> you're just falling for the "Street Light Effect" ... the recent work and >> 6.0 happened to catch your eye, and you notice some of those open 6.0 >> issues could/should be resolved, but that doesn't mean there is anything >> special about open issues with 6.0 set on them ... there might be just as >> many open issues w/o a fixVersion that warrant equal review/edits. >> >> : Since there isn't a problem here that open and fixVersion doesn't mean >> : anything together, I'm fine with just leaving as is. >> >> I don't think there is, and i don't subscribe any meaning to it, but >> that's just my opinion. >> >> if other folks *want* to subscribe meaning to it that will be an uphill >> battle unless some work is done to change our workflow and lock down jira >> to prevent arbitrary fixVersons from bieng added to issues. >> >> >> -Hoss >> http://www.lucidworks.com/ >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> >
