From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by 10.90.117.16 with SMTP id p16cs447222agc; Mon, 2 Nov 2009 00:52:37 -0800 (PST) Received: by 10.224.32.7 with SMTP id a7mr2709249qad.308.1257151956527; Mon, 02 Nov 2009 00:52:36 -0800 (PST) Return-Path: Received: from rubyforge.org (rubyforge.org [205.234.109.19]) by mx.google.com with ESMTP id 27si6920716qyk.21.2009.11.02.00.52.36; Mon, 02 Nov 2009 00:52:36 -0800 (PST) Received-SPF: pass (google.com: domain of sup-talk-bounces@rubyforge.org designates 205.234.109.19 as permitted sender) client-ip=205.234.109.19; Authentication-Results: mx.google.com; spf=pass (google.com: domain of sup-talk-bounces@rubyforge.org designates 205.234.109.19 as permitted sender) smtp.mail=sup-talk-bounces@rubyforge.org Received: from rubyforge.org (rubyforge.org [127.0.0.1]) by rubyforge.org (Postfix) with ESMTP id 2D7293C8067; Mon, 2 Nov 2009 03:52:36 -0500 (EST) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by rubyforge.org (Postfix) with ESMTP id 2E4551858289 for ; Mon, 2 Nov 2009 03:46:35 -0500 (EST) X-IronPort-AV: E=Sophos;i="4.44,665,1249250400"; d="scan'208";a="39342198" Received: from peray.inria.fr (HELO localhost) ([128.93.8.98]) by mail1-relais-roc.national.inria.fr with ESMTP; 02 Nov 2009 09:46:34 +0100 From: Nicolas Pouillard To: Tero Tilus In-reply-to: <1257143690-sup-7839@tilus.net> References: <1257111816-sup-4397@peray> <1257143690-sup-7839@tilus.net> Date: Mon, 02 Nov 2009 09:46:34 +0100 Message-Id: <1257150627-sup-1843@peray> User-Agent: Sup/git Cc: sup-talk Subject: Re: [sup-talk] Choosing a bug tracker for Sup X-BeenThere: sup-talk@rubyforge.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: User & developer discussion of Sup List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sup-talk-bounces@rubyforge.org Errors-To: sup-talk-bounces@rubyforge.org Excerpts from Tero Tilus's message of Mon Nov 02 08:01:31 +0100 2009: > Requirements collected: > - Store/track > - Formal attributes: Issue type, severity, priority, category, > person assigned, progress status, incriminated version and > platform, planned milestone/released > - Informal meta: Issue details, discussion, answers, attachments > - Web-interface (at least for issue submission, searching and displaying) > - Issue submission, commenting, attachments and editing attributes by email > - Notifications by email Nice summary. > Nicolas Pouillard, 2009-11-01 23:52: > > OK lets forget Ditz[2] as an option. > > Why? (not that i have any reason why not, i've never used diz) At least temporarily, I think it also fails at staying simple. And while it is fun to hack that's fine but then it becomes burden and code to maintain. > > 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. > > Looks like this is a issue you have discussed in depth before. Any > pointers to list archives? Not really publicly, and I'm open to seeing tools I don't know. > > A simple question I asked me was: > > "Do we really need to invent this (big) tool?" > > Well... if somebody invented it for us already. :) Yes but a big tool imply development, extensions, upgrades... > > Especially for a bug tracker we need recipes, protocols more than a > > nice interface. > > Now we are talking! ...and when trying to choose a tool, we need to > think about what we need it to do for us. I would say that we need a collection of small and clear tools. > I tried to pick the requirements you used. > > > So we need a web interface for non technical users, great. > > OK, this seems reasonable requirement. > > > What about a pre-formatted email explained on a single web-page for > > reporting bugs. > ... > > A bot will receive emails on the mailing-list and process those > > which are in the right format. > > Requirement: Bug submission by email? > I'd say we need that. Yes some people tend to really dislike web UIs, and while it is not my case I prefer to keep a "by email" option anyway. > > 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. > > This is pretty traditional. I'd still want to challenge a bit. Why > do we need severity and priority? What would they be used for? I don't say that we need all of those, that the flexibility point. The configuration will be something like: attributes: type: [defect, enhancement, task] severity: [critical, ...] priority: [high, low, ...] category: [UI, index, ...] assigned to: [someone, someoneelse, ...] progress status: [waiting, open, started, closed] ... This can be tweaked as needed, if we need one more 'type' we add it, if we do not need severity we remove it. > > I would store and manage the first category using a simple YAML > > file. The bot acknowledges its updates by simply answering to the > > discussion. > > Requirement: Email notifications to ticket "subscribers"? > That's reasonable. I would say that the mailing-list is the only subscriber, people choose to follow the discussion or not with their email-client. This only miss the "vote for this issue" feature, which we can avoid in the mean time and delegate to a polling tool afterward. > > Those of the second category can be managed using a single email > > discussion. > > Requirement: Issue comments/attachments and status changes by email? Right. > > I don't know yet how many issues I've forgotten > > I can't figure out anything really necessary you would have missed. I got some more input via other channels about the need of an UI to search, triage, sort issues. I would say that all of this can easily be done by playing with the YAML file. The only tool I see would be one to fetch the email discussion given a Message-ID, but this is a matter of another separated tool. Thanks for your input! -- Nicolas Pouillard http://nicolaspouillard.fr _______________________________________________ sup-talk mailing list sup-talk@rubyforge.org http://rubyforge.org/mailman/listinfo/sup-talk