Fix Sierra Trac query

Tue Dec 26 00:47:11 UTC 2017

On 2017-12-25 11:34, Jan Stary wrote:
> On Dec 24 13:56:08, ryandesign at macports.org wrote:
>>>>> Perhaps Chris is suggesting to just change the tag going forward.
>>>> I would find that more confusing.
>>>
>>> How is "10.13" confusing?
>>> How is it more confusing than "High Sierra"?
>>
>> I meant that I would find it more confusing to use two different ways of tagging OS versions in the issue tracker, depending on the version of the OS. I would find it simpler to use a single way to tag all OS versions in the issue tracker.
> 
> So let's start tagging with the version numbers, like adults.

Please do not belittle the established keywords and processes. They
might not be perfect, but that is no reason to mock them. At the time
they were introduced, this problem just did not exist as there was no
overlap in the keywords.

> The confusion of also having names of cats and mountains
> for the old releases will eventually die out as they get older.

I doubt so, since Apple always introduced a codename for each release.
What makes you think they would stop this?

>>>> I really didn't intend to start a big discussion here.
>>>> I just wanted to point out a small issue with one of our wiki pages
>>>> and to invite someone with interest in fixing the page to do so.
>>>
>>> The point of that page, if I get it, is to list problems
>>> specific to that vesion of the OS, and it doesn't,
>>> precisely because "sierra" matches "highsierra" (right?).
>>> So using these silly names is precisely the problem, no?
> 
> Can someone please confirm this is the case?
> Is it because the tracker's querry cannot distinguish
> between ^sierra$ (as in grep -w) and "sierra" as a substring?

Apparently, yes. The search for "sierra" will match "highsierra", as it
contains the substring and there is no filter to match whole words only.

See Trac upstream: https://trac.edgewall.org/ticket/7558

>>> On Sep 26 15:58:04, smithsp wrote:
>>>> If I go to "Apple symbol" -> "About this mac",
>>>> I get a version number, not a name.
>>>
>>> Exactly. Why would you use anything else to identify the OS version?
>> "About this Mac" shows both the marketing name and the version number.
> 
> Yes it does. It also says 'macOS' where it used to say 'MacOSX'.
> How is a random marketing name better then a number?
> Why would you use that?

Most people are actually better with names than numbers when it comes to
memorize things. Furthermore, Apple advertises its OS this way. On my
Sierra installation, there is an update to "Install macOS High Sierra".

>>> On Sep 27 16:13:45, jonesc wrote:
>>>> As a test I tried adding highsierra as a keyword to
>>>> https://trac.macports.org/ticket/53161
>>>> and indeed it disappeared from the Sierra list.
>>>> I then changed the keyword from highsierra to 10.13 ... and it also did not
>>>> work.
>>>> It appears the logic in the code has never worked for these sorts of
>>>> keywords. I just fixed this and now the ticket appears in both lists.
>>>
>>> This ticket uses both keywords
>>> but only appears on the HighSierra list.
>>
>> Yup. That is because the query on the Sierra page says to find tickets having the keyword highsierra but not the keyword sierra. Which isn't really what we want.
> 
> Now I'm confused: why doesn't the query on that page
> just search for 'highsierra' (or better yet, 10.13.?),
> thus getting problems specific to that release
> - and possibly other releases too, if that's the case?
> 
>>> On the other hand,
>>> https://trac.macports.org/ticket/55262
>>> uses no keywords and appears on both lists.
>>
>> Yup. That's because the queries look not only in the keywords field
>> but also in the summary, and that ticket says "High Sierra" in the summary.
> 
> Ah, so it's _not_ a list if tickets saying the keyword in the keywords?

Just look at the source of the wiki page to see the actual query.

>>>> So one work around is to start to try and use 10.13 and 10.12 etc.,
>>>> instead of highsierra, sierra.
>>>
>>> Please.
>>
>> As I'm sure I said before in this thread, we could do that,
>> but I'm not thrilled about the massive amount of editing of existing tickets
>> required to convert all the existing keywords,
> 
> Would that need to be done maually?
> Isn't thee a "s/^tiger$/10.4/" to be run over the database?
> 
> Looking at
> 
> 	https://trac.macports.org/wiki/SnowLeopardProblems
> 	https://trac.macports.org/wiki/LionProblems
> 	https://trac.macports.org/wiki/MavericksProblems
> 	https://trac.macports.org/wiki/YosemiteProblems
> 	https://trac.macports.org/wiki/ElCapitanProblems
> 	https://trac.macports.org/wiki/SierraProblems
> 	https://trac.macports.org/wiki/HighSierraProblems
> 
> there seem to be about three hundred tickets.

Which are only the open tickets. There are many more in the database
that use one of these keywords.

> BTW, what are those "gaps" inbetween the sets of tickets
> on each of those pages? For example, for SnowLeopardProblems,
> there is 22 tickets + a few more + 1 ticket, in such sets.
> It seems that the first is those who say just 'snowleopard'
> in the keywords, the seconds set is those that say 'snowleopard'
> and possibly something else, and for https://trac.macports.org/ticket/20909
> I have no idea. How did it get there?

Indeed, the wiki page uses three separate queries. Maybe the person who
wrote this had no idea that combining operators like AND and OR exist.
Feel free to convert this into a single query.

>> and of all the email notifications that will go out to everyone as a result,
>> which some might start to view as spam...
> 
> If I get an email saying that keyword 'snowleopard' in my ticket
> has been changed to '10.6', I'll say hooray.

This feels like we would only postpone the problem. "10.1" would still
match 10.10/10.11/10.12/... Okay, tickets against 10.1 or 10.2 are
unlikely now, but somehow this means this format is not perfect either.
Imagine someone wants to be specific and uses a keyword like "10.10.6",
which suddenly gets matched by "10.6".

What we really want is a way to apply a regex or at least a filter with
"contains word". Unfortunately, we probably need to patch Trac to get that.

If we really want to do this, we would have to do it in the database and
not send out mails, as that would affect thousands of tickets.

Rainer