Strange Solr JIRA versions

classic Classic list List threaded Threaded
41 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Strange Solr JIRA versions

Mark Miller-3
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
--
Reply | Threaded
Open this post in threaded view
|

Re: Strange Solr JIRA versions

Cassandra Targett
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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Strange Solr JIRA versions

Mark Miller-3

On Fri, Apr 14, 2017 at 9:37 AM Cassandra Targett <[hidden email]> 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.

Ah, that makes this a lot less baffling I guess.
 

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.

+1!
 

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.

I agree.
 

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.

+1. It also matches how we handle CHANGES afaict.

I wish we could disable the auto creating of versions entirely somehow, but I guess the next best thing is to raise awareness. It's great to have the correct versions and in the correct ordering.

- Mark
 

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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

--
Reply | Threaded
Open this post in threaded view
|

Re: Strange Solr JIRA versions

Mark Miller-3
Bummer, seems we can't lock this down :( https://jira.atlassian.com/browse/JRASERVER-42068

On Fri, Apr 14, 2017 at 9:42 AM Mark Miller <[hidden email]> wrote:
On Fri, Apr 14, 2017 at 9:37 AM Cassandra Targett <[hidden email]> 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.

Ah, that makes this a lot less baffling I guess.
 

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.

+1!
 

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.

I agree.
 

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.

+1. It also matches how we handle CHANGES afaict.

I wish we could disable the auto creating of versions entirely somehow, but I guess the next best thing is to raise awareness. It's great to have the correct versions and in the correct ordering.

- Mark
 

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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

--
--
Reply | Threaded
Open this post in threaded view
|

Re: Strange Solr JIRA versions

Mark Miller-3
Perhaps everyone doesn't need to be a JIRA admin? Like people that add new bad versions in the future ;) This is no fun to cleanup.

- Mark

On Fri, Apr 14, 2017 at 10:23 AM Mark Miller <[hidden email]> wrote:
Bummer, seems we can't lock this down :( https://jira.atlassian.com/browse/JRASERVER-42068

On Fri, Apr 14, 2017 at 9:42 AM Mark Miller <[hidden email]> wrote:
On Fri, Apr 14, 2017 at 9:37 AM Cassandra Targett <[hidden email]> 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.

Ah, that makes this a lot less baffling I guess.
 

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.

+1!
 

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.

I agree.
 

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.

+1. It also matches how we handle CHANGES afaict.

I wish we could disable the auto creating of versions entirely somehow, but I guess the next best thing is to raise awareness. It's great to have the correct versions and in the correct ordering.

- Mark
 

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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

--
--
--
Reply | Threaded
Open this post in threaded view
|

Re: Strange Solr JIRA versions

Mark Miller-3
I wish hossman was still more active in this type of thing. He would have sworn more and fixed it more meticulously and probably earlier. Or maybe he is sick of it after last time. Anyway, I did what I could, preserved the proper versions I could, and it's clean again for now.

I'm halfway serious about the admin thing given you can easily auto create components and versions by accident. Maybe instead of giving it to everyone by default, we should be doing it by request.

- Mark

On Fri, Apr 14, 2017 at 10:29 AM Mark Miller <[hidden email]> wrote:
Perhaps everyone doesn't need to be a JIRA admin? Like people that add new bad versions in the future ;) This is no fun to cleanup.

- Mark

On Fri, Apr 14, 2017 at 10:23 AM Mark Miller <[hidden email]> wrote:
Bummer, seems we can't lock this down :( https://jira.atlassian.com/browse/JRASERVER-42068

On Fri, Apr 14, 2017 at 9:42 AM Mark Miller <[hidden email]> wrote:
On Fri, Apr 14, 2017 at 9:37 AM Cassandra Targett <[hidden email]> 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.

Ah, that makes this a lot less baffling I guess.
 

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.

+1!
 

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.

I agree.
 

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.

+1. It also matches how we handle CHANGES afaict.

I wish we could disable the auto creating of versions entirely somehow, but I guess the next best thing is to raise awareness. It's great to have the correct versions and in the correct ordering.

- Mark
 

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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

--
--
--
--
Reply | Threaded
Open this post in threaded view
|

Re: Strange Solr JIRA versions

Erick Erickson
If you look at the "history" tab on the JIRA you can see who set what
values when. I checked 4-5 of the JIRAS and the person who set those
has a long record of being very conscientious about changes so I'm
certain it's just an awareness issue, at least for that person. I'll
ping....

Which suggests a way to raise awareness going forward: check the
history and send a message.

If that doesn't cure it we can consider harsher measures, although I
don't think forbidding arbitrary labels is "harsh", it's just too bad
we can't.

Erick

On Fri, Apr 14, 2017 at 7:56 AM, Mark Miller <[hidden email]> wrote:

> I wish hossman was still more active in this type of thing. He would have
> sworn more and fixed it more meticulously and probably earlier. Or maybe he
> is sick of it after last time. Anyway, I did what I could, preserved the
> proper versions I could, and it's clean again for now.
>
> I'm halfway serious about the admin thing given you can easily auto create
> components and versions by accident. Maybe instead of giving it to everyone
> by default, we should be doing it by request.
>
> - Mark
>
> On Fri, Apr 14, 2017 at 10:29 AM Mark Miller <[hidden email]> wrote:
>>
>> Perhaps everyone doesn't need to be a JIRA admin? Like people that add new
>> bad versions in the future ;) This is no fun to cleanup.
>>
>> - Mark
>>
>> On Fri, Apr 14, 2017 at 10:23 AM Mark Miller <[hidden email]>
>> wrote:
>>>
>>> Bummer, seems we can't lock this down :(
>>> https://jira.atlassian.com/browse/JRASERVER-42068
>>>
>>> On Fri, Apr 14, 2017 at 9:42 AM Mark Miller <[hidden email]>
>>> wrote:
>>>>
>>>> On Fri, Apr 14, 2017 at 9:37 AM Cassandra Targett
>>>> <[hidden email]> 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.
>>>>
>>>>
>>>> Ah, that makes this a lot less baffling I guess.
>>>>
>>>>>
>>>>>
>>>>> 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.
>>>>
>>>>
>>>> +1!
>>>>
>>>>>
>>>>>
>>>>> 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.
>>>>
>>>>
>>>> I agree.
>>>>
>>>>>
>>>>>
>>>>> 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.
>>>>
>>>>
>>>> +1. It also matches how we handle CHANGES afaict.
>>>>
>>>> I wish we could disable the auto creating of versions entirely somehow,
>>>> but I guess the next best thing is to raise awareness. It's great to have
>>>> the correct versions and in the correct ordering.
>>>>
>>>> - Mark
>>>>
>>>>>
>>>>>
>>>>> 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 <[hidden email]>
>>>>> 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: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>> --
>>>> - Mark
>>>> about.me/markrmiller
>>>
>>> --
>>> - Mark
>>> about.me/markrmiller
>>
>> --
>> - Mark
>> about.me/markrmiller
>
> --
> - Mark
> about.me/markrmiller

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Strange Solr JIRA versions

Erick Erickson
Hmmm, and come to think of it I'm pretty sure I resolved some "fix
versions" as "trunk", which is also incorrect.

Well, now I know.

On Fri, Apr 14, 2017 at 9:21 AM, Erick Erickson <[hidden email]> wrote:

> If you look at the "history" tab on the JIRA you can see who set what
> values when. I checked 4-5 of the JIRAS and the person who set those
> has a long record of being very conscientious about changes so I'm
> certain it's just an awareness issue, at least for that person. I'll
> ping....
>
> Which suggests a way to raise awareness going forward: check the
> history and send a message.
>
> If that doesn't cure it we can consider harsher measures, although I
> don't think forbidding arbitrary labels is "harsh", it's just too bad
> we can't.
>
> Erick
>
> On Fri, Apr 14, 2017 at 7:56 AM, Mark Miller <[hidden email]> wrote:
>> I wish hossman was still more active in this type of thing. He would have
>> sworn more and fixed it more meticulously and probably earlier. Or maybe he
>> is sick of it after last time. Anyway, I did what I could, preserved the
>> proper versions I could, and it's clean again for now.
>>
>> I'm halfway serious about the admin thing given you can easily auto create
>> components and versions by accident. Maybe instead of giving it to everyone
>> by default, we should be doing it by request.
>>
>> - Mark
>>
>> On Fri, Apr 14, 2017 at 10:29 AM Mark Miller <[hidden email]> wrote:
>>>
>>> Perhaps everyone doesn't need to be a JIRA admin? Like people that add new
>>> bad versions in the future ;) This is no fun to cleanup.
>>>
>>> - Mark
>>>
>>> On Fri, Apr 14, 2017 at 10:23 AM Mark Miller <[hidden email]>
>>> wrote:
>>>>
>>>> Bummer, seems we can't lock this down :(
>>>> https://jira.atlassian.com/browse/JRASERVER-42068
>>>>
>>>> On Fri, Apr 14, 2017 at 9:42 AM Mark Miller <[hidden email]>
>>>> wrote:
>>>>>
>>>>> On Fri, Apr 14, 2017 at 9:37 AM Cassandra Targett
>>>>> <[hidden email]> 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.
>>>>>
>>>>>
>>>>> Ah, that makes this a lot less baffling I guess.
>>>>>
>>>>>>
>>>>>>
>>>>>> 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.
>>>>>
>>>>>
>>>>> +1!
>>>>>
>>>>>>
>>>>>>
>>>>>> 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.
>>>>>
>>>>>
>>>>> I agree.
>>>>>
>>>>>>
>>>>>>
>>>>>> 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.
>>>>>
>>>>>
>>>>> +1. It also matches how we handle CHANGES afaict.
>>>>>
>>>>> I wish we could disable the auto creating of versions entirely somehow,
>>>>> but I guess the next best thing is to raise awareness. It's great to have
>>>>> the correct versions and in the correct ordering.
>>>>>
>>>>> - Mark
>>>>>
>>>>>>
>>>>>>
>>>>>> 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 <[hidden email]>
>>>>>> 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: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>> --
>>>>> - Mark
>>>>> about.me/markrmiller
>>>>
>>>> --
>>>> - Mark
>>>> about.me/markrmiller
>>>
>>> --
>>> - Mark
>>> about.me/markrmiller
>>
>> --
>> - Mark
>> about.me/markrmiller

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Strange Solr JIRA versions

Mark Miller-3
The problem is not so much notifying people, because no one is closely monitoring this stuff. By the time we ever notice it and attempt to fix it, there are 40-200 issues involved. You are not the only one. And I would be angry at you! If not for the fact that it's a terrible JIRA issue that did not used to be a problem. But, ok, you have learned this JIRA 'feature' is a problem. What about those not reading this, what about future committers, what about you go away for a year and come back having forgotten. The JIRA issue to fix this in JIRA has tons of votes, but it's also old, so no help from Atlassian likely any time soon. You can read the comments on the bug report and lots of people have this problem and hate it. The devs doing it here are not special, that's obvious.

