lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cassandra Targett <casstarg...@gmail.com>
Subject Re: Strange Solr JIRA versions
Date Fri, 14 Apr 2017 18:44:38 GMT
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 <erickerickson@gmail.com> 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 <markrmiller@gmail.com> 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 <erickerickson@gmail.com>
>> 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 <markrmiller@gmail.com>
>>> 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
>>> > <erickerickson@gmail.com>
>>> > 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
>>> >> <erickerickson@gmail.com>
>>> >> 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 <markrmiller@gmail.com>
>>> >> > 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 <markrmiller@gmail.com>
>>> >> >> 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
>>> >> >>> <markrmiller@gmail.com>
>>> >> >>> 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
>>> >> >>>> <markrmiller@gmail.com>
>>> >> >>>> wrote:
>>> >> >>>>>
>>> >> >>>>> On Fri, Apr 14, 2017 at 9:37 AM Cassandra Targett
>>> >> >>>>> <casstargett@gmail.com> wrote:
>>> >> >>>>>>
>>> >> >>>>>> I noticed these the other day also, and had
an email half-wrote
>>> >> >>>>>> that I
>>> >> >>>>>> intended to finish up today.
>>> >> >>>>>>
>>> >> >>>>>> To start, JIRA unfortunately makes this really
easy to make a
>>> >> >>>>>> mess
>>> >> >>>>>> of
>>> >> >>>>>> - if you can create or edit an issue, you can
just pop in a new
>>> >> >>>>>> value
>>> >> >>>>>> that gets added to the list of open versions.
Editing an issue
>>> >> >>>>>> is
>>> >> >>>>>> open
>>> >> >>>>>> to lots of folks - committers, contributors,
the reporter of an
>>> >> >>>>>> issue.
>>> >> >>>>>> So, we have high potential for this to be an
ongoing problem.
>>> >> >>>>>
>>> >> >>>>>
>>> >> >>>>> 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
>>> >> >>>>>> <markrmiller@gmail.com>
>>> >> >>>>>> wrote:
>>> >> >>>>>> > Who keeps adding strange JIRA release
versions? I've cleaned
>>> >> >>>>>> > up
>>> >> >>>>>> > strange ones
>>> >> >>>>>> > in the past and they keep coming back.
>>> >> >>>>>> >
>>> >> >>>>>> > Why do we have branch6x, 6x and 6.x and
trunk?
>>> >> >>>>>> >
>>> >> >>>>>> > Even if we wanted more than 6.1, 6.2,
6.2.1 and master (7.0),
>>> >> >>>>>> > and
>>> >> >>>>>> > I
>>> >> >>>>>> > don't
>>> >> >>>>>> > think we do, who keeps adding these duplicates?
Let's come to
>>> >> >>>>>> > some
>>> >> >>>>>> > sanity
>>> >> >>>>>> > here.
>>> >> >>>>>> >
>>> >> >>>>>> > - Mark
>>> >> >>>>>> > --
>>> >> >>>>>> > - Mark
>>> >> >>>>>> > about.me/markrmiller
>>> >> >>>>>>
>>> >> >>>>>>
>>> >> >>>>>>
>>> >> >>>>>> ---------------------------------------------------------------------
>>> >> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> >> >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>> >> >>>>>>
>>> >> >>>>> --
>>> >> >>>>> - Mark
>>> >> >>>>> about.me/markrmiller
>>> >> >>>>
>>> >> >>>> --
>>> >> >>>> - Mark
>>> >> >>>> about.me/markrmiller
>>> >> >>>
>>> >> >>> --
>>> >> >>> - Mark
>>> >> >>> about.me/markrmiller
>>> >> >>
>>> >> >> --
>>> >> >> - Mark
>>> >> >> about.me/markrmiller
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> >> For additional commands, e-mail: dev-help@lucene.apache.org
>>> >>
>>> > --
>>> > - Mark
>>> > about.me/markrmiller
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>> --
>> - Mark
>> about.me/markrmiller
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message