On Dec 25 15:16:24, [email protected] 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