I'm not sure why we have so many admins though. Sure, if you do a release, you want to be able to manage the versions, but a huge number of committers have not done a release and could request admin when needed. Then we could grant it, and be like, by the way, careful with your god like powers to create stuff out of thin air without realizing.

Perhaps the other reason most might use admin power is to add someone, but I think only a subset of people do that as well currently.

- Mark

On Fri, Apr 14, 2017 at 12:28 PM Erick Erickson <[hidden email]> wrote:
Hmmm, and come to think of it I'm pretty sure I resolved some "fix
versions" as "trunk", which is also incorrect.

Well, now I know.

On Fri, Apr 14, 2017 at 9:21 AM, Erick Erickson <[hidden email]> wrote:
> If you look at the "history" tab on the JIRA you can see who set what
> values when. I checked 4-5 of the JIRAS and the person who set those
> has a long record of being very conscientious about changes so I'm
> certain it's just an awareness issue, at least for that person. I'll
> ping....
>
> Which suggests a way to raise awareness going forward: check the
> history and send a message.
>
> If that doesn't cure it we can consider harsher measures, although I
> don't think forbidding arbitrary labels is "harsh", it's just too bad
> we can't.
>
> Erick
>
> On Fri, Apr 14, 2017 at 7:56 AM, Mark Miller <[hidden email]> wrote:
>> I wish hossman was still more active in this type of thing. He would have
>> sworn more and fixed it more meticulously and probably earlier. Or maybe he
>> is sick of it after last time. Anyway, I did what I could, preserved the
>> proper versions I could, and it's clean again for now.
>>
>> I'm halfway serious about the admin thing given you can easily auto create
>> components and versions by accident. Maybe instead of giving it to everyone
>> by default, we should be doing it by request.
>>
>> - Mark
>>
>> On Fri, Apr 14, 2017 at 10:29 AM Mark Miller <[hidden email]> wrote:
>>>
>>> Perhaps everyone doesn't need to be a JIRA admin? Like people that add new
>>> bad versions in the future ;) This is no fun to cleanup.
>>>
>>> - Mark
>>>
>>> On Fri, Apr 14, 2017 at 10:23 AM Mark Miller <[hidden email]>
>>> wrote:
>>>>
>>>> Bummer, seems we can't lock this down :(
>>>> https://jira.atlassian.com/browse/JRASERVER-42068
>>>>
>>>> On Fri, Apr 14, 2017 at 9:42 AM Mark Miller <[hidden email]>
>>>> wrote:
>>>>>
>>>>> On Fri, Apr 14, 2017 at 9:37 AM Cassandra Targett
>>>>> <[hidden email]> 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.
>>>>>
>>>>>
>>>>> Ah, that makes this a lot less baffling I guess.
>>>>>
>>>>>>
>>>>>>
>>>>>> 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.
>>>>>
>>>>>
>>>>> +1!
>>>>>
>>>>>>
>>>>>>
>>>>>> 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.
>>>>>
>>>>>
>>>>> I agree.
>>>>>
>>>>>>
>>>>>>
>>>>>> 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.
>>>>>
>>>>>
>>>>> +1. It also matches how we handle CHANGES afaict.
>>>>>
>>>>> I wish we could disable the auto creating of versions entirely somehow,
>>>>> but I guess the next best thing is to raise awareness. It's great to have
>>>>> the correct versions and in the correct ordering.
>>>>>
>>>>> - Mark
>>>>>
>>>>>>
>>>>>>
>>>>>> 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 <[hidden email]>
>>>>>> 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: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>> --
>>>>> - Mark
>>>>> about.me/markrmiller
>>>>
>>>> --
>>>> - Mark
>>>> about.me/markrmiller
>>>
>>> --
>>> - Mark
>>> about.me/markrmiller
>>
>> --
>> - Mark
>> about.me/markrmiller

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

--
Reply | Threaded
Open this post in threaded view
|

Re: Strange Solr JIRA versions

Erick Erickson
I agree with all your points and would _much_ rather be unable to
screw up even if it meant jumping through another hoop on those rare
occasions when I needed more authority.

Personally I'm fine with not being an administrator as long as I can
assign JIRAs to myself and resolve them.

On Fri, Apr 14, 2017 at 9:34 AM, Mark Miller <[hidden email]> wrote:

> The problem is not so much notifying people, because no one is closely
> monitoring this stuff. By the time we ever notice it and attempt to fix it,
> there are 40-200 issues involved. You are not the only one. And I would be
> angry at you! If not for the fact that it's a terrible JIRA issue that did
> not used to be a problem. But, ok, you have learned this JIRA 'feature' is a
> problem. What about those not reading this, what about future committers,
> what about you go away for a year and come back having forgotten. The JIRA
> issue to fix this in JIRA has tons of votes, but it's also old, so no help
> from Atlassian likely any time soon. You can read the comments on the bug
> report and lots of people have this problem and hate it. The devs doing it
> here are not special, that's obvious.
>
> I'm not sure why we have so many admins though. Sure, if you do a release,
> you want to be able to manage the versions, but a huge number of committers
> have not done a release and could request admin when needed. Then we could
> grant it, and be like, by the way, careful with your god like powers to
> create stuff out of thin air without realizing.
>
> Perhaps the other reason most might use admin power is to add someone, but I
> think only a subset of people do that as well currently.
>
> - Mark
>
> On Fri, Apr 14, 2017 at 12:28 PM Erick Erickson <[hidden email]>
> wrote:
>>
>> Hmmm, and come to think of it I'm pretty sure I resolved some "fix
>> versions" as "trunk", which is also incorrect.
>>
>> Well, now I know.
>>
>> On Fri, Apr 14, 2017 at 9:21 AM, Erick Erickson <[hidden email]>
>> wrote:
>> > If you look at the "history" tab on the JIRA you can see who set what
>> > values when. I checked 4-5 of the JIRAS and the person who set those
>> > has a long record of being very conscientious about changes so I'm
>> > certain it's just an awareness issue, at least for that person. I'll
>> > ping....
>> >
>> > Which suggests a way to raise awareness going forward: check the
>> > history and send a message.
>> >
>> > If that doesn't cure it we can consider harsher measures, although I
>> > don't think forbidding arbitrary labels is "harsh", it's just too bad
>> > we can't.
>> >
>> > Erick
>> >
>> > On Fri, Apr 14, 2017 at 7:56 AM, Mark Miller <[hidden email]>
>> > wrote:
>> >> I wish hossman was still more active in this type of thing. He would
>> >> have
>> >> sworn more and fixed it more meticulously and probably earlier. Or
>> >> maybe he
>> >> is sick of it after last time. Anyway, I did what I could, preserved
>> >> the
>> >> proper versions I could, and it's clean again for now.
>> >>
>> >> I'm halfway serious about the admin thing given you can easily auto
>> >> create
>> >> components and versions by accident. Maybe instead of giving it to
>> >> everyone
>> >> by default, we should be doing it by request.
>> >>
>> >> - Mark
>> >>
>> >> On Fri, Apr 14, 2017 at 10:29 AM Mark Miller <[hidden email]>
>> >> wrote:
>> >>>
>> >>> Perhaps everyone doesn't need to be a JIRA admin? Like people that add
>> >>> new
>> >>> bad versions in the future ;) This is no fun to cleanup.
>> >>>
>> >>> - Mark
>> >>>
>> >>> On Fri, Apr 14, 2017 at 10:23 AM Mark Miller <[hidden email]>
>> >>> wrote:
>> >>>>
>> >>>> Bummer, seems we can't lock this down :(
>> >>>> https://jira.atlassian.com/browse/JRASERVER-42068
>> >>>>
>> >>>> On Fri, Apr 14, 2017 at 9:42 AM Mark Miller <[hidden email]>
>> >>>> wrote:
>> >>>>>
>> >>>>> On Fri, Apr 14, 2017 at 9:37 AM Cassandra Targett
>> >>>>> <[hidden email]> 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.
>> >>>>>
>> >>>>>
>> >>>>> Ah, that makes this a lot less baffling I guess.
>> >>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> 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.
>> >>>>>
>> >>>>>
>> >>>>> +1!
>> >>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> 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.
>> >>>>>
>> >>>>>
>> >>>>> I agree.
>> >>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> 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.
>> >>>>>
>> >>>>>
>> >>>>> +1. It also matches how we handle CHANGES afaict.
>> >>>>>
>> >>>>> I wish we could disable the auto creating of versions entirely
>> >>>>> somehow,
>> >>>>> but I guess the next best thing is to raise awareness. It's great to
>> >>>>> have
>> >>>>> the correct versions and in the correct ordering.
>> >>>>>
>> >>>>> - Mark
>> >>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> 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
>> >>>>>> <[hidden email]>
>> >>>>>> 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: [hidden email]
>> >>>>>> For additional commands, e-mail: [hidden email]
>> >>>>>>
>> >>>>> --
>> >>>>> - Mark
>> >>>>> about.me/markrmiller
>> >>>>
>> >>>> --
>> >>>> - Mark
>> >>>> about.me/markrmiller
>> >>>
>> >>> --
>> >>> - Mark
>> >>> about.me/markrmiller
>> >>
>> >> --
>> >> - Mark
>> >> about.me/markrmiller
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
> --
> - Mark
> about.me/markrmiller

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Strange Solr JIRA versions

Mark Miller-3
bq. Personally I'm fine with not being an administrator as long as I can assign JIRAs to myself and resolve them.

I think that is 80-90% of us. The only time I ever use admin is to fix version stuff like this or do a release. I think Jenkins access might work this way, you have to request it. It would also be great if like the committer role could manage versions, but I couldn't seem to find that feature.

But anyway, my proposal would be to get rid of that PMC group (which is like more admins), clear the admin group, and seed it with anyone that calls out wanting access, and then give access as requested from there out, extra points for a warning about this 'feature' and managing versions consistently with the past unless there is discussion.

- Mark

On Fri, Apr 14, 2017 at 1:06 PM Erick Erickson <[hidden email]> wrote:
I agree with all your points and would _much_ rather be unable to
screw up even if it meant jumping through another hoop on those rare
occasions when I needed more authority.

Personally I'm fine with not being an administrator as long as I can
assign JIRAs to myself and resolve them.

