Fix Sierra Trac query

[Jan Stary]

On Dec 25 15:16:24, ryandesign at macports.org wrote:
> >>> 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.

Doesn't this alone rule out the method of using
keywords like "sierra" and "highsierra" to identify releases?

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

OK, I see now.

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


If the ${RELEASE}Problems wiki pages are supposed to do
what I think they are supposed to do, then the following
seems to be the obvious, least-surprise thing to do:

1. Choose a keyword that will uniquely identify each MacOS release
   (that MP supports); e.g. the version number is such a keyword.

2. Add this as a keyword to the keywords of every ticket
   which describes a problem related to that specific release.

3. Let the respective ${RELEASE}Problems wiki pages query
   for tickets having the respective keyword among their keywords.
   Let the pages display those and precisely those tickets.

Jan