Maintaining this seems to be a pain; I wonder if it's worth bothering with the distinction between "Resolved" and "Closed"? Examining the "fix version" would indicate what release has the code (if it was a code thing and not some infra thing).
Your 600 day buffer seems safe since it hasn't been that long for master/8.0 code to have been committed without being released. There are numerous non-fix resolution statuses like "Duplicate" that an issue ought not to sit idle in Resolved yet not yet Closed states. You could consider going after these too. Whatever you do will one day be repeated. BTW when you do your bulk closing, please add a comment with a searchable phrase should we want to easily bulk revert via a search. This approach has been done in the past for bulk changes. It could be something like "2018-07-05 Bulk close resolved, not commented on in 600 days" ~ David On Thu, Jul 5, 2018 at 5:54 PM Walter Underwood <[email protected]> wrote: > Thanks. > > Update the version if that helps people. It is a new feature and still > hasn’t been implemented or obsoleted. > > There are enough changes in edismax that we’ll need to re-implement the > changes. > > wunder > Walter Underwood > [email protected] > http://observer.wunderwood.org/ (my blog) > > On Jul 5, 2018, at 2:51 PM, Alexandre Rafalovitch <[email protected]> > wrote: > > Yes, I skipped over it in the manual review. Would it make sense to > update the version affected to the latest though if the issue is still > open? I've also updated the issue title to say eDisMax as requested. > > Regards, > Alex. > > On 5 July 2018 at 17:46, Walter Underwood <[email protected]> wrote: > > Please do not close SOLR-629. I’ve been submitting patches and trying to > get > someone to commit that for years. This is blocking us from upgrading one of > our clusters from 4.10.4. > > https://issues.apache.org/jira/browse/SOLR-629 > > wunder > Walter Underwood > [email protected] > http://observer.wunderwood.org/ (my blog) > > On Jul 5, 2018, at 2:33 PM, Alexandre Rafalovitch <[email protected]> > wrote: > > Ok. I found Bulk Transition to Close workflow. > > Would it make sense to transition all Solr 'Resolved' issues older > than (say) 600 days to 'Closed' state? project = SOLR AND status = > Resolved AND "Last public comment date" <= -600d ? Without emails, as > I suspect I already annoyed a bunch of people with my cleanup. > > That's 1500 issues we are really unlikely to touch ever again. > > Thoughts? > > Regards, > Alex. > > > On 5 July 2018 at 14:32, Alexandre Rafalovitch <[email protected]> wrote: > > Do I have a JIRA permission/procedure to do the bulk closures? I > wasn't sure. And definitely did not want to step on any RM feet, given > that I know nothing about those processes. > > As is, for now, I am mostly trying to clean out the ancient weeds, > those that just get in the way. > > Regards, > Alex. > > On 5 July 2018 at 14:27, David Smiley <[email protected]> wrote: > > Thanks for doing the JIRA gardening. > > By the way, there were past releases where the RM apparently forgot to > perform the step of bulk closing resolved issues. That can be done without > sending a notification, by the way -- thus no list noise. You might want > to > start with rectifying this? > > ~ David > > On Thu, Jul 5, 2018 at 1:49 PM Alexandre Rafalovitch <[email protected]> > wrote: > > > Hi, > > I am manually reviewing and closing issues marked Resolved against 7.4 > and earlier as well as in versions unknown. > > I am leaving those I can't quite figure out the "true final" status of > as is. Like a patch is in the tree, but it is not marked with a > version and nothing in CHANGES file. > > I hope this approach is ok. I apologize in advance if I mis-read > somebody's intention. Feel free to 'reopened' the case (Jira flow > state transition name needs fixing too). > > Please let me know if you disagree with this cleanup and/or if you > have a better algorithm to improve searches/statistics for > still-active issues. > > Regards, > Alex. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- > Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker > LinkedIn: http://linkedin.com/in/davidwsmiley | Book: > http://www.solrenterprisesearchserver.com > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > -- Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com