On Fri, Apr 14, 2017 at 9:34 AM, Mark Miller <[hidden email]> wrote:
> The problem is not so much notifying people, because no one is closely
> monitoring this stuff. By the time we ever notice it and attempt to fix it,
> there are 40-200 issues involved. You are not the only one. And I would be
> angry at you! If not for the fact that it's a terrible JIRA issue that did
> not used to be a problem. But, ok, you have learned this JIRA 'feature' is a
> problem. What about those not reading this, what about future committers,
> what about you go away for a year and come back having forgotten. The JIRA
> issue to fix this in JIRA has tons of votes, but it's also old, so no help
> from Atlassian likely any time soon. You can read the comments on the bug
> report and lots of people have this problem and hate it. The devs doing it
> here are not special, that's obvious.
>
> I'm not sure why we have so many admins though. Sure, if you do a release,
> you want to be able to manage the versions, but a huge number of committers
> have not done a release and could request admin when needed. Then we could
> grant it, and be like, by the way, careful with your god like powers to
> create stuff out of thin air without realizing.
>
> Perhaps the other reason most might use admin power is to add someone, but I
> think only a subset of people do that as well currently.
>
> - Mark
>
> On Fri, Apr 14, 2017 at 12:28 PM Erick Erickson <[hidden email]>
> wrote:
>>
>> Hmmm, and come to think of it I'm pretty sure I resolved some "fix
>> versions" as "trunk", which is also incorrect.
>>
>> Well, now I know.
>>
>> On Fri, Apr 14, 2017 at 9:21 AM, Erick Erickson <[hidden email]>
>> wrote:
>> > If you look at the "history" tab on the JIRA you can see who set what
>> > values when. I checked 4-5 of the JIRAS and the person who set those
>> > has a long record of being very conscientious about changes so I'm
>> > certain it's just an awareness issue, at least for that person. I'll
>> > ping....
>> >
>> > Which suggests a way to raise awareness going forward: check the
>> > history and send a message.
>> >
>> > If that doesn't cure it we can consider harsher measures, although I
>> > don't think forbidding arbitrary labels is "harsh", it's just too bad
>> > we can't.
>> >
>> > Erick
>> >
>> > On Fri, Apr 14, 2017 at 7:56 AM, Mark Miller <[hidden email]>
>> > wrote:
>> >> I wish hossman was still more active in this type of thing. He would
>> >> have
>> >> sworn more and fixed it more meticulously and probably earlier. Or
>> >> maybe he
>> >> is sick of it after last time. Anyway, I did what I could, preserved
>> >> the
>> >> proper versions I could, and it's clean again for now.
>> >>
>> >> I'm halfway serious about the admin thing given you can easily auto
>> >> create
>> >> components and versions by accident. Maybe instead of giving it to
>> >> everyone
>> >> by default, we should be doing it by request.
>> >>
>> >> - Mark
>> >>
>> >> On Fri, Apr 14, 2017 at 10:29 AM Mark Miller <[hidden email]>
>> >> wrote:
>> >>>
>> >>> Perhaps everyone doesn't need to be a JIRA admin? Like people that add
>> >>> new
>> >>> bad versions in the future ;) This is no fun to cleanup.
>> >>>
>> >>> - Mark
>> >>>
>> >>> On Fri, Apr 14, 2017 at 10:23 AM Mark Miller <[hidden email]>
>> >>> wrote:
>> >>>>
>> >>>> Bummer, seems we can't lock this down :(
>> >>>> https://jira.atlassian.com/browse/JRASERVER-42068
>> >>>>
>> >>>> On Fri, Apr 14, 2017 at 9:42 AM Mark Miller <[hidden email]>
>> >>>> wrote:
>> >>>>>
>> >>>>> On Fri, Apr 14, 2017 at 9:37 AM Cassandra Targett
>> >>>>> <[hidden email]> 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.
>> >>>>>
>> >>>>>
>> >>>>> Ah, that makes this a lot less baffling I guess.
>> >>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> 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.
>> >>>>>
>> >>>>>
>> >>>>> +1!
>> >>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> 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.
>> >>>>>
>> >>>>>
>> >>>>> I agree.
>> >>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> 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.
>> >>>>>
>> >>>>>
>> >>>>> +1. It also matches how we handle CHANGES afaict.
>> >>>>>
>> >>>>> I wish we could disable the auto creating of versions entirely
>> >>>>> somehow,
>> >>>>> but I guess the next best thing is to raise awareness. It's great to
>> >>>>> have
>> >>>>> the correct versions and in the correct ordering.
>> >>>>>
>> >>>>> - Mark
>> >>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> 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
>> >>>>>> <[hidden email]>
>> >>>>>> 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: [hidden email]
>> >>>>>> For additional commands, e-mail: [hidden email]
>> >>>>>>
>> >>>>> --
>> >>>>> - Mark
>> >>>>> about.me/markrmiller
>> >>>>
>> >>>> --
>> >>>> - Mark
>> >>>> about.me/markrmiller
>> >>>
>> >>> --
>> >>> - Mark
>> >>> about.me/markrmiller
>> >>
>> >> --
>> >> - Mark
>> >> about.me/markrmiller
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
> --
> - Mark
> about.me/markrmiller

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

--
Reply | Threaded
Open this post in threaded view
|

Re: Strange Solr JIRA versions

Mark Miller-3
bq. committer role could manage versions, but I couldn't seem to find that feature.

Although I suppose if it could, it would probably also get god like auto create powers anyway.

On Fri, Apr 14, 2017 at 1:45 PM Mark Miller <[hidden email]> wrote:
bq. Personally I'm fine with not being an administrator as long as I can assign JIRAs to myself and resolve them.

I think that is 80-90% of us. The only time I ever use admin is to fix version stuff like this or do a release. I think Jenkins access might work this way, you have to request it. It would also be great if like the committer role could manage versions, but I couldn't seem to find that feature.

But anyway, my proposal would be to get rid of that PMC group (which is like more admins), clear the admin group, and seed it with anyone that calls out wanting access, and then give access as requested from there out, extra points for a warning about this 'feature' and managing versions consistently with the past unless there is discussion.

- Mark

On Fri, Apr 14, 2017 at 1:06 PM Erick Erickson <[hidden email]> wrote:
I agree with all your points and would _much_ rather be unable to
screw up even if it meant jumping through another hoop on those rare
occasions when I needed more authority.

Personally I'm fine with not being an administrator as long as I can
assign JIRAs to myself and resolve them.

On Fri, Apr 14, 2017 at 9:34 AM, Mark Miller <[hidden email]> wrote:
> The problem is not so much notifying people, because no one is closely
> monitoring this stuff. By the time we ever notice it and attempt to fix it,
> there are 40-200 issues involved. You are not the only one. And I would be
> angry at you! If not for the fact that it's a terrible JIRA issue that did
> not used to be a problem. But, ok, you have learned this JIRA 'feature' is a
> problem. What about those not reading this, what about future committers,
> what about you go away for a year and come back having forgotten. The JIRA
> issue to fix this in JIRA has tons of votes, but it's also old, so no help
> from Atlassian likely any time soon. You can read the comments on the bug
> report and lots of people have this problem and hate it. The devs doing it
> here are not special, that's obvious.
>
> I'm not sure why we have so many admins though. Sure, if you do a release,
> you want to be able to manage the versions, but a huge number of committers
> have not done a release and could request admin when needed. Then we could
> grant it, and be like, by the way, careful with your god like powers to
> create stuff out of thin air without realizing.
>
> Perhaps the other reason most might use admin power is to add someone, but I
> think only a subset of people do that as well currently.
>
> - Mark
>
> On Fri, Apr 14, 2017 at 12:28 PM Erick Erickson <[hidden email]>
> wrote:
>>
>> Hmmm, and come to think of it I'm pretty sure I resolved some "fix
>> versions" as "trunk", which is also incorrect.
>>
>> Well, now I know.
>>
>> On Fri, Apr 14, 2017 at 9:21 AM, Erick Erickson <[hidden email]>
>> wrote:
>> > If you look at the "history" tab on the JIRA you can see who set what
>> > values when. I checked 4-5 of the JIRAS and the person who set those
>> > has a long record of being very conscientious about changes so I'm
>> > certain it's just an awareness issue, at least for that person. I'll
>> > ping....
>> >
>> > Which suggests a way to raise awareness going forward: check the
>> > history and send a message.
>> >
>> > If that doesn't cure it we can consider harsher measures, although I
>> > don't think forbidding arbitrary labels is "harsh", it's just too bad
>> > we can't.
>> >
>> > Erick
>> >
>> > On Fri, Apr 14, 2017 at 7:56 AM, Mark Miller <[hidden email]>
>> > wrote:
>> >> I wish hossman was still more active in this type of thing. He would
>> >> have
>> >> sworn more and fixed it more meticulously and probably earlier. Or
>> >> maybe he
>> >> is sick of it after last time. Anyway, I did what I could, preserved
>> >> the
>> >> proper versions I could, and it's clean again for now.
>> >>
>> >> I'm halfway serious about the admin thing given you can easily auto
>> >> create
>> >> components and versions by accident. Maybe instead of giving it to
>> >> everyone
>> >> by default, we should be doing it by request.
>> >>
>> >> - Mark
>> >>
>> >> On Fri, Apr 14, 2017 at 10:29 AM Mark Miller <[hidden email]>
>> >> wrote:
>> >>>
>> >>> Perhaps everyone doesn't need to be a JIRA admin? Like people that add
>> >>> new
>> >>> bad versions in the future ;) This is no fun to cleanup.
>> >>>
>> >>> - Mark
>> >>>
>> >>> On Fri, Apr 14, 2017 at 10:23 AM Mark Miller <[hidden email]>
>> >>> wrote:
>> >>>>
>> >>>> Bummer, seems we can't lock this down :(
>> >>>> https://jira.atlassian.com/browse/JRASERVER-42068
>> >>>>
>> >>>> On Fri, Apr 14, 2017 at 9:42 AM Mark Miller <[hidden email]>
>> >>>> wrote:
>> >>>>>
>> >>>>> On Fri, Apr 14, 2017 at 9:37 AM Cassandra Targett
>> >>>>> <[hidden email]> 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.
>> >>>>>
>> >>>>>
>> >>>>> Ah, that makes this a lot less baffling I guess.
>> >>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> 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.
>> >>>>>
>> >>>>>
>> >>>>> +1!
>> >>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> 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.
>> >>>>>
>> >>>>>
>> >>>>> I agree.
>> >>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> 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.
>> >>>>>
>> >>>>>
>> >>>>> +1. It also matches how we handle CHANGES afaict.
>> >>>>>
>> >>>>> I wish we could disable the auto creating of versions entirely
>> >>>>> somehow,
>> >>>>> but I guess the next best thing is to raise awareness. It's great to
>> >>>>> have
>> >>>>> the correct versions and in the correct ordering.
>> >>>>>
>> >>>>> - Mark
>> >>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> 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
>> >>>>>> <[hidden email]>
>> >>>>>> 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: [hidden email]
>> >>>>>> For additional commands, e-mail: [hidden email]
>> >>>>>>
>> >>>>> --
>> >>>>> - Mark
>> >>>>> about.me/markrmiller
>> >>>>
>> >>>> --
>> >>>> - Mark
>> >>>> about.me/markrmiller
>> >>>
>> >>> --
>> >>> - Mark
>> >>> about.me/markrmiller
>> >>
>> >> --
>> >> - Mark
>> >> about.me/markrmiller
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
> --
> - Mark
> about.me/markrmiller

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

