From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bastien Subject: Re: Re: Org-mode as a bug tracker. Date: Sat, 18 Jul 2009 12:46:35 +0200 Message-ID: <87zlb28e0k.fsf@bzg.ath.cx> References: <87ocrj728a.fsf@telefonica.net> <87fxcv6zvc.fsf@telefonica.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MS7RF-0007zh-Ij for emacs-orgmode@gnu.org; Sat, 18 Jul 2009 06:46:45 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MS7RC-0007yW-S6 for emacs-orgmode@gnu.org; Sat, 18 Jul 2009 06:46:45 -0400 Received: from [199.232.76.173] (port=42199 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MS7RC-0007yG-4p for emacs-orgmode@gnu.org; Sat, 18 Jul 2009 06:46:42 -0400 Received: from mail-px0-f193.google.com ([209.85.216.193]:57620) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MS7RB-0003Me-Gz for emacs-orgmode@gnu.org; Sat, 18 Jul 2009 06:46:41 -0400 Received: by mail-px0-f193.google.com with SMTP id 31so951380pxi.14 for ; Sat, 18 Jul 2009 03:46:41 -0700 (PDT) In-Reply-To: <87fxcv6zvc.fsf@telefonica.net> (=?iso-8859-1?Q?=22=D3scar?= Fuentes"'s message of "Fri, 17 Jul 2009 18:25:11 +0200") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: =?iso-8859-1?Q?=D3scar?= Fuentes Cc: emacs-orgmode@gnu.org Óscar Fuentes writes: > Óscar Fuentes writes: > >> Any reasons why this is not a good idea? > > Just remembered that time ago, when the bug tracker for Emacs was > discussed, Bastien proposed to use org-mode for it. Actually I'm glad you bring this up again, as I want to work on this proposal again. There are actually two ideas: (1) use org-mode instead of outline-mode in Emacs internal files etc/TODO and admin/FOR-RELEASE. This is pretty straightforward and not a big change. As a minimal change, it improves the way we can navigate through these files, but it opens new possibilities about adding milestones, tagging tasks, keep track of the email which originated the task, assign them to someone, etc. (2) use org-mode as a collective bug tracker. Let me dwell a bit on the second idea. A good bug tracker for Emacs would let both users and developers easily access (read/write) to a constantly updated bugs database. One way to do this with Org files is the "Worg" way: share Org files over git (or bzr) and let's people contribute to it. However, this is not a good solution for *users*. Even for developers it's not usable: people will have to pull the last version of the bug database to check that they are not working on the same things... too bad. Another solution would be to take the Worg road only for publishing the Org bug database, and take another road for writing stuff into it. I think a clever system combining HTML input and mail interactions could do it: - A HTML form would let users fill a bug report that would be add to the Org bug database; - M-x report-emacs-bug would be sent to a machine able to extract an Org subtree from the email and add it to the Org bug database; - When a developer is taking any action on a bug (revising, closing, etc) he emails the updated version of the task to the system and the system takes care of replace the old entry by the new one. - Whenever X changes an entry assigned to Y, Y receives an email asking for permission about this changes. If yes, then the change is applied to the bug database, if no it isn't. This is the basic workflow. Of course, permissions and other issues could be refined but I think such a system is feasible. > I argued against > because the Emacs bug database would soon fill dozens of megabytes and > this volume does not fit the philosophy of a text-based database. I don't think the size of the database would really be an issue for the system above - but maybe I'm wrong on this. > Another nuisance is attached files. This requires an ad-hoc mechanism > and I'm not sure I want them stored along with the source files. I guess 20MB is because there are many files attached - as Matt mentioned you can attach files *outside* the bug database so this isn't really an issue. Looking forward reading your ideas on the proposed setup above! Thanks, -- Bastien