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

[Bastien]

Óscar Fuentes <address@hidden> writes:

> Óscar Fuentes <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.

  (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