--
--
Reply | Threaded
Open this post in threaded view
|

Re: Strange Solr JIRA versions

Erick Erickson
In reply to this post by Mark Miller-3
bq: my proposal would be to get rid of that PMC group (which is like
more admins), clear the admin group, and seed it with anyone that
calls out wanting access

+1

On Fri, Apr 14, 2017 at 10:45 AM, Mark Miller <[hidden email]> wrote:

> bq. Personally I'm fine with not being an administrator as long as I can
> assign JIRAs to myself and resolve them.
>
> I think that is 80-90% of us. The only time I ever use admin is to fix
> version stuff like this or do a release. I think Jenkins access might work
> this way, you have to request it. It would also be great if like the
> committer role could manage versions, but I couldn't seem to find that
> feature.
>
> But anyway, my proposal would be to get rid of that PMC group (which is like
> more admins), clear the admin group, and seed it with anyone that calls out
> wanting access, and then give access as requested from there out, extra
> points for a warning about this 'feature' and managing versions consistently
> with the past unless there is discussion.
>
> - Mark
>
> On Fri, Apr 14, 2017 at 1:06 PM Erick Erickson <[hidden email]>
> wrote:
>>
>> I agree with all your points and would _much_ rather be unable to
>> screw up even if it meant jumping through another hoop on those rare
>> occasions when I needed more authority.
>>
>> Personally I'm fine with not being an administrator as long as I can
>> assign JIRAs to myself and resolve them.
>>
>> On Fri, Apr 14, 2017 at 9:34 AM, Mark Miller <[hidden email]>
>> wrote:
>> > The problem is not so much notifying people, because no one is closely
>> > monitoring this stuff. By the time we ever notice it and attempt to fix
>> > it,
>> > there are 40-200 issues involved. You are not the only one. And I would
>> > be
>> > angry at you! If not for the fact that it's a terrible JIRA issue that
>> > did
>> > not used to be a problem. But, ok, you have learned this JIRA 'feature'
>> > is a
>> > problem. What about those not reading this, what about future
>> > committers,
>> > what about you go away for a year and come back having forgotten. The
>> > JIRA
>> > issue to fix this in JIRA has tons of votes, but it's also old, so no
>> > help
>> > from Atlassian likely any time soon. You can read the comments on the
>> > bug
>> > report and lots of people have this problem and hate it. The devs doing
>> > it
>> > here are not special, that's obvious.
>> >
>> > I'm not sure why we have so many admins though. Sure, if you do a
>> > release,
>> > you want to be able to manage the versions, but a huge number of
>> > committers
>> > have not done a release and could request admin when needed. Then we
>> > could
>> > grant it, and be like, by the way, careful with your god like powers to
>> > create stuff out of thin air without realizing.
>> >
>> > Perhaps the other reason most might use admin power is to add someone,
>> > but I
>> > think only a subset of people do that as well currently.
>> >
>> > - Mark
>> >
>> > On Fri, Apr 14, 2017 at 12:28 PM Erick Erickson
>> > <[hidden email]>
>> > wrote:
>> >>
>> >> Hmmm, and come to think of it I'm pretty sure I resolved some "fix
>> >> versions" as "trunk", which is also incorrect.
>> >>
>> >> Well, now I know.
>> >>
>> >> On Fri, Apr 14, 2017 at 9:21 AM, Erick Erickson
>> >> <[hidden email]>
>> >> wrote:
>> >> > If you look at the "history" tab on the JIRA you can see who set what
>> >> > values when. I checked 4-5 of the JIRAS and the person who set those
>> >> > has a long record of being very conscientious about changes so I'm
>> >> > certain it's just an awareness issue, at least for that person. I'll
>> >> > ping....
>> >> >
>> >> > Which suggests a way to raise awareness going forward: check the
>> >> > history and send a message.
>> >> >
>> >> > If that doesn't cure it we can consider harsher measures, although I
>> >> > don't think forbidding arbitrary labels is "harsh", it's just too bad
>> >> > we can't.
>> >> >
>> >> > Erick
>> >> >
>> >> > On Fri, Apr 14, 2017 at 7:56 AM, Mark Miller <[hidden email]>
>> >> > wrote:
>> >> >> I wish hossman was still more active in this type of thing. He would
>> >> >> have
>> >> >> sworn more and fixed it more meticulously and probably earlier. Or
>> >> >> maybe he
>> >> >> is sick of it after last time. Anyway, I did what I could, preserved
>> >> >> the
>> >> >> proper versions I could, and it's clean again for now.
>> >> >>
>> >> >> I'm halfway serious about the admin thing given you can easily auto
>> >> >> create
>> >> >> components and versions by accident. Maybe instead of giving it to
>> >> >> everyone
>> >> >> by default, we should be doing it by request.
>> >> >>
>> >> >> - Mark
>> >> >>
>> >> >> On Fri, Apr 14, 2017 at 10:29 AM Mark Miller <[hidden email]>
>> >> >> wrote:
>> >> >>>
>> >> >>> Perhaps everyone doesn't need to be a JIRA admin? Like people that
>> >> >>> add
>> >> >>> new
>> >> >>> bad versions in the future ;) This is no fun to cleanup.
>> >> >>>
>> >> >>> - Mark
>> >> >>>
>> >> >>> On Fri, Apr 14, 2017 at 10:23 AM Mark Miller
>> >> >>> <[hidden email]>
>> >> >>> wrote:
>> >> >>>>
>> >> >>>> Bummer, seems we can't lock this down :(
>> >> >>>> https://jira.atlassian.com/browse/JRASERVER-42068
>> >> >>>>
>> >> >>>> On Fri, Apr 14, 2017 at 9:42 AM Mark Miller
>> >> >>>> <[hidden email]>
>> >> >>>> wrote:
>> >> >>>>>
>> >> >>>>> On Fri, Apr 14, 2017 at 9:37 AM Cassandra Targett
>> >> >>>>> <[hidden email]> 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.
>> >> >>>>>
>> >> >>>>>
>> >> >>>>> Ah, that makes this a lot less baffling I guess.
>> >> >>>>>
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>> 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.
>> >> >>>>>
>> >> >>>>>
>> >> >>>>> +1!
>> >> >>>>>
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>> 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.
>> >> >>>>>
>> >> >>>>>
>> >> >>>>> I agree.
>> >> >>>>>
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>> 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.
>> >> >>>>>
>> >> >>>>>
>> >> >>>>> +1. It also matches how we handle CHANGES afaict.
>> >> >>>>>
>> >> >>>>> I wish we could disable the auto creating of versions entirely
>> >> >>>>> somehow,
>> >> >>>>> but I guess the next best thing is to raise awareness. It's great
>> >> >>>>> to
>> >> >>>>> have
>> >> >>>>> the correct versions and in the correct ordering.
>> >> >>>>>
>> >> >>>>> - Mark
>> >> >>>>>
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>> 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
>> >> >>>>>> <[hidden email]>
>> >> >>>>>> 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: [hidden email]
>> >> >>>>>> For additional commands, e-mail: [hidden email]
>> >> >>>>>>
>> >> >>>>> --
>> >> >>>>> - Mark
>> >> >>>>> about.me/markrmiller
>> >> >>>>
>> >> >>>> --
>> >> >>>> - Mark
>> >> >>>> about.me/markrmiller
>> >> >>>
>> >> >>> --
>> >> >>> - Mark
>> >> >>> about.me/markrmiller
>> >> >>
>> >> >> --
>> >> >> - Mark
>> >> >> about.me/markrmiller
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [hidden email]
>> >> For additional commands, e-mail: [hidden email]
>> >>
>> > --
>> > - Mark
>> > about.me/markrmiller
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
> --
> - Mark
> about.me/markrmiller

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Strange Solr JIRA versions

Cassandra Targett
In reply to this post by Mark Miller-3
On Fri, Apr 14, 2017 at 9:56 AM, Mark Miller <[hidden email]> wrote:
> I wish hossman was still more active in this type of thing. He would have
> sworn more

Heh. This is why I was going to send a mail about it before he got
back from vacation ;)

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Strange Solr JIRA versions

Cassandra Targett
In reply to this post by Erick Erickson
I'm also +1 to removing PMC group - I checked and every permission PMC
group has, administrators also have so consolidating those 2 groups
should have no impact on people.

I'd be happy to have admin access, and I will help keep my eyes out
for problems like this in the future.

On Fri, Apr 14, 2017 at 1:36 PM, Erick Erickson <[hidden email]> wrote:

