Hi, I would like to discuss more the issue of choosing a bug tracker for sup.
(I've made a new thread for clarity) (This is a cross post of a post[1] on my blog) OK lets forget Ditz[2] as an option. Note also that I would make no objection to using a traditional bug tracker. It seems that we do not find a tool we really like. A simple question I asked me was: "Do we really need to invent this (big) tool?" And more and more the answer I see is that we do not need yet another big tool. Especially for a bug tracker we need recipes, protocols more than a nice interface. And generally I think we better need thinking on how to split the problem in small issues than writing the tool that tackles all of them in one go. Again the UNIX philosophy can help us to simplify all this mess! So we need a web interface for non technical users, great. What about a pre-formatted email explained on a single web-page for reporting bugs. This simple web-page will also have a form to fill which will send the email for them. This micro web app is really simple and does a very clear job. So we now have issues as emails. Thus the mailing-list is our bug tracker as before. However issues are now in a proper format. A bot will receive emails on the mailing-list and process those which are in the right format. I think that the bot will not have a lot of information to store: (correct me if you find something else) * Issue type, severity, priority, category, person assigned, progress status, incriminated version and platform, planned milestone/released. * Issue details, discussion, answers, attachments. All those of the first category can be easily handled in a very flexible way either with labels, or a simple mapping: Labels (like the Google bug tracker on code.google.com): Type-Defect Priority-Critical Component-UI Mapping: type: defect priority: critical component: UI This is very flexible because this set of labels/attributes is chosen by the project maintainer to match the complexity of the project. I would store and manage the first category using a simple YAML file. The bot acknowledges its updates by simply answering to the discussion. Those of the second category can be managed using a single email discussion. Since the discussion is central to the issue, tracking the original message-ID could be used as the unique identifier. About the issues identifier I see two options, either we try to allocate simple integers like most of the trackers or we just keep the unique (long) identifier. Then, optionally a simple set of HTML pages can be generated using the YAML file. About storage of the YAML file I would simply store it in the repository. If we make the bot accessible, we just have to periodically pull from it. I don't know yet how many issues I've forgotten, and if this design is really as simple and lightweight as I claim it to be. I look forward to your answers on that. Best regards, [1]: http://blog.nicolaspouillard.fr/entries/2009-11-01-bug-tracker-design-issues.html [2]: http://ditz.rubyforge.org/ -- Nicolas Pouillard http://nicolaspouillard.fr _______________________________________________ sup-talk mailing list sup-talk@rubyforge.org http://rubyforge.org/mailman/listinfo/sup-talk