Brainstorming features for issues.guix.gnu.org

Brainstorming features for issues.guix.gnu.org

[Ricardo Wurmus]

Hello Guix!

I want issues.guix.gnu.org to become more useful for all of us.  It’s
easy to get lost in a deluge of bug reports and patch submissions, so
our tools should allow us to stay afloat.

Do you use issues.guix.gnu.org?  If you aren’t: what workflow do you
have to review patch submissions?

If you do use it: what features do you think are missing?

Personally, I’d wish for a more streamlined workflow to download and
apply patch sets.  I don’t want to click on each “download” link in the
web interface.  Instead I would like to run something like

    ./etc/review 12345

which would fetch the patches in issue 12345 and apply them to my
git worktree.

I would also like to see neglected issues in the web interface, i.e. a
list of open issues that haven’t seen any response in a while and that
haven’t been tagged as awaiting more information from the submitter.
This should make it easier for us to prevent patches from slipping into
obscurity, which is a terrible thing to happen especially for new
contributors.

What do you think?

--
Ricardo

Re: Brainstorming features for issues.guix.gnu.org

[Arun Isaac]

[-- Attachment #1: Type: text/plain, Size: 1721 bytes --]


> Personally, I’d wish for a more streamlined workflow to download and
> apply patch sets.  I don’t want to click on each “download” link in the
> web interface.  Instead I would like to run something like
>
>     ./etc/review 12345
>
> which would fetch the patches in issue 12345 and apply them to my
> git worktree.

This feature would be very welcome. Perhaps we need an emacs interface
to mumi just as debbugs has an emacs interface. We could implement this
emacs interface by first implementing a HTTP API for mumi and then
making emacs interact with that HTTP API. But, I think it would be
better to simply run mumi locally. That is, we first pull all the latest
bug reports using something like `mumi pull` and then operate on the
local copy of bug reports. WDYT?

Also, the "download" link in mumi doesn't correctly download the patch
when the patch is sent using `git send-email`. This is because it
truncates the headers of the email that is required by `git am` to
correctly apply the patch. For example, see the second email in
https://issues.guix.info/issue/34948 Due to this bug, I often find
myself having to fall back to the debbugs web interface.

> I would also like to see neglected issues in the web interface

It would be nice to have the "Recent activity" and "Priority bugs" lists
on the home page load without javascript.

> list of open issues that haven’t seen any response in a while and that
> haven’t been tagged as awaiting more information from the submitter.
> This should make it easier for us to prevent patches from slipping into
> obscurity, which is a terrible thing to happen especially for new
> contributors.

I agree completely.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Brainstorming features for issues.guix.gnu.org

[Vincent Legoll]

Another idea:

Detect applied patches (idependently of the Done issue status)
because an issue may have more than one patch, or patch
revisions, and all may not be applicable / applied, etc.

-- 
Vincent Legoll

Re: Brainstorming features for issues.guix.gnu.org

[Vincent Legoll]

Hello,

On Thu, Mar 26, 2020 at 9:49 AM Ricardo Wurmus <rekado@elephly.net> wrote:
>
> Hello Guix!
>
> I want issues.guix.gnu.org to become more useful for all of us.

Yes, that is a nice goal, I have a few ideas.

> If you do use it: what features do you think are missing?

* I'd like to have a way to reverse the ordering of the results, especially
to get newer issues at the top (I think this should even be the default).

But as you say later, the "oldest first" view is also of interest, so
a classical
ordering combobox could be added

order-by:
- oldest to newest
- newest to oldest
- etc.

* The filtering hints are great (are they an exhaustive list, is there a full
list somewhere). But to ease their use, maybe they could be made
clickable, and a click on one could append it to the search entry, making
their usage from a "select, copy, change focus, paste, click search" into
"click item(s) from the hint list, click search"... This is not high
priority, but
maybe nice to have UI enhancement.

* the "is:Done" filtering shows some Open issues, is that a bug, or a
misunderstanding on my part about what is "Done"

> Personally, I’d wish for a more streamlined workflow to download and
> apply patch sets.  I don’t want to click on each “download” link in the
> web interface.  Instead I would like to run something like
>
>     ./etc/review 12345
>
> which would fetch the patches in issue 12345 and apply them to my
> git worktree.

or to a new branch (maybe you can take ideas from gerrit, not all of
it hopefully ;-))