> bq: my proposal would be to get rid of that PMC group (which is like
> more admins), clear the admin group, and seed it with anyone that
> calls out wanting access
>
> +1
>
> On Fri, Apr 14, 2017 at 10:45 AM, Mark Miller <[hidden email]> wrote:
>> bq. Personally I'm fine with not being an administrator as long as I can
>> assign JIRAs to myself and resolve them.
>>
>> I think that is 80-90% of us. The only time I ever use admin is to fix
>> version stuff like this or do a release. I think Jenkins access might work
>> this way, you have to request it. It would also be great if like the
>> committer role could manage versions, but I couldn't seem to find that
>> feature.
>>
>> But anyway, my proposal would be to get rid of that PMC group (which is like
>> more admins), clear the admin group, and seed it with anyone that calls out
>> wanting access, and then give access as requested from there out, extra
>> points for a warning about this 'feature' and managing versions consistently
>> with the past unless there is discussion.
>>
>> - Mark
>>
>> On Fri, Apr 14, 2017 at 1:06 PM Erick Erickson <[hidden email]>
>> wrote:
>>>
>>> I agree with all your points and would _much_ rather be unable to
>>> screw up even if it meant jumping through another hoop on those rare
>>> occasions when I needed more authority.
>>>
>>> Personally I'm fine with not being an administrator as long as I can
>>> assign JIRAs to myself and resolve them.
>>>
>>> On Fri, Apr 14, 2017 at 9:34 AM, Mark Miller <[hidden email]>
>>> wrote:
>>> > The problem is not so much notifying people, because no one is closely
>>> > monitoring this stuff. By the time we ever notice it and attempt to fix
>>> > it,
>>> > there are 40-200 issues involved. You are not the only one. And I would
>>> > be
>>> > angry at you! If not for the fact that it's a terrible JIRA issue that
>>> > did
>>> > not used to be a problem. But, ok, you have learned this JIRA 'feature'
>>> > is a
>>> > problem. What about those not reading this, what about future
>>> > committers,
>>> > what about you go away for a year and come back having forgotten. The
>>> > JIRA
>>> > issue to fix this in JIRA has tons of votes, but it's also old, so no
>>> > help
>>> > from Atlassian likely any time soon. You can read the comments on the
>>> > bug
>>> > report and lots of people have this problem and hate it. The devs doing
>>> > it
>>> > here are not special, that's obvious.
>>> >
>>> > I'm not sure why we have so many admins though. Sure, if you do a
>>> > release,
>>> > you want to be able to manage the versions, but a huge number of
>>> > committers
>>> > have not done a release and could request admin when needed. Then we
>>> > could
>>> > grant it, and be like, by the way, careful with your god like powers to
>>> > create stuff out of thin air without realizing.
>>> >
>>> > Perhaps the other reason most might use admin power is to add someone,
>>> > but I
>>> > think only a subset of people do that as well currently.
>>> >
>>> > - Mark
>>> >
>>> > On Fri, Apr 14, 2017 at 12:28 PM Erick Erickson
>>> > <[hidden email]>
>>> > wrote:
>>> >>
>>> >> Hmmm, and come to think of it I'm pretty sure I resolved some "fix
>>> >> versions" as "trunk", which is also incorrect.
>>> >>
>>> >> Well, now I know.
>>> >>
>>> >> On Fri, Apr 14, 2017 at 9:21 AM, Erick Erickson
>>> >> <[hidden email]>
>>> >> wrote:
>>> >> > If you look at the "history" tab on the JIRA you can see who set what
>>> >> > values when. I checked 4-5 of the JIRAS and the person who set those
>>> >> > has a long record of being very conscientious about changes so I'm
>>> >> > certain it's just an awareness issue, at least for that person. I'll
>>> >> > ping....
>>> >> >
>>> >> > Which suggests a way to raise awareness going forward: check the
>>> >> > history and send a message.
>>> >> >
>>> >> > If that doesn't cure it we can consider harsher measures, although I
>>> >> > don't think forbidding arbitrary labels is "harsh", it's just too bad
>>> >> > we can't.
>>> >> >
>>> >> > Erick
>>> >> >
>>> >> > On Fri, Apr 14, 2017 at 7:56 AM, Mark Miller <[hidden email]>
>>> >> > wrote:
>>> >> >> I wish hossman was still more active in this type of thing. He would
>>> >> >> have
>>> >> >> sworn more and fixed it more meticulously and probably earlier. Or
>>> >> >> maybe he
>>> >> >> is sick of it after last time. Anyway, I did what I could, preserved
>>> >> >> the
>>> >> >> proper versions I could, and it's clean again for now.
>>> >> >>
>>> >> >> I'm halfway serious about the admin thing given you can easily auto
>>> >> >> create
>>> >> >> components and versions by accident. Maybe instead of giving it to
>>> >> >> everyone
>>> >> >> by default, we should be doing it by request.
>>> >> >>
>>> >> >> - Mark
>>> >> >>
>>> >> >> On Fri, Apr 14, 2017 at 10:29 AM Mark Miller <[hidden email]>
>>> >> >> wrote:
>>> >> >>>
>>> >> >>> Perhaps everyone doesn't need to be a JIRA admin? Like people that
>>> >> >>> add
>>> >> >>> new
>>> >> >>> bad versions in the future ;) This is no fun to cleanup.
>>> >> >>>
>>> >> >>> - Mark
>>> >> >>>
>>> >> >>> On Fri, Apr 14, 2017 at 10:23 AM Mark Miller
>>> >> >>> <[hidden email]>
>>> >> >>> wrote:
>>> >> >>>>
>>> >> >>>> Bummer, seems we can't lock this down :(
>>> >> >>>> https://jira.atlassian.com/browse/JRASERVER-42068
>>> >> >>>>
>>> >> >>>> On Fri, Apr 14, 2017 at 9:42 AM Mark Miller
>>> >> >>>> <[hidden email]>
>>> >> >>>> wrote:
>>> >> >>>>>
>>> >> >>>>> On Fri, Apr 14, 2017 at 9:37 AM Cassandra Targett
>>> >> >>>>> <[hidden email]> 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.
>>> >> >>>>>
>>> >> >>>>>
>>> >> >>>>> Ah, that makes this a lot less baffling I guess.
>>> >> >>>>>
>>> >> >>>>>>
>>> >> >>>>>>
>>> >> >>>>>> 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.
>>> >> >>>>>
>>> >> >>>>>
>>> >> >>>>> +1!
>>> >> >>>>>
>>> >> >>>>>>
>>> >> >>>>>>
>>> >> >>>>>> 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.
>>> >> >>>>>
>>> >> >>>>>
>>> >> >>>>> I agree.
>>> >> >>>>>
>>> >> >>>>>>
>>> >> >>>>>>
>>> >> >>>>>> 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.
>>> >> >>>>>
>>> >> >>>>>
>>> >> >>>>> +1. It also matches how we handle CHANGES afaict.
>>> >> >>>>>
>>> >> >>>>> I wish we could disable the auto creating of versions entirely
>>> >> >>>>> somehow,
>>> >> >>>>> but I guess the next best thing is to raise awareness. It's great
>>> >> >>>>> to
>>> >> >>>>> have
>>> >> >>>>> the correct versions and in the correct ordering.
>>> >> >>>>>
>>> >> >>>>> - Mark
>>> >> >>>>>
>>> >> >>>>>>
>>> >> >>>>>>
>>> >> >>>>>> 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
>>> >> >>>>>> <[hidden email]>
>>> >> >>>>>> 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: [hidden email]
>>> >> >>>>>> For additional commands, e-mail: [hidden email]
>>> >> >>>>>>
>>> >> >>>>> --
>>> >> >>>>> - Mark
>>> >> >>>>> about.me/markrmiller
>>> >> >>>>
>>> >> >>>> --
>>> >> >>>> - Mark
>>> >> >>>> about.me/markrmiller
>>> >> >>>
>>> >> >>> --
>>> >> >>> - Mark
>>> >> >>> about.me/markrmiller
>>> >> >>
>>> >> >> --
>>> >> >> - Mark
>>> >> >> about.me/markrmiller
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: [hidden email]
>>> >> For additional commands, e-mail: [hidden email]
>>> >>
>>> > --
>>> > - Mark
>>> > about.me/markrmiller
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>> --
>> - Mark
>> about.me/markrmiller
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Strange Solr JIRA versions

Tomás Fernández Löbbe
Isn't the PMC group required to see issues with security level "private"?

On Fri, Apr 14, 2017 at 11:44 AM, Cassandra Targett <[hidden email]> wrote:
I'm also +1 to removing PMC group - I checked and every permission PMC
group has, administrators also have so consolidating those 2 groups
should have no impact on people.

I'd be happy to have admin access, and I will help keep my eyes out
for problems like this in the future.

On Fri, Apr 14, 2017 at 1:36 PM, Erick Erickson <[hidden email]> wrote:
> bq: my proposal would be to get rid of that PMC group (which is like
> more admins), clear the admin group, and seed it with anyone that
> calls out wanting access
>
> +1
>
> On Fri, Apr 14, 2017 at 10:45 AM, Mark Miller <[hidden email]> wrote:
>> bq. Personally I'm fine with not being an administrator as long as I can
>> assign JIRAs to myself and resolve them.
>>
>> I think that is 80-90% of us. The only time I ever use admin is to fix
>> version stuff like this or do a release. I think Jenkins access might work
>> this way, you have to request it. It would also be great if like the
>> committer role could manage versions, but I couldn't seem to find that
>> feature.
>>
>> But anyway, my proposal would be to get rid of that PMC group (which is like
>> more admins), clear the admin group, and seed it with anyone that calls out
>> wanting access, and then give access as requested from there out, extra
>> points for a warning about this 'feature' and managing versions consistently
>> with the past unless there is discussion.
>>
>> - Mark
>>
>> On Fri, Apr 14, 2017 at 1:06 PM Erick Erickson <[hidden email]>
>> wrote:
>>>
>>> I agree with all your points and would _much_ rather be unable to
>>> screw up even if it meant jumping through another hoop on those rare
>>> occasions when I needed more authority.
>>>
>>> Personally I'm fine with not being an administrator as long as I can
>>> assign JIRAs to myself and resolve them.
>>>
>>> On Fri, Apr 14, 2017 at 9:34 AM, Mark Miller <[hidden email]>
>>> wrote:
>>> > The problem is not so much notifying people, because no one is closely
>>> > monitoring this stuff. By the time we ever notice it and attempt to fix
>>> > it,
>>> > there are 40-200 issues involved. You are not the only one. And I would
>>> > be
>>> > angry at you! If not for the fact that it's a terrible JIRA issue that
>>> > did
>>> > not used to be a problem. But, ok, you have learned this JIRA 'feature'
>>> > is a
>>> > problem. What about those not reading this, what about future
>>> > committers,
>>> > what about you go away for a year and come back having forgotten. The
>>> > JIRA
>>> > issue to fix this in JIRA has tons of votes, but it's also old, so no
>>> > help
>>> > from Atlassian likely any time soon. You can read the comments on the
>>> > bug
>>> > report and lots of people have this problem and hate it. The devs doing
>>> > it
>>> > here are not special, that's obvious.
>>> >
>>> > I'm not sure why we have so many admins though. Sure, if you do a
>>> > release,
>>> > you want to be able to manage the versions, but a huge number of
>>> > committers
>>> > have not done a release and could request admin when needed. Then we
>>> > could
>>> > grant it, and be like, by the way, careful with your god like powers to
>>> > create stuff out of thin air without realizing.
>>> >
>>> > Perhaps the other reason most might use admin power is to add someone,
>>> > but I
>>> > think only a subset of people do that as well currently.
>>> >
>>> > - Mark
>>> >
>>> > On Fri, Apr 14, 2017 at 12:28 PM Erick Erickson
>>> > <[hidden email]>
>>> > wrote:
>>> >>
>>> >> Hmmm, and come to think of it I'm pretty sure I resolved some "fix
>>> >> versions" as "trunk", which is also incorrect.
>>> >>
>>> >> Well, now I know.
>>> >>
>>> >> On Fri, Apr 14, 2017 at 9:21 AM, Erick Erickson
>>> >> <[hidden email]>
>>> >> wrote:
>>> >> > If you look at the "history" tab on the JIRA you can see who set what
>>> >> > values when. I checked 4-5 of the JIRAS and the person who set those
>>> >> > has a long record of being very conscientious about changes so I'm
>>> >> > certain it's just an awareness issue, at least for that person. I'll
>>> >> > ping....
>>> >> >
>>> >> > Which suggests a way to raise awareness going forward: check the
>>> >> > history and send a message.
>>> >> >
>>> >> > If that doesn't cure it we can consider harsher measures, although I
>>> >> > don't think forbidding arbitrary labels is "harsh", it's just too bad
>>> >> > we can't.
>>> >> >
>>> >> > Erick
>>> >> >
>>> >> > On Fri, Apr 14, 2017 at 7:56 AM, Mark Miller <[hidden email]>
>>> >> > wrote:
>>> >> >> I wish hossman was still more active in this type of thing. He would
>>> >> >> have
>>> >> >> sworn more and fixed it more meticulously and probably earlier. Or
>>> >> >> maybe he
>>> >> >> is sick of it after last time. Anyway, I did what I could, preserved
>>> >> >> the
>>> >> >> proper versions I could, and it's clean again for now.
>>> >> >>
>>> >> >> I'm halfway serious about the admin thing given you can easily auto
>>> >> >> create
>>> >> >> components and versions by accident. Maybe instead of giving it to
>>> >> >> everyone
>>> >> >> by default, we should be doing it by request.
>>> >> >>
>>> >> >> - Mark
>>> >> >>
>>> >> >> On Fri, Apr 14, 2017 at 10:29 AM Mark Miller <[hidden email]>
>>> >> >> wrote:
>>> >> >>>
>>> >> >>> Perhaps everyone doesn't need to be a JIRA admin? Like people that
>>> >> >>> add
>>> >> >>> new
>>> >> >>> bad versions in the future ;) This is no fun to cleanup.
>>> >> >>>
>>> >> >>> - Mark
>>> >> >>>
>>> >> >>> On Fri, Apr 14, 2017 at 10:23 AM Mark Miller
>>> >> >>> <[hidden email]>
>>> >> >>> wrote:
>>> >> >>>>
>>> >> >>>> Bummer, seems we can't lock this down :(
>>> >> >>>> https://jira.atlassian.com/browse/JRASERVER-42068
>>> >> >>>>
>>> >> >>>> On Fri, Apr 14, 2017 at 9:42 AM Mark Miller
>>> >> >>>> <[hidden email]>
>>> >> >>>> wrote:
>>> >> >>>>>
>>> >> >>>>> On Fri, Apr 14, 2017 at 9:37 AM Cassandra Targett
>>> >> >>>>> <[hidden email]> 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.
>>> >> >>>>>
>>> >> >>>>>
>>> >> >>>>> Ah, that makes this a lot less baffling I guess.
>>> >> >>>>>
>>> >> >>>>>>
>>> >> >>>>>>
>>> >> >>>>>> 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.
>>> >> >>>>>
>>> >> >>>>>
>>> >> >>>>> +1!
>>> >> >>>>>
>>> >> >>>>>>
>>> >> >>>>>>
>>> >> >>>>>> 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.
>>> >> >>>>>
>>> >> >>>>>
>>> >> >>>>> I agree.
>>> >> >>>>>
>>> >> >>>>>>
>>> >> >>>>>>
>>> >> >>>>>> 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.
>>> >> >>>>>
>>> >> >>>>>
>>> >> >>>>> +1. It also matches how we handle CHANGES afaict.
>>> >> >>>>>
>>> >> >>>>> I wish we could disable the auto creating of versions entirely
>>> >> >>>>> somehow,
>>> >> >>>>> but I guess the next best thing is to raise awareness. It's great
>>> >> >>>>> to
>>> >> >>>>> have
>>> >> >>>>> the correct versions and in the correct ordering.
>>> >> >>>>>
>>> >> >>>>> - Mark
>>> >> >>>>>
>>> >> >>>>>>
>>> >> >>>>>>
>>> >> >>>>>> 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
>>> >> >>>>>> <[hidden email]>
>>> >> >>>>>> 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: [hidden email]
>>> >> >>>>>> For additional commands, e-mail: [hidden email]
>>> >> >>>>>>
>>> >> >>>>> --
>>> >> >>>>> - Mark
>>> >> >>>>> about.me/markrmiller
>>> >> >>>>
>>> >> >>>> --
>>> >> >>>> - Mark
>>> >> >>>> about.me/markrmiller
>>> >> >>>
>>> >> >>> --
>>> >> >>> - Mark
>>> >> >>> about.me/markrmiller
>>> >> >>
>>> >> >> --
>>> >> >> - Mark
>>> >> >> about.me/markrmiller
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: [hidden email]
>>> >> For additional commands, e-mail: [hidden email]
>>> >>
>>> > --
>>> > - Mark
>>> > about.me/markrmiller
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>> --
>> - Mark
>> about.me/markrmiller
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Strange Solr JIRA versions

