Hi Arun,
Thiago’s idea to allow people to subscribe to certain *kinds*
of
issues when they are reported is also good.
I agree this is a great idea. Recently, I unsubscribed from
guix-patches. It's just too high volume. These days, I prefer to
just
search for issues using emacs-debbugs and mumi.
Here's another idea for mumi: mumi should have a JSON
API. Debbugs' SOAP
API is quite terrible, and doesn't even expose such things as
the number
of emails in an issue. Mumi can offer its own API which does
these
things properly. That way, we can write new clients (say, a CLI
client)
for mumi, that can filter more intelligently. If we had a good
CLI
client, our contributors wouldn't have to set up an email client
or
emacs just to participate.
These are all excellent ideas, and seeing you articulate them
makes me happy, because in my experience there’s always good code
around the corner whenever you have good ideas :)
The way I see it, we are outgrowing general purpose bug trackers
like
debbugs. We need a special purpose bug tracker specifically for
Guix
with its special requirements. We are a big enough community for
this to
be important.
I might be able to find some time to implement a simple JSON API
for
mumi. Would there be interest in such a contribution?
Absolutely, yes, please!
Regarding, hacking on mumi, I understand that
issues.guix.gnu.org is on
an IP whitelist with the GNU debbugs server. How do I hack on
mumi if
simply running it on my local machine, and pulling data from GNU
debbugs
would alarm the debbugs admins?
That’s correct, but mumi itself doesn’t directly talk to debbugs
any longer. We just periodically sync all debbugs data from the
GNU debbugs server and have mumi work on these files locally. So
to hack on mumi I’d suggest downloading a copy of the raw debbugs
data from issues.guix.gnu.org. I could put an archive somewhere
where you can fetch it.
--
Ricardo
