Fix Sierra Trac query

Mon Dec 25 21:16:24 UTC 2017

On Dec 25, 2017, at 04:34, Jan Stary wrote:

> On Dec 24 13:56:08, Ryan Schmidt 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.
> The confusion of also having names of cats and mountains
> for the old releases will eventually die out as they get older.

There's nothing "non-adult" about using marketing names. No need to insult us for trying to manage MacPorts as best we can.

I'll repeat myself again: I don't want the confusion of needing to remember to search for old-OS tickets with the OS marketing name and new-OS tickets with the version number. I want a single consistent method for all tickets. That's what we currently have, which is why I'm in favor of keeping it that way. We could try to fix that method, which is what I opened this email thread to invite discussion about, or we could change the method, as you advocate.

>>>> 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?

Correct, Trac does not have a regular expression search feature. There's a very old ticket in Trac's upstream issue tracker requesting that feature. One possible avenue of exploration would be for us to attempt to resolve that issue and implement regex search in Trac.

>>> 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?

I don't remember why we originally used the marketing name instead of the version number. At this point, we continue to do so for the sake of consistency.

>>> 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?

Oops, I misspoke: I meant to say: the query on the SierraProblems page says to find tickets where the keywords field contains the substring *sierra* but not the substring *highsierra*. If this were not done, the SierraProblems page would also list all High Sierra tickets, because "sierra" is a substring of "highsierra". But excluding tickets that include the substring "highsierra" in the keywords field on the SierraProblems page is not what we want, because some tickets might list *both* the highsierra keyword and the sierra keyword. That was the point of this email thread: to invite someone to figure out a way to solve that problem.

>>> 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?

It shows tickets having the keywords, and also tickets using likely words in the summary, because some submitters put OS versions or names into the summary instead of following our directions and putting it in the keywords.

>>>> 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.

Yes it could conceivably be done with raw SQL queries in the database.

> 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?

The *Problems wiki pages each have multiple queries. This is because Trac's query syntax is not sufficiently advanced to allow us to construct a single query that would return all results. Each query produces a list of tickets, and the lists are separated by some whitespace because that's what Trac wants to do. You can edit the pages and see what the queries are doing if you like. On the SnowLeopardProblems page, the third set of results are those containing the keyword LP64, since Snow Leopard was the first macOS version that compiled for 64-bit by default.

>> 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.

Ok. But I want to anticipate possible complaints from the rest of the MacPorts user population as well.