> I would also like to see neglected issues in the web interface, i.e. a
> list of open issues that haven’t seen any response in a while and that
> haven’t been tagged as awaiting more information from the submitter.
> This should make it easier for us to prevent patches from slipping into
> obscurity, which is a terrible thing to happen especially for new
> contributors.

An indicator (à la Done, Open) could be added to make issues with
patches stand out.

Thanks for the great work BTW
Tchuss

-- 
Vincent Legoll

Re: Brainstorming features for issues.guix.gnu.org

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 1396 bytes --]

Hi!

Thanks for the effort, issues.guix.gnu.org is a great initiative in my
opinion.

I used to not use it much in the past because it was too slow and seemed
to timeout.  Since your recent fix this problem is gone so I will use it
more from now on.
(I use debbugs otherwise.)

> Personally, I’d wish for a more streamlined workflow to download and
> apply patch sets.  I don’t want to click on each “download” link in the
> web interface.  Instead I would like to run something like
>
>     ./etc/review 12345

That'd be great indeed!

Other suggestions:

- Add column ordering to search results.

- Add a live filter input field on top of the search results.  This is
  useful to narrow down large lists when the browser's "search feature"
  is too limited.

- From the search result page, there is no help about the search query
  syntax.  One has to go back to the main page and open
  https://issues.guix.info/help#search.
  What about adding a tooltip or a hint as on the main page:

--8<---------------cut here---------------start------------->8---
Hint: Refine your search with filters like is:open, author:me, submitter:me, date:yesterday..now, date:2018-04-01..2018-04-02, date:1m..today, mdate:2w..12h, and many more!
--8<---------------cut here---------------end--------------->8---

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Brainstorming features for issues.guix.gnu.org

[Vincent Legoll]

Looks like the "is:Done" bug is not a bug, but a case-sensitivity
issue on my side...

-- 
Vincent Legoll

Re: Brainstorming features for issues.guix.gnu.org

[Vincent Legoll]

filtering by severity maybe be of use (low, easy for newcomers, etc.)

-- 
Vincent Legoll

Re: Brainstorming features for issues.guix.gnu.org

[Ricardo Wurmus]

Vincent Legoll <vincent.legoll@gmail.com> writes:

> filtering by severity maybe be of use (low, easy for newcomers, etc.)

This already works for all severities that Debbugs supports.  For
example:

    https://issues.guix.gnu.org/search?query=severity%3Aserious+is%3Aopen

(28211 is included because of a bug: the issue has been moved to a
different package, so it is not included in the regular automated
updates of our database.)

We also have a dedicated page for easy issues:

    https://issues.guix.gnu.org/easy

The “severity” query filter should be documented, and we should probably
link to the “/easy” page somewhere.

--
Ricardo

Re: Brainstorming features for issues.guix.gnu.org

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 245 bytes --]

Ricardo Wurmus <rekado@elephly.net> writes:

> We also have a dedicated page for easy issues:
>
>     https://issues.guix.gnu.org/easy

Nice!  Maybe this should be linked on the front page.

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Brainstorming features for issues.guix.gnu.org

[John Soo]

Hi Ricardo!

I love the idea of a smoother download/review process. I think I would
be happier with a curl-able endpoint to download patches from. I think
it might compose with other tools a little more smoothly. Other than
that, nothing really comes to my mind.

I only just started using it more frequently since it stopped timing out
so frequently.

Kindly,

John

Re: Brainstorming features for issues.guix.gnu.org

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 2865 bytes --]


Ricardo Wurmus <rekado@elephly.net> writes:

> I want issues.guix.gnu.org to become more useful for all of us.  It’s
> easy to get lost in a deluge of bug reports and patch submissions, so
> our tools should allow us to stay afloat.
>
> Do you use issues.guix.gnu.org?  If you aren’t: what workflow do you
> have to review patch submissions?

Normally when I look at reviewing patches, I end up finding something
else to try and automate or make easier.

My current workflow is, look for patches to review through email, or
Patchwork [1], look the patches over, follow the link to the Guix Data
Service instance, and maybe try building some of the derivations [2]. If
I want to manipulate the patches locally, I checkout the branch or
cherry-pick the relevant commits [3].

