[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Orgmode] Re: Org-mode as a bug tracker.

From: Óscar Fuentes
Subject: [Orgmode] Re: Org-mode as a bug tracker.
Date: Sun, 19 Jul 2009 23:12:58 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux)

Bastien <address@hidden> 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.

Using org-mode instead of outline-mode is a no-brainer. The only
incovenient is org's complexity. A basic but effective use of org is
straightforward but its extensive documentation may seem daunting for
the occasional user. Maybe a paragraph or two at the beginning of the
file explaining what's required for adding entries and doing simple
queries would help those developers who don't know nor plan to use org
for other uses.

>   (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.   

IMAO this setup is more complex and fragile than a conventional bug
tracker. The idea may seem appealing at first for a group of veteran
emacs users (those who insist on managing the bug database via e-mail
because they refuse to use a web browser, for instance) but I'm far from
convinced about its effectiveness.

>> 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.

I'm afraid you are. Lots of emacs bug reports comprises hundreds of
lines of stack dumps, plus e-mail discussions with lots of quoted text,
etc. Org is great for notes, but is it practical for containing tens of
thousands of bug reports, some of them made of thousands of lines? And
you don't control what's on a bug report, they usually contain all sorts
of text constructs and random characters. How well it would deal with
bug reports about org's itself, containing excerpts from other org
files?  Wouldn't this confuse org?

>> 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.

Nope, the 20MB is the bugs' text alone. But attached files belong to the
tickets and supposedly provide key information, so you can wipe them
away to a place where they are not distributed along with the bug

I think org as a bug tracker may work very well for individual
developers or for small groups, but not for open big projects such as


reply via email to

[Prev in Thread] Current Thread [Next in Thread]