You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by David Smiley <da...@gmail.com> on 2017/05/24 15:16:24 UTC
Re: Strange Solr JIRA versions (Lucene too!)
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 <ca...@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 <ma...@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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com
Re: Strange Solr JIRA versions (Lucene too!)
Posted by David Smiley <da...@gmail.com>.
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 <da...@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 <da...@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 <ca...@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 <ma...@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-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@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
Re: Strange Solr JIRA versions (Lucene too!)
Posted by David Smiley <da...@gmail.com>.
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 <da...@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 <ca...@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 <ma...@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-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@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