Hi Björn,
thanks for the list of suggestions! > * First of all, I find this mixture very confusing: Is this about bugs > or is this about patches? I really don't know, and the start page is > ambigious about it too: > > "Guix /patch/ tracker > This is a web frontend to the Guix /issue/ trackers. > /Issues/ of interest > Priority /bugs/" I updated the text, but I think it’s not a good idea to have two separate trackers, because bug reports can have patches. > * Is it intentionally that there still is a http site? I would have > expected a redirect onto https. > > * http[s]://issues.guix.info/ is also still alive. Shouldn't it redirect > to http[s]://issues.guix.gnu.org/? This should be changed in maintenance.git. I would like a redirect to https://issues.guix.gnu.org/. I haven’t done this yet as I’m only focusing on mumi itself at this point. > * If you search for something, you get away from the homepage and > tips are missing. There should be a "help/tooltip" button near the > search input that explains the query language. The search results page now also has the search input widget with hints. Not sure how to handle the little search field in the menu bar, though. > * If you enter a query, that query should be kept in the input field. > Currently, it is discarded. That would make it more easy to update your > query. Yes, this has annoyed me too. The query is now kept. > * It is not clear to me how long a closed issue is still visible on the > home-page. Is it still an "Issue of interest" if it is closed? The idea was that you may want to look at issues that have just been closed to catch up (or to reopen them). But I guess closed issues could just be hidden. > * Sorting issues by columns would be cool. Done. > * Mumi has no paging: It only presents one page of issues, but it > doesn't say how many are there in total nor does it page through all > other pages of issues. Yes, this is a restriction due to debbugs. We can’t ask it for all issues and implementing paging is a little annoying. I think this will change as I’m making more and more features independent of debbugs requests. > * In that list, it is not clear what a red/orange colored bug-number > means: A tool-tip would be nice. I never liked those colors. There’s a little icon now with a tool-tip. > * A long desired feature is having general tags. It took me a very long > time until I realized that Debbugs allows user-tags. What about using a > common email address like "issues AT guix.gnu.org" and add user-tags > for that address, like "python", "core-updates", "release-1.1.x", etc. Sounds like a good idea. I don’t know if it even has to be an email address or if we can fake it. This deserves a closer look. > * I still don't see that all bugs and patches from the mailing list are > part of the mumi issues list? There was a problem with the worker process that fetched and indexed messages from Debbugs. > * The HTML could be responsive. It should be responsive with recent changes. > * The query syntax examples are only on the home page. Please repeat > them also on the help page. That I don’t understand. The help page has *more* examples, no? > * Either I don't understand the "date:<start>..<end>" semantics or it > is broken. The range yesterday..today lists no issues after 2015. Not > the "yesterday" I expected...: > > https://issues.guix.gnu.org/search?query=date%3Ayesterday..today Yeah, this is embarrassing… “yesterday” isn’t actually valid. I only just noticed that after a much longer debugging session than I feel comfortable admitting. The “proper” way to do this is to write “date:2d..”. I updated the help. > With numbers, it gets even more strange: > https://issues.guix.gnu.org/search?query=date%3A2020-03-29..2020-03-30 > --> Nothing found. This seems to be correct now. > Some more, but why are these selected?: > https://issues.guix.gnu.org/search?query=date%3A2020-03-29..2020-03-30 …this is the same query as above. They are selected because the discussion contains messages in the given range. > * Mdate does not find anything? > https://issues.guix.gnu.org/search?query=mdate%3A2w..12h mdate no longer exists (it was a debbugs search filter), but maybe it should be added again to distinguish between message dates and submission dates. I’ll add this to my list. Thanks again! -- Ricardo PS: When I say that something’s fixed I mean that it’s fixed in the repository, not necessarily in the public instance.
