Lucene devs, lets get on the same page about this issue. Dawid seems to _want_ to use 6.x https://issues.apache.org/jira/browse/LUCENE-7841?focusedCommentId=16024639&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16024639 Christine and I are the only ones to have commented about this pertaining to LUCENE JIRA issues. Lets have this conversation here, not on LUCENE-7841.
~ David On Thu, May 25, 2017 at 1:28 AM David Smiley <david.w.smi...@gmail.com> wrote: > Aha; this problem is a little more than a nuisance... it seems to be why > most of these issues are marked Resolved and not Closed as well. The RM's > release process is to search for JIRA issues with a fix version of the > release version (i.e. 6.6 NOT 6.x). Issues that do not have a real version > then fall through the cracks and remain in a "Resolved" limbo/ambiguity: > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20LUCENE%20AND%20status%20in%20(Resolved)%20AND%20fixVersion%20%3D%206.x%20ORDER%20BY%20fixVersion%20ASC%2C%20assignee%20ASC > And thus it's unclear to users browsing these issues in JIRA for which > version the issue was released in. > > ~ David > > > On Wed, May 24, 2017 at 11:16 AM David Smiley <david.w.smi...@gmail.com> > wrote: > >> It seems this issue applies to Lucene too, and it's more widespread (79 >> issues): >> >> >> https://issues.apache.org/jira/issues/?jql=project%20%3D%20LUCENE%20AND%20status%20in%20(Resolved%2C%20Closed)%20AND%20fixVersion%20in%20(6.x%2C%20branch_6x) >> >> On Fri, Apr 14, 2017 at 9:37 AM Cassandra Targett <casstarg...@gmail.com> >> wrote: >> >>> I noticed these the other day also, and had an email half-wrote that I >>> intended to finish up today. >>> >>> To start, JIRA unfortunately makes this really easy to make a mess of >>> - if you can create or edit an issue, you can just pop in a new value >>> that gets added to the list of open versions. Editing an issue is open >>> to lots of folks - committers, contributors, the reporter of an issue. >>> So, we have high potential for this to be an ongoing problem. >>> >>> But, since only committers can commit patches and are thus the usual >>> resolvers of an issue, committers either aren't paying enough >>> attention to that field when they resolve an issue or there is >>> confusion/difference of understanding about what that field is >>> supposed to mean. >>> >>> There are currently 49 issues for Solr that have these "non-standard" >>> versions [1]. Some date back before the most recent 6.5.0 release, >>> which means there are issues fixed in 6.4 and 6.5 (at least) which >>> don't say so in JIRA. >>> >>> This could be really problematic going forward. We need to agree that >>> when issues are resolved, the fixVersion field is reliable and means >>> the same thing to everyone. >>> >>> IMO we should always use the *next* version that makes sense at that >>> time. So, an issue resolved today would be "6.6" and "master (7.0)". >>> Others may have different points of view on how we should do this, but >>> I think traditionally it's been the way I suggest, so if there is >>> change desired there, we should discuss it. >>> >>> Side note: I know there is some doubt today that 6.6 will ever exist. >>> However, it will be a lot easier to go through JIRA to remove "6.6" >>> from issues that aren't in 6.x than it will be to review >>> issue-by-issue everything that says "6x" or "6.x" or "branch_6x", >>> etc., and figure out when it was actually released. >>> >>> Cassandra >>> >>> [1] Query for JIRA issues: >>> >>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20SOLR%20AND%20status%20in%20(Resolved%2C%20Closed)%20AND%20fixVersion%20in%20(6.x%2C%206x%2C%20branch_6x) >>> >>> On Fri, Apr 14, 2017 at 1:33 AM, Mark Miller <markrmil...@gmail.com> >>> wrote: >>> > Who keeps adding strange JIRA release versions? I've cleaned up >>> strange ones >>> > in the past and they keep coming back. >>> > >>> > Why do we have branch6x, 6x and 6.x and trunk? >>> > >>> > Even if we wanted more than 6.1, 6.2, 6.2.1 and master (7.0), and I >>> don't >>> > think we do, who keeps adding these duplicates? Let's come to some >>> sanity >>> > here. >>> > >>> > - Mark >>> > -- >>> > - Mark >>> > about.me/markrmiller >>> >>> --------------------------------------------------------------------- >>> 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 >> > -- > Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker > LinkedIn: http://linkedin.com/in/davidwsmiley | Book: > http://www.solrenterprisesearchserver.com > -- Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com