Mark Miller-3
Something to look into. That might actually. E something we can configure correctly rather than also giving admin.
On Fri, Apr 14, 2017 at 3:25 PM Tomás Fernández Löbbe <[hidden email]> wrote:
Isn't the PMC group required to see issues with security level "private"?

On Fri, Apr 14, 2017 at 11:44 AM, Cassandra Targett <[hidden email]> wrote:
I'm also +1 to removing PMC group - I checked and every permission PMC
group has, administrators also have so consolidating those 2 groups
should have no impact on people.

I'd be happy to have admin access, and I will help keep my eyes out
for problems like this in the future.

On Fri, Apr 14, 2017 at 1:36 PM, Erick Erickson <[hidden email]> wrote:
> bq: my proposal would be to get rid of that PMC group (which is like
> more admins), clear the admin group, and seed it with anyone that
> calls out wanting access
>
> +1
>
> On Fri, Apr 14, 2017 at 10:45 AM, Mark Miller <[hidden email]> wrote:
>> bq. Personally I'm fine with not being an administrator as long as I can
>> assign JIRAs to myself and resolve them.
>>
>> I think that is 80-90% of us. The only time I ever use admin is to fix
>> version stuff like this or do a release. I think Jenkins access might work
>> this way, you have to request it. It would also be great if like the
>> committer role could manage versions, but I couldn't seem to find that
>> feature.
>>
>> But anyway, my proposal would be to get rid of that PMC group (which is like
>> more admins), clear the admin group, and seed it with anyone that calls out
>> wanting access, and then give access as requested from there out, extra
>> points for a warning about this 'feature' and managing versions consistently
>> with the past unless there is discussion.
>>
>> - Mark
>>
>> On Fri, Apr 14, 2017 at 1:06 PM Erick Erickson <[hidden email]>
>> wrote:
>>>
>>> I agree with all your points and would _much_ rather be unable to
>>> screw up even if it meant jumping through another hoop on those rare
>>> occasions when I needed more authority.
>>>
>>> Personally I'm fine with not being an administrator as long as I can
>>> assign JIRAs to myself and resolve them.
>>>
>>> On Fri, Apr 14, 2017 at 9:34 AM, Mark Miller <[hidden email]>
>>> wrote:
>>> > The problem is not so much notifying people, because no one is closely
>>> > monitoring this stuff. By the time we ever notice it and attempt to fix
>>> > it,
>>> > there are 40-200 issues involved. You are not the only one. And I would
>>> > be
>>> > angry at you! If not for the fact that it's a terrible JIRA issue that
>>> > did
>>> > not used to be a problem. But, ok, you have learned this JIRA 'feature'
>>> > is a
>>> > problem. What about those not reading this, what about future
>>> > committers,
>>> > what about you go away for a year and come back having forgotten. The
>>> > JIRA
>>> > issue to fix this in JIRA has tons of votes, but it's also old, so no
>>> > help
>>> > from Atlassian likely any time soon. You can read the comments on the
>>> > bug
>>> > report and lots of people have this problem and hate it. The devs doing
>>> > it
>>> > here are not special, that's obvious.
>>> >
>>> > I'm not sure why we have so many admins though. Sure, if you do a
>>> > release,
>>> > you want to be able to manage the versions, but a huge number of
>>> > committers
>>> > have not done a release and could request admin when needed. Then we
>>> > could
>>> > grant it, and be like, by the way, careful with your god like powers to
>>> > create stuff out of thin air without realizing.
>>> >
>>> > Perhaps the other reason most might use admin power is to add someone,
>>> > but I
>>> > think only a subset of people do that as well currently.
>>> >
>>> > - Mark
>>> >
>>> > On Fri, Apr 14, 2017 at 12:28 PM Erick Erickson
>>> > <[hidden email]>
>>> > wrote:
>>> >>
>>> >> Hmmm, and come to think of it I'm pretty sure I resolved some "fix
>>> >> versions" as "trunk", which is also incorrect.
>>> >>
>>> >> Well, now I know.
>>> >>
>>> >> On Fri, Apr 14, 2017 at 9:21 AM, Erick Erickson
>>> >> <[hidden email]>
>>> >> wrote:
>>> >> > If you look at the "history" tab on the JIRA you can see who set what
>>> >> > values when. I checked 4-5 of the JIRAS and the person who set those
>>> >> > has a long record of being very conscientious about changes so I'm
>>> >> > certain it's just an awareness issue, at least for that person. I'll
>>> >> > ping....
>>> >> >
>>> >> > Which suggests a way to raise awareness going forward: check the
>>> >> > history and send a message.
>>> >> >
>>> >> > If that doesn't cure it we can consider harsher measures, although I
>>> >> > don't think forbidding arbitrary labels is "harsh", it's just too bad
>>> >> > we can't.
>>> >> >
>>> >> > Erick
>>> >> >
>>> >> > On Fri, Apr 14, 2017 at 7:56 AM, Mark Miller <[hidden email]>
>>> >> > wrote:
>>> >> >> I wish hossman was still more active in this type of thing. He would
>>> >> >> have
>>> >> >> sworn more and fixed it more meticulously and probably earlier. Or
>>> >> >> maybe he
>>> >> >> is sick of it after last time. Anyway, I did what I could, preserved
>>> >> >> the
>>> >> >> proper versions I could, and it's clean again for now.
>>> >> >>
>>> >> >> I'm halfway serious about the admin thing given you can easily auto
>>> >> >> create
>>> >> >> components and versions by accident. Maybe instead of giving it to
>>> >> >> everyone
>>> >> >> by default, we should be doing it by request.
>>> >> >>
>>> >> >> - Mark
>>> >> >>
>>> >> >> On Fri, Apr 14, 2017 at 10:29 AM Mark Miller <[hidden email]>
>>> >> >> wrote:
>>> >> >>>
>>> >> >>> Perhaps everyone doesn't need to be a JIRA admin? Like people that
>>> >> >>> add
>>> >> >>> new
>>> >> >>> bad versions in the future ;) This is no fun to cleanup.
>>> >> >>>
>>> >> >>> - Mark
>>> >> >>>
>>> >> >>> On Fri, Apr 14, 2017 at 10:23 AM Mark Miller
>>> >> >>> <[hidden email]>
>>> >> >>> wrote:
>>> >> >>>>
>>> >> >>>> Bummer, seems we can't lock this down :(
>>> >> >>>> https://jira.atlassian.com/browse/JRASERVER-42068
>>> >> >>>>
>>> >> >>>> On Fri, Apr 14, 2017 at 9:42 AM Mark Miller
>>> >> >>>> <[hidden email]>
>>> >> >>>> wrote:
>>> >> >>>>>
>>> >> >>>>> On Fri, Apr 14, 2017 at 9:37 AM Cassandra Targett
>>> >> >>>>> <[hidden email]> 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.
>>> >> >>>>>
>>> >> >>>>>
>>> >> >>>>> Ah, that makes this a lot less baffling I guess.
>>> >> >>>>>
>>> >> >>>>>>
>>> >> >>>>>>
>>> >> >>>>>> 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.
>>> >> >>>>>
>>> >> >>>>>
>>> >> >>>>> +1!
>>> >> >>>>>
>>> >> >>>>>>
>>> >> >>>>>>
>>> >> >>>>>> 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.
>>> >> >>>>>
>>> >> >>>>>
>>> >> >>>>> I agree.
>>> >> >>>>>
>>> >> >>>>>>
>>> >> >>>>>>
>>> >> >>>>>> 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.
>>> >> >>>>>
>>> >> >>>>>
>>> >> >>>>> +1. It also matches how we handle CHANGES afaict.
>>> >> >>>>>
>>> >> >>>>> I wish we could disable the auto creating of versions entirely
>>> >> >>>>> somehow,
>>> >> >>>>> but I guess the next best thing is to raise awareness. It's great
>>> >> >>>>> to
>>> >> >>>>> have
>>> >> >>>>> the correct versions and in the correct ordering.
>>> >> >>>>>
>>> >> >>>>> - Mark
>>> >> >>>>>
>>> >> >>>>>>
>>> >> >>>>>>
>>> >> >>>>>> 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
>>> >> >>>>>> <[hidden email]>
>>> >> >>>>>> 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: [hidden email]
>>> >> >>>>>> For additional commands, e-mail: [hidden email]
>>> >> >>>>>>
>>> >> >>>>> --
>>> >> >>>>> - Mark
>>> >> >>>>> about.me/markrmiller
>>> >> >>>>
>>> >> >>>> --
>>> >> >>>> - Mark
>>> >> >>>> about.me/markrmiller
>>> >> >>>
>>> >> >>> --
>>> >> >>> - Mark
>>> >> >>> about.me/markrmiller
>>> >> >>
>>> >> >> --
>>> >> >> - Mark
>>> >> >> about.me/markrmiller
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: [hidden email]
>>> >> For additional commands, e-mail: [hidden email]
>>> >>
>>> > --
>>> > - Mark
>>> > about.me/markrmiller
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>> --
>> - Mark
>> about.me/markrmiller
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