1: https://patchwork.cbaines.net/project/guix-patches/list/
2: I use the substitutes from the Guix Data Service instance for the
derivation, so I can build it locally without having to apply the
patches.
3: https://git.cbaines.net/guix/patches

> If you do use it: what features do you think are missing?

Being able to go to domain/patch-number would be useful ([4] for
example). Debbugs does a redirect, so I usually end up typing that out
instead.

4: http://issues.guix.info/39258

> Personally, I’d wish for a more streamlined workflow to download and
> apply patch sets.  I don’t want to click on each “download” link in the
> web interface.  Instead I would like to run something like
>
>     ./etc/review 12345
>
> which would fetch the patches in issue 12345 and apply them to my
> git worktree.

I use the combination of Patchwork plus some scripts run through Laminar
to populate a Git repository with commits for the patches for this. I've
got the git repository as a remote, which makes applying the patches
reasonably easy.

> I would also like to see neglected issues in the web interface, i.e. a
> list of open issues that haven’t seen any response in a while and that
> haven’t been tagged as awaiting more information from the submitter.
> This should make it easier for us to prevent patches from slipping into
> obscurity, which is a terrible thing to happen especially for new
> contributors.

Those are definitely features I'd like to see. They would be very useful
to help people prioritise.

While most of the discussion here has been about patches, I can think of
a few useful things in terms of issues that don't directly relate to
patches (or at least not yet).

For bug reports, it could be useful to be able to associate them with
packages that the bug is for. This could allow you to filter for bugs
related to a package. It could also be useful to be able to mark which
commit introduced an issue, and when it was resolved.

Thanks for your work on issues.guix.info!

Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 962 bytes --]

Re: Brainstorming features for issues.guix.gnu.org

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 760 bytes --]

Hi Chris!

Christopher Baines <mail@cbaines.net> writes:

> My current workflow is, look for patches to review through email, or
> Patchwork [1], look the patches over, follow the link to the Guix Data
> Service instance,

Which link?

> and maybe try building some of the derivations [2]. If
> I want to manipulate the patches locally, I checkout the branch or
> cherry-pick the relevant commits [3].
>
> 1: https://patchwork.cbaines.net/project/guix-patches/list/
> 2: I use the substitutes from the Guix Data Service instance for the
> derivation, so I can build it locally without having to apply the
> patches.

Is there a public substitute server from the Guix Data Service?

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Brainstorming features for issues.guix.gnu.org

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 1885 bytes --]


Pierre Neidhardt <mail@ambrevar.xyz> writes:

> Hi Chris!
>
> Christopher Baines <mail@cbaines.net> writes:
>
>> My current workflow is, look for patches to review through email, or
>> Patchwork [1], look the patches over, follow the link to the Guix Data
>> Service instance,
>
> Which link?

If you go to a patch, like: https://patchwork.cbaines.net/patch/20613/
there are some links in the Checks section. The "View comparison" link
takes you to a Guix Data Service instance, the "View Git branch" link
takes you go a Git repository containing the patches, and the "View
Laminar job" link takes you to the job in Laminar that tried to apply
the patches.

>> and maybe try building some of the derivations [2]. If
>> I want to manipulate the patches locally, I checkout the branch or
>> cherry-pick the relevant commits [3].
>>
>> 1: https://patchwork.cbaines.net/project/guix-patches/list/
>> 2: I use the substitutes from the Guix Data Service instance for the
>> derivation, so I can build it locally without having to apply the
>> patches.
>
> Is there a public substitute server from the Guix Data Service?

I realise that it's not easy enough to find this out, but the Guix Data
Service provides substitutes for the derivations it knows about. It
stores all the information about derivations, and it also stores the
sources referenced by the derivations.

This means it can provide substitutes for these store items. Take mxnet,
if you trust the key (which can be found here
https://guix-patches-data.cbaines.net/substitutes ), then you'll be able
to do:

  guix build --substitute-urls="https://guix-patches-data.cbaines.net" /gnu/store/9xcmc4z6w0brg17l1frz6blg79wgf7yi-mxnet-1.6.0.drv

As I understand it, Guix will download the derivation graph from the
Guix Data Service until it has the derivation locally, then it will
build it as normal.

Hope that makes sense?

Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 962 bytes --]

Re: Brainstorming features for issues.guix.gnu.org

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 113 bytes --]

Fantastic, thanks for the details!
This is all very useful! :)

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Brainstorming features for issues.guix.gnu.org

[pinoaffe]

Hi!

On 2020-03-26 08:49, Ricardo Wurmus wrote:
> What do you think?

This interface looks great, but I don't quite understand what it lists,
since it doesn't seem to list all patches submitted to 
guix-patches@gnu.org.
What is the criterion applied here?
Might it be useful to reconsider said criterion?

pinoaffe

Re: Brainstorming features for issues.guix.gnu.org

[Ricardo Wurmus]

pinoaffe@airmail.cc writes:

> This interface looks great, but I don't quite understand what it lists,
> since it doesn't seem to list all patches submitted to
> guix-patches@gnu.org.

It really should list all patches submitted to guix-patches@gnu.org and
all bugs sent to bug-guix@gnu.org.

We’re getting a list of bugs and patches from Debbugs, so if something
is missing please give me an example so I can try to figure out why it’s
not showing up (and if Debbugs does the right thing).

-- 
Ricardo

Re: Brainstorming features for issues.guix.gnu.org

[Vincent Legoll]

On Fri, Mar 27, 2020 at 10:43 AM Ricardo Wurmus <rekado@elephly.net> wrote:
> It really should list all patches submitted to guix-patches@gnu.org and
> all bugs sent to bug-guix@gnu.org.
>
> We’re getting a list of bugs and patches from Debbugs, so if something
> is missing please give me an example so I can try to figure out why it’s
> not showing up (and if Debbugs does the right thing).

I have a hard time getting 40246 shown with any search queries,
except asking directly with the bug number.

-- 
Vincent Legoll

Re: Brainstorming features for issues.guix.gnu.org

[Ricardo Wurmus]

Vincent Legoll <vincent.legoll@gmail.com> writes:

> On Fri, Mar 27, 2020 at 10:43 AM Ricardo Wurmus <rekado@elephly.net> wrote:
>> It really should list all patches submitted to guix-patches@gnu.org and
>> all bugs sent to bug-guix@gnu.org.
>>
>> We’re getting a list of bugs and patches from Debbugs, so if something
>> is missing please give me an example so I can try to figure out why it’s
>> not showing up (and if Debbugs does the right thing).
>
> I have a hard time getting 40246 shown with any search queries,
> except asking directly with the bug number.

Looks like it merely got delayed:

    https://issues.guix.gnu.org/search?query=cramfs

I don’t know why.

-- 
Ricardo

Re: Brainstorming features for issues.guix.gnu.org

[Vincent Legoll]

On Fri, Mar 27, 2020 at 3:19 PM Ricardo Wurmus <rekado@elephly.net> wrote:
> Looks like it merely got delayed:
>
>     https://issues.guix.gnu.org/search?query=cramfs

OK, I tried this exact query and got no result, yet now
it is here.

It's not the first time I see that, (almost?) every time I
submit a new patch, it takes a long time to appear in
issues, to the point that I was thinking it only appeared
after someone replied to it (i.e. when it was being closed,
for most of them...)

But for this one I replied to myself pretty early, and despite
seeing my replies in debbugs.gnu.org, there was still nothing
shown on issues.guix.gnu.org, so it looks like a time thing...

-- 
Vincent Legoll

Re: Brainstorming features for issues.guix.gnu.org

[pinoaffe]

On 2020-03-27 09:42, Ricardo Wurmus wrote:
> It really should list all patches submitted to guix-patches@gnu.org and
> all bugs sent to bug-guix@gnu.org.

For example patch 40182 : doesn't show up when looking for "icestorm" or 
"pinoaffe",
but does show up when I enter the number.
Same goes for 40165 and 40167 (strangely, 40166 does show up for 
relevant search terms).

Re: Brainstorming features for issues.guix.gnu.org

[Vincent Legoll]

Searching with "mdate:2w..now" does show a single issue,
is that really so ?

I expect this to mean all issues with a new comment in
the last 2 weeks.

-- 
Vincent Legoll

Re: Brainstorming features for issues.guix.gnu.org

[Vincent Legoll]

