Nils Gillmann <niaster...@grrlz.net> writes: > First follow up idea: > > Ideal case would be: > - integration with Guix in the future (the emacs interface and > other potential future interfaces) > - integration into Guix website > - patches can be marked: > - state (done/open) > - priority > - patches can be assigned to more than 1 person > - webinterface > > As we are not at the ideal case and need a software until we get > there, most projects seem to either use mailman, bugzilla, > something equal to prmon.freebsd.org (ports monitor), simple pull > requests on a mirror on a bigger source control system.
I have a very strong aversion to bugzilla and other complicated tracking systems. All of the above points are covered by debbugs, which we already use for bug tracking. debbugs has an Emacs interface as well as a read-only web interface. I must admit that I’m not using debbugs regularly for our bug tracker because I’m not working on bugs very often. If we really wanted to track progress on patches we could be using debbugs, but I don’t actually think it would improve the situation much. Right now I’m capturing guix-devel emails that I want to look at later with Org capture, or I simply leave them in an unread state. The problem, in my opinion, is not so much keeping track of patches, but taking the time to review and engage in discussions. I cannot review as much as I would like to and for follow up discussions I often miss time (in front of the computer, and in a reasonably awake state). I don’t think it’s a software problem, but a people problem. To deal with more patches we need more people reviewing patches. We already have “guix lint” to point out common problems. We probably should add a little helper script for all non-Emacsers that runs Emacs over the expression to check the indentation. But other than that I’d just say: resend a patch if you haven’t received any response within five days or so. ~~ Ricardo