--
Reply | Threaded
Open this post in threaded view
|

Re: Strange Solr JIRA versions

Cassandra Targett
Yes, Tomás is right - currently "private" issues are set to be seen by
only members of the PMC group and the reporter only. That's a separate
permissions config (grrrr Atlassian) that I neglected to check last
week.

We could instead change that to allow "private" issues to be seen by
Admins, but then we need to make sure that only PMC members are Admins
and that would shrink the pool of people who are eligible to do
releases. So, that won't work.

I guess we'll have to keep both groups, but update the people who are
Admins to the people who want to be (or need to be to do a release)
and retain the list of PMCs as a separate group. Unless someone can
think of another way.

On Fri, Apr 14, 2017 at 2:49 PM, Mark Miller <[hidden email]> wrote:

> Something to look into. That might actually. E something we can configure
> correctly rather than also giving admin.
> On Fri, Apr 14, 2017 at 3:25 PM Tomás Fernández Löbbe
> <[hidden email]> wrote:
>>
>> Isn't the PMC group required to see issues with security level "private"?
>>
>> On Fri, Apr 14, 2017 at 11:44 AM, Cassandra Targett
>> <[hidden email]> wrote:
>>>
>>> I'm also +1 to removing PMC group - I checked and every permission PMC
>>> group has, administrators also have so consolidating those 2 groups
>>> should have no impact on people.
>>>
>>> I'd be happy to have admin access, and I will help keep my eyes out
>>> for problems like this in the future.
>>>
>>> On Fri, Apr 14, 2017 at 1:36 PM, Erick Erickson <[hidden email]>
>>> wrote:
>>> > bq: my proposal would be to get rid of that PMC group (which is like
>>> > more admins), clear the admin group, and seed it with anyone that
>>> > calls out wanting access
>>> >
>>> > +1
>>> >
>>> > On Fri, Apr 14, 2017 at 10:45 AM, Mark Miller <[hidden email]>
>>> > wrote:
>>> >> bq. Personally I'm fine with not being an administrator as long as I
>>> >> can
>>> >> assign JIRAs to myself and resolve them.
>>> >>
>>> >> I think that is 80-90% of us. The only time I ever use admin is to fix
>>> >> version stuff like this or do a release. I think Jenkins access might
>>> >> work
>>> >> this way, you have to request it. It would also be great if like the
>>> >> committer role could manage versions, but I couldn't seem to find that
>>> >> feature.
>>> >>
>>> >> But anyway, my proposal would be to get rid of that PMC group (which
>>> >> is like
>>> >> more admins), clear the admin group, and seed it with anyone that
>>> >> calls out
>>> >> wanting access, and then give access as requested from there out,
>>> >> extra
>>> >> points for a warning about this 'feature' and managing versions
>>> >> consistently
>>> >> with the past unless there is discussion.
>>> >>
>>> >> - Mark
>>> >>
>>> >> On Fri, Apr 14, 2017 at 1:06 PM Erick Erickson
>>> >> <[hidden email]>
>>> >> wrote:
>>> >>>
>>> >>> I agree with all your points and would _much_ rather be unable to
>>> >>> screw up even if it meant jumping through another hoop on those rare
>>> >>> occasions when I needed more authority.
>>> >>>
>>> >>> Personally I'm fine with not being an administrator as long as I can
>>> >>> assign JIRAs to myself and resolve them.
>>> >>>
>>> >>> On Fri, Apr 14, 2017 at 9:34 AM, Mark Miller <[hidden email]>
>>> >>> wrote:
>>> >>> > The problem is not so much notifying people, because no one is
>>> >>> > closely
>>> >>> > monitoring this stuff. By the time we ever notice it and attempt to
>>> >>> > fix
>>> >>> > it,
>>> >>> > there are 40-200 issues involved. You are not the only one. And I
>>> >>> > would
>>> >>> > be
>>> >>> > angry at you! If not for the fact that it's a terrible JIRA issue
>>> >>> > that
>>> >>> > did
>>> >>> > not used to be a problem. But, ok, you have learned this JIRA
>>> >>> > 'feature'
>>> >>> > is a
>>> >>> > problem. What about those not reading this, what about future
>>> >>> > committers,
>>> >>> > what about you go away for a year and come back having forgotten.
>>> >>> > The
>>> >>> > JIRA
>>> >>> > issue to fix this in JIRA has tons of votes, but it's also old, so
>>> >>> > no
>>> >>> > help
>>> >>> > from Atlassian likely any time soon. You can read the comments on
>>> >>> > the
>>> >>> > bug
>>> >>> > report and lots of people have this problem and hate it. The devs
>>> >>> > doing
>>> >>> > it
>>> >>> > here are not special, that's obvious.
>>> >>> >
>>> >>> > I'm not sure why we have so many admins though. Sure, if you do a
>>> >>> > release,
>>> >>> > you want to be able to manage the versions, but a huge number of
>>> >>> > committers
>>> >>> > have not done a release and could request admin when needed. Then
>>> >>> > we
>>> >>> > could
>>> >>> > grant it, and be like, by the way, careful with your god like
>>> >>> > powers to
>>> >>> > create stuff out of thin air without realizing.
>>> >>> >
>>> >>> > Perhaps the other reason most might use admin power is to add
>>> >>> > someone,
>>> >>> > but I
>>> >>> > think only a subset of people do that as well currently.
>>> >>> >
>>> >>> > - Mark
>>> >>> >
>>> >>> > On Fri, Apr 14, 2017 at 12:28 PM Erick Erickson
>>> >>> > <[hidden email]>
>>> >>> > wrote:
>>> >>> >>
>>> >>> >> Hmmm, and come to think of it I'm pretty sure I resolved some "fix
>>> >>> >> versions" as "trunk", which is also incorrect.
>>> >>> >>
>>> >>> >> Well, now I know.
>>> >>> >>
>>> >>> >> On Fri, Apr 14, 2017 at 9:21 AM, Erick Erickson
>>> >>> >> <[hidden email]>
>>> >>> >> wrote:
>>> >>> >> > If you look at the "history" tab on the JIRA you can see who set
>>> >>> >> > what
>>> >>> >> > values when. I checked 4-5 of the JIRAS and the person who set
>>> >>> >> > those
>>> >>> >> > has a long record of being very conscientious about changes so
>>> >>> >> > I'm
>>> >>> >> > certain it's just an awareness issue, at least for that person.
>>> >>> >> > I'll
>>> >>> >> > ping....
>>> >>> >> >
>>> >>> >> > Which suggests a way to raise awareness going forward: check the
>>> >>> >> > history and send a message.
>>> >>> >> >
>>> >>> >> > If that doesn't cure it we can consider harsher measures,
>>> >>> >> > although I
>>> >>> >> > don't think forbidding arbitrary labels is "harsh", it's just
>>> >>> >> > too bad
>>> >>> >> > we can't.
>>> >>> >> >
>>> >>> >> > Erick
>>> >>> >> >
>>> >>> >> > On Fri, Apr 14, 2017 at 7:56 AM, Mark Miller
>>> >>> >> > <[hidden email]>
>>> >>> >> > wrote:
>>> >>> >> >> I wish hossman was still more active in this type of thing. He
>>> >>> >> >> would
>>> >>> >> >> have
>>> >>> >> >> sworn more and fixed it more meticulously and probably earlier.
>>> >>> >> >> Or
>>> >>> >> >> maybe he
>>> >>> >> >> is sick of it after last time. Anyway, I did what I could,
>>> >>> >> >> preserved
>>> >>> >> >> the
>>> >>> >> >> proper versions I could, and it's clean again for now.
>>> >>> >> >>
>>> >>> >> >> I'm halfway serious about the admin thing given you can easily
>>> >>> >> >> auto
>>> >>> >> >> create
>>> >>> >> >> components and versions by accident. Maybe instead of giving it
>>> >>> >> >> to
>>> >>> >> >> everyone
>>> >>> >> >> by default, we should be doing it by request.
>>> >>> >> >>
>>> >>> >> >> - Mark
>>> >>> >> >>
>>> >>> >> >> On Fri, Apr 14, 2017 at 10:29 AM Mark Miller
>>> >>> >> >> <[hidden email]>
>>> >>> >> >> wrote:
>>> >>> >> >>>
>>> >>> >> >>> Perhaps everyone doesn't need to be a JIRA admin? Like people
>>> >>> >> >>> that
>>> >>> >> >>> add
>>> >>> >> >>> new
>>> >>> >> >>> bad versions in the future ;) This is no fun to cleanup.
>>> >>> >> >>>
>>> >>> >> >>> - Mark
>>> >>> >> >>>
>>> >>> >> >>> On Fri, Apr 14, 2017 at 10:23 AM Mark Miller
>>> >>> >> >>> <[hidden email]>
>>> >>> >> >>> wrote:
>>> >>> >> >>>>
>>> >>> >> >>>> Bummer, seems we can't lock this down :(
>>> >>> >> >>>> https://jira.atlassian.com/browse/JRASERVER-42068
>>> >>> >> >>>>
>>> >>> >> >>>> On Fri, Apr 14, 2017 at 9:42 AM Mark Miller
>>> >>> >> >>>> <[hidden email]>
>>> >>> >> >>>> wrote:
>>> >>> >> >>>>>
>>> >>> >> >>>>> On Fri, Apr 14, 2017 at 9:37 AM Cassandra Targett
>>> >>> >> >>>>> <[hidden email]> 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.
>>> >>> >> >>>>>
>>> >>> >> >>>>>
>>> >>> >> >>>>> Ah, that makes this a lot less baffling I guess.
>>> >>> >> >>>>>
>>> >>> >> >>>>>>
>>> >>> >> >>>>>>
>>> >>> >> >>>>>> 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.
>>> >>> >> >>>>>
>>> >>> >> >>>>>
>>> >>> >> >>>>> +1!
>>> >>> >> >>>>>
>>> >>> >> >>>>>>
>>> >>> >> >>>>>>
>>> >>> >> >>>>>> 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.
>>> >>> >> >>>>>
>>> >>> >> >>>>>
>>> >>> >> >>>>> I agree.
>>> >>> >> >>>>>
>>> >>> >> >>>>>>
>>> >>> >> >>>>>>
>>> >>> >> >>>>>> 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.
>>> >>> >> >>>>>
>>> >>> >> >>>>>
>>> >>> >> >>>>> +1. It also matches how we handle CHANGES afaict.
>>> >>> >> >>>>>
>>> >>> >> >>>>> I wish we could disable the auto creating of versions
>>> >>> >> >>>>> entirely
>>> >>> >> >>>>> somehow,
>>> >>> >> >>>>> but I guess the next best thing is to raise awareness. It's
>>> >>> >> >>>>> great
>>> >>> >> >>>>> to
>>> >>> >> >>>>> have
>>> >>> >> >>>>> the correct versions and in the correct ordering.
>>> >>> >> >>>>>
>>> >>> >> >>>>> - Mark
>>> >>> >> >>>>>
>>> >>> >> >>>>>>
>>> >>> >> >>>>>>
>>> >>> >> >>>>>> 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
>>> >>> >> >>>>>> <[hidden email]>
>>> >>> >> >>>>>> 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: [hidden email]
>>> >>> >> >>>>>> For additional commands, e-mail: [hidden email]
>>> >>> >> >>>>>>
>>> >>> >> >>>>> --
>>> >>> >> >>>>> - Mark
>>> >>> >> >>>>> about.me/markrmiller
>>> >>> >> >>>>
>>> >>> >> >>>> --
>>> >>> >> >>>> - Mark
>>> >>> >> >>>> about.me/markrmiller
>>> >>> >> >>>
>>> >>> >> >>> --
>>> >>> >> >>> - Mark
>>> >>> >> >>> about.me/markrmiller
>>> >>> >> >>
>>> >>> >> >> --
>>> >>> >> >> - Mark
>>> >>> >> >> about.me/markrmiller
>>> >>> >>
>>> >>> >>
>>> >>> >> ---------------------------------------------------------------------
>>> >>> >> To unsubscribe, e-mail: [hidden email]
>>> >>> >> For additional commands, e-mail: [hidden email]
>>> >>> >>
>>> >>> > --
>>> >>> > - Mark
>>> >>> > about.me/markrmiller
>>> >>>
>>> >>> ---------------------------------------------------------------------
>>> >>> To unsubscribe, e-mail: [hidden email]
>>> >>> For additional commands, e-mail: [hidden email]
>>> >>>
>>> >> --
>>> >> - Mark
>>> >> about.me/markrmiller
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: [hidden email]
>>> > For additional commands, e-mail: [hidden email]
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
> --
> - Mark
> about.me/markrmiller

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Strange Solr JIRA versions

