Hi! Arun Isaac <arunis...@systemreboot.net> skribis:
>> 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. > > 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? Definitely, but I think the JSON API is a means, not an end, so what matters is what we’ll build with it. Example that comes to mind: debbugs.el could use it for features Debbugs lacks; we could have a client Scheme module and a command-line tool to perform certain query, with the goal of being able to do things like: guix review apply 1234 guix review search bioinformatics … That could be a game-changer. Of course we should start small and focus on specific features such as searching, listing, and retrieving. > 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? Ricardo may know the answer. :-) Thanks, Ludo’.