Another feature idea...

I often use it to educate myself on what's going
on and read status about various things.

When doing so I do not always want to scroll
through kilometers of patches.

A way to collapse / hide all/too big patches on
an issue page would be great, to enhance
readability

-- 
Vincent Legoll

Re: Brainstorming features for issues.guix.gnu.org

[Ricardo Wurmus]

Vincent Legoll <vincent.legoll@gmail.com> writes:

> Searching with "mdate:2w..now" does show a single issue,
> is that really so ?
>
> I expect this to mean all issues with a new comment in
> the last 2 weeks.

I just looked at the services and noticed that the mumi-worker service
was dead.  That worker is responsible for regularly fetching new mails
from Debbugs and to index them.

I’ll see if I can make it more robust.  This should fix all these
problems of not being able to find recent messages.

Sorry about that.

--
Ricardo

Re: Brainstorming features for issues.guix.gnu.org

[Ricardo Wurmus]

Vincent Legoll <vincent.legoll@gmail.com> writes:

> Searching with "mdate:2w..now" does show a single issue,
> is that really so ?

mdate actually no longer exists.  It was used when we queried the
debbugs service directly.  Now that we only query a local database we
only have “date”.  I’ll update the help.

-- 
Ricardo

Re: Brainstorming features for issues.guix.gnu.org

[Vincent Legoll]

On Mon, Mar 30, 2020 at 1:07 PM Ricardo Wurmus <rekado@elephly.net> wrote:
> mdate actually no longer exists.  It was used when we queried the
> debbugs service directly.  Now that we only query a local database we
> only have “date”.  I’ll update the help.

Thanks for the update, and many thanks for working on this. The site
is already useful, and will be even more in the future. I hope you are
not swamped under the avalanche of suggestions. ;-)

-- 
Vincent Legoll

Re: Brainstorming features for issues.guix.gnu.org

[Björn Höfling]

[-- Attachment #1: Type: text/plain, Size: 3702 bytes --]

Hi Ricardo,

On Thu, 26 Mar 2020 09:49:12 +0100
Ricardo Wurmus <rekado@elephly.net> wrote:

> Hello Guix!
> 
> I want issues.guix.gnu.org to become more useful for all of us.  It’s
> easy to get lost in a deluge of bug reports and patch submissions, so
> our tools should allow us to stay afloat.
> 
> Do you use issues.guix.gnu.org?  If you aren’t: what workflow do you
> have to review patch submissions?

I prefer my mailbox, with sometimes looking through the Debbugs web
page. I have to admit, I'm not using it and I think it is not
intuitive. It is as colorful as the bug trackers at github.com, but not
as useable as them.

Here are my suggestions for mumi, some of them already said by others:

* 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 would prefer two trackers: 
https://issues.guix.gnu.org/ for bugs and
httsp://patches.guix.gnu.org/ for 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/?

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

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

* I would expect the home page to present the newest issues first, and
only open ones.

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

* Sorting issues by columns would be cool.

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

* That means: If I search only for open issues, I get one page ranging
from 2013 until 2017, nothing newer:
https://issues.guix.gnu.org/search?query=is%3Aopen
This is unsatisfying.

* In that list, it is not clear what a red/orange colored bug-number
means: A tool-tip would be nice.

* As others mentioned, linking and explaining the tags (like easy)
is missing.

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

* I still don't see that all bugs and patches from the mailing list are
part of the mumi issues list?

* The HTML could be responsive.

* The query syntax examples are only on the home page. Please repeat
them also on the help page.

* 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

With numbers, it gets even more strange:
https://issues.guix.gnu.org/search?query=date%3A2020-03-29..2020-03-30
--> Nothing found.

Some more, but why are these selected?:
https://issues.guix.gnu.org/search?query=date%3A2020-03-29..2020-03-30

* Mdate does not find anything?
https://issues.guix.gnu.org/search?query=mdate%3A2w..12h

Despite all the critics, thanks for caring and improving mumi.

Björn

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Brainstorming features for issues.guix.gnu.org

[Ricardo Wurmus]

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.

Re: Brainstorming features for issues.guix.gnu.org

[Björn Höfling]

[-- Attachment #1: Type: text/plain, Size: 6288 bytes --]

On Wed, 01 Apr 2020 04:05:13 +0200
Ricardo Wurmus <rekado@elephly.net> wrote:

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

OK. I understand.

What about adding a syntax like "source:bugs", "source:patches"? I
would like to have something like this in order to compare my emails
with Mumi (at least to easier show you that there is again something
missing :-))

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

OK. I looked into the nginx config in the maintenance repository. I was
surprised how complex this already is.

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

Looks much better now, thanks :-)

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