Christine Poerschke (BLOOMBERG/ LONDON)
In reply to this post by Mark Miller-3
Joining the conversation late here.

I've been using fixVersion 6.x in the honest belief that:
* that was the done thing (and now i know that it isn't, oops)
* what is displayed as 6.x now will in future become 6.6 (when 6.6 is released) or it will stay 6.x (if there is no 6.6 release)
* if a 6.x label exists then it can and even should be used (that is not so)

Thanks for bringing this up and for fixing the mislabeled issues.

Going forward I'm happy to keep an eye on this type of thing though I won't be able to match others on the "would have sworn more" style point you mention.

Christine

----- Original Message -----
From: [hidden email]
To: [hidden email]
At: 04/14/17 17:22:44

If you look at the "history" tab on the JIRA you can see who set what
values when. I checked 4-5 of the JIRAS and the person who set those
has a long record of being very conscientious about changes so I'm
certain it's just an awareness issue, at least for that person. I'll
ping....

Which suggests a way to raise awareness going forward: check the
history and send a message.

If that doesn't cure it we can consider harsher measures, although I
don't think forbidding arbitrary labels is "harsh", it's just too bad
we can't.

Erick

On Fri, Apr 14, 2017 at 7:56 AM, Mark Miller <[hidden email]> wrote:

> I wish hossman was still more active in this type of thing. He would have
> sworn more and fixed it more meticulously and probably earlier. Or maybe he
> is sick of it after last time. Anyway, I did what I could, preserved the
> proper versions I could, and it's clean again for now.
>
> I'm halfway serious about the admin thing given you can easily auto create
> components and versions by accident. Maybe instead of giving it to everyone
> by default, we should be doing it by request.
>
> - Mark
>
> On Fri, Apr 14, 2017 at 10:29 AM Mark Miller <[hidden email]> wrote:
>>
>> Perhaps everyone doesn't need to be a JIRA admin? Like people that add new
>> bad versions in the future ;) This is no fun to cleanup.
>>
>> - Mark
>>
>> On Fri, Apr 14, 2017 at 10:23 AM Mark Miller <[hidden email]>
>> wrote:
>>>
>>> Bummer, seems we can't lock this down :(
>>> https://jira.atlassian.com/browse/JRASERVER-42068
>>>
>>> On Fri, Apr 14, 2017 at 9:42 AM Mark Miller <[hidden email]>
>>> wrote:
>>>>
>>>> On Fri, Apr 14, 2017 at 9:37 AM Cassandra Targett
>>>> <[hidden email]> 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.
>>>>
>>>>
>>>> Ah, that makes this a lot less baffling I guess.
>>>>
>>>>>
>>>>>
>>>>> 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.
>>>>
>>>>
>>>> +1!
>>>>
>>>>>
>>>>>
>>>>> 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.
>>>>
>>>>
>>>> I agree.
>>>>
>>>>>
>>>>>
>>>>> 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.
>>>>
>>>>
>>>> +1. It also matches how we handle CHANGES afaict.
>>>>
>>>> I wish we could disable the auto creating of versions entirely somehow,
>>>> but I guess the next best thing is to raise awareness. It's great to have
>>>> the correct versions and in the correct ordering.
>>>>
>>>> - Mark
>>>>
>>>>>
>>>>>
>>>>> 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 <[hidden email]>
>>>>> 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: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>> --
>>>> - Mark
>>>> about.me/markrmiller
>>>
>>> --
>>> - Mark
>>> about.me/markrmiller
>>
>> --
>> - Mark
>> about.me/markrmiller
>
> --
> - Mark
> about.me/markrmiller

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Strange Solr JIRA versions

Mark Miller-3
Hossman is the only one that can swear more and get away with it. Pact with the devil or something.
On Tue, Apr 18, 2017 at 8:41 AM Christine Poerschke (BLOOMBERG/ LONDON) <[hidden email]> wrote:
Joining the conversation late here.

I've been using fixVersion 6.x in the honest belief that:
* that was the done thing (and now i know that it isn't, oops)
* what is displayed as 6.x now will in future become 6.6 (when 6.6 is released) or it will stay 6.x (if there is no 6.6 release)
* if a 6.x label exists then it can and even should be used (that is not so)

Thanks for bringing this up and for fixing the mislabeled issues.

Going forward I'm happy to keep an eye on this type of thing though I won't be able to match others on the "would have sworn more" style point you mention.

Christine

----- Original Message -----
From: [hidden email]
To: [hidden email]
At: 04/14/17 17:22:44

If you look at the "history" tab on the JIRA you can see who set what
values when. I checked 4-5 of the JIRAS and the person who set those
has a long record of being very conscientious about changes so I'm
certain it's just an awareness issue, at least for that person. I'll
ping....

Which suggests a way to raise awareness going forward: check the
history and send a message.

If that doesn't cure it we can consider harsher measures, although I
don't think forbidding arbitrary labels is "harsh", it's just too bad
we can't.

Erick

On Fri, Apr 14, 2017 at 7:56 AM, Mark Miller <[hidden email]> wrote:
> I wish hossman was still more active in this type of thing. He would have
> sworn more and fixed it more meticulously and probably earlier. Or maybe he
> is sick of it after last time. Anyway, I did what I could, preserved the
> proper versions I could, and it's clean again for now.
>
> I'm halfway serious about the admin thing given you can easily auto create
> components and versions by accident. Maybe instead of giving it to everyone
> by default, we should be doing it by request.
>
> - Mark
>
> On Fri, Apr 14, 2017 at 10:29 AM Mark Miller <[hidden email]> wrote:
>>
>> Perhaps everyone doesn't need to be a JIRA admin? Like people that add new
>> bad versions in the future ;) This is no fun to cleanup.
>>
>> - Mark
>>
>> On Fri, Apr 14, 2017 at 10:23 AM Mark Miller <[hidden email]>
>> wrote:
>>>
>>> Bummer, seems we can't lock this down :(
>>> https://jira.atlassian.com/browse/JRASERVER-42068
>>>
>>> On Fri, Apr 14, 2017 at 9:42 AM Mark Miller <[hidden email]>
>>> wrote:
>>>>
>>>> On Fri, Apr 14, 2017 at 9:37 AM Cassandra Targett
>>>> <[hidden email]> 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.
>>>>
>>>>
>>>> Ah, that makes this a lot less baffling I guess.
>>>>
>>>>>
>>>>>
>>>>> 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.
>>>>
>>>>
>>>> +1!
>>>>
>>>>>
>>>>>
>>>>> 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.
>>>>
>>>>
>>>> I agree.
>>>>
>>>>>
>>>>>
>>>>> 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.
>>>>
>>>>
>>>> +1. It also matches how we handle CHANGES afaict.
>>>>
>>>> I wish we could disable the auto creating of versions entirely somehow,
>>>> but I guess the next best thing is to raise awareness. It's great to have
>>>> the correct versions and in the correct ordering.
>>>>
>>>> - Mark
>>>>
>>>>>
>>>>>
>>>>> 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 <[hidden email]>
>>>>> 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: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>> --
>>>> - Mark
>>>> about.me/markrmiller
>>>
>>> --
>>> - Mark
>>> about.me/markrmiller
>>
>> --
>> - Mark
>> about.me/markrmiller
>
> --
> - Mark
> about.me/markrmiller

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


--
123