Hello, Detlef Steuer <ste...@hsu-hh.de> writes:
> That leads to the next point: If Nicolas decided *he* would love to work > with a bugtracker, I would not complain and open an account. > As it is now, anything that's not in the best interest of our benevolent > developer, should not even be considered :-) Thank you for your consideration. However, the question of what bug tracker to use is the maintainer's, not mine. Besides, just to avoid the confusion, I'm not a diva ;) If it is obvious that a solution is good for the project, I wouldn't dare opposing it. Now, I think I should add a few data points: - Many bug reports, and patches, are "lost" currently. Of course, they are still there, if you dig deep enough in the ML archives. But I doubt anyone would do that, so it is more realistic to consider them lost. - As pointed out, Org has a bug tracker : Emacs' Debbugs. See <https://debbugs.gnu.org/Emacs.html>. Org users do not send bugs through it much. It is possibly a cultural thing. In these "package.el" days, people may forget that Org is also bundled with Emacs. The manual is not clear about it, too. In particular, this bug tracker can be used for any Org version, not necessarily the one bundled with Emacs. The good thing is that every bug sent there is also sent to our ML. Now, after the facts, some personal rambling about it: - I have no opinion on the fact that a bug tracker would bring more life to the project. It may be, but it is not obvious either. I'm not against it anyway. - The mailing list is the central place in our project, and any discussion should all happen here, so that anyone can get involved. In particular, a "mini mailing-list" per bug number is not a good thing, if messages are not made public in the ML. - A bug tracker without first-class support for Emacs—i.e., you can do anything from Emacs—is missing the point. Therefore, I agree that an email-based bug tracker is particularly suited. - Debbugs has a nice, modern, front end, too: Mumi (<https://git.elephly.net/gitweb.cgi?p=software/mumi.git>). See for example <http://issues.guix.gnu.org/>. - No matter what bug tracker (or lack thereof) is used, Org needs more reviewers, i.e., more users with write access to the repository. Receiving a ton of bug fixes is a certainly great, but is also discouraging when you realize you cannot possibly deal with all of them. - Considering the previous point, I doubt switching to a bug tracker today would help handling more bug reports. It will induce more work, though. For example, some triage happens currently on the ML: if a so-called bug report is clearly a misunderstanding, someone here often helps the OP without the developers interfering. This never happens in the bug tracker Org has actually. So, in a nutshell, if Bastien, or a future maintainer, decides that Org project should seriously be using a bug tracker, I suggest to simply advertise the current one, and add a Mumi interface somewhere. As the final words, reviewers are welcome, too… Regards, -- Nicolas Goaziou