Very nice :-)

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

Wow.

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

OK, I understand that limitations.

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

Good.

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

Is it broken again? I don't see any messages from April.
 
> > * The HTML could be responsive.  
> 
> It should be responsive with recent changes.

You are right. I meant it could be "more" responsive: When I use the
site with my mobile phone, I have to scroll horizontally to see the
"Done" column.

One idea would be to not use a <table> but <div class="container"> and
make use of the bootstrap 12-cells grid layout. In that way, some
columns could be removed and/or shown in smaller versions in the mobile
version. Also we don't need to stick to exactly one line but could wrap
it in the mobile version.

I wanted to try that out, but failed to set up mumi. I will write about
that in its own message.

Maybe it would also help to have the date formated in ISO-format?
 
> > * 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?

Definitions: Directly under the search input field are the "Hints".
From there, you can open the "Help" page.

The "Help" page contains the full syntax definitions. But it contains
less examples than the "hints" :-)

In the "hints", I directly find and can copy the example "date:2d..now"
or "date:2018-04-01..2018-04-02". On the help page, the full syntax is
explained, but these examples are no longer there to copy. I have to go
back to the hints.
 
[..]

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

That would be a good idea. I thought that "date" is the submit-date
whereas "mdate" would be the date of the last post (and not any
technical synchronization thing).

There are two things wrong with the dates that could have the same
cause: The order doesn't match and there are issues with no post at
all within the specified date range:

http://issues.guix.gnu.org/search?query=date%3A2020-03-30..2020-03-31

If I order that by "date submitted", I see that the order is broken many
times.

For example this issue is from 2018 but is ordered somewhere in the
middle:

http://issues.guix.gnu.org/issue/33507

Next thing: The following issue has its last post from 2020-03-20 and
thus should not be within the search range:

http://issues.guix.gnu.org/issue/37266

Only when you switch to Debbugs you see an obscure control message "Did
not alter fixed versions and reopened" which was from 2020-03-30:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=37266

This message is neither understandable nor shows it up in MuMi. Either
the message does not show up in Mumi (which I would prefer) or the
technical messages should also show up in MuMi such that for the user
it is clear why this issue is part of the search result.

> Thanks again!

Thanks to you for the improvements!

Björn

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Brainstorming features for issues.guix.gnu.org

[Ricardo Wurmus]

John Soo <jsoo1@asu.edu> writes:

> It can be hard to review a patchset with multiple revisions
> (particularly when sent as attachments).

I agree.

> It is hard to find how patchsets differ - let alone where
> revisions start and end.

Do you have an idea how to improve this?  Should we use, for example,
the message subject to detect revisions?  (E.g. [PATCH 3/3] will
indicate that the end of the patch set has been reached.)

How would we indicate different patch sets visually?  Should there be
links somewhere to jump to patch sets?

--
Ricardo

Re: Brainstorming features for issues.guix.gnu.org

[John Soo]

Ricardo Wurmus <rekado@elephly.net> writes:

>> It is hard to find how patchsets differ - let alone where
>> revisions start and end.
>
> Do you have an idea how to improve this?  Should we use, for example,
> the message subject to detect revisions?  (E.g. [PATCH 3/3] will
> indicate that the end of the patch set has been reached.)
>
> How would we indicate different patch sets visually?  Should there be
> links somewhere to jump to patch sets?

Hmm. I don't know if I have a good answer yet. I think I like the
debbugs threaded view. Here are a couple ideas:

* Allow expansion/collapse of diffs
* Provide a thread view and a view of just one patchset (maybe computed
  via [PATCH 3/3] or by attachments as you mention)
* Provide an interdiff view between revisions
* Only show the most recent patchset like some large commercial products

I like the thread view idea since this is an email workflow, afterall.

It has been improving a lot and I am already using it a lot more now that
it has its own database.

John