Subject: Re: [sup-talk] Choosing a bug tracker for Sup

From: Tero Tilus <[email-masked]>
Date: Mon, 02 Nov 2009 11:50:07 +0200

Nicolas Pouillard, 2009-11-02 10:46:
> Excerpts from Tero Tilus's message of Mon Nov 02 08:01:31 +0100 2009:
>>>   "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...

Unless you take service, not the bare tool.  We are already using
gitorius and rubyforge (at least to some extent).  I'd go for a issue
tracking service that suits our needs.

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

Thats exactly why there were quotes around the word subscribers.  ;)

What I was thinking was that you could be a first class citized no
matter the client.  You could choose to comment and follow the
discussion on issues using your mua or web interface.  Kinda like what
Alue[1] does for discussions in general.

[1] http://antti-juhani.kaijanaho.fi/newblog/archives/572

-- 
Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
_______________________________________________
sup-talk mailing list
[email-masked]
http://rubyforge.org/mailman/listinfo/sup-talk

---

From: Mike Kelly <[email-masked]>
Date: Tue, 03 Nov 2009 10:34:24 -0500

On Tue, 03 Nov 2009 07:16:15 -0800, William Morgan
<[email-masked]> wrote:
> Reformatted excerpts from Mike Kelly's message of 2009-11-03:
>> As much as I hate to suggest it... RT should have all of these
>> qualities.
> 
> Rrrrrrrrreally. Is it a pain to set up? Why do you hate to suggest it?
> (I've heard people complain about it before, but I don't remember any of
> the details.)

Yes, somewhat, IIRC. But, I haven't really ever had to set it up. It's one
of those things which requires half of CPAN to work. So, it was annoying
when I made an attempt to package it for a distro, but if you're just
installing it following their directions, it's probably not that bad.

But, someone is able to get away with charging $3250 a month for a
"platinum" managed install of it. (Then again, some enterprises will pay
anything for hosting...)

Let me try a test install real quick, and I'll get back to you.

-- 
Mike Kelly

---

From: Reid Thompson <[email-masked]>
Date: Tue, 3 Nov 2009 11:49:53 -0500

> Let me try a test install real quick, and I'll get back to you.

I just started looking at it, so not sure if it fits all needs but
fossil has a built in bugtracker

http://www.fossil-scm.org/index.html/doc/tip/www/index.wiki

---

From: Michael Stapelberg <[email-masked]>
Date: Wed, 04 Nov 2009 10:38:20 +0100

Hi,

Excerpts from Mike Kelly's message of Mi Nov 04 01:07:24 +0100 2009:
> Also, I've used trac for years for another project, and I wouldn't
> recommend it. (It's been a memory hog, among other things).
I’ve also used trac for quite some time now and I don’t recommend it
either. As soon as the spammers find your website, problems start. trac
has no built-in possibility to delete a comment/ticket, nor do any of
the anti-spam plugins work as they should (either they don’t recognize
spam, they have false-positives or they are totally cumbersome for the
user).

Best regards,
Michael

---

From: William Morgan <[email-masked]>
Date: Tue, 03 Nov 2009 07:16:15 -0800

William <[email-masked]>

---

From: Nicolas Pouillard <[email-masked]>
Date: Mon, 02 Nov 2009 18:47:19 +0100

Excerpts from William Morgan's message of Mon Nov 02 15:50:08 +0100 2009:
> Nice writeup. Just brainstorming, here are the features I personally
> find vital for an issue tracker that would make me happy:
> 
> 1. Web submission. The burden of creating a record should be on the
> submitter---it's not too much to ask, and it saves developer time. This
> also encourages reporters to provide relevant information like version,
> platform, Ruby version, etc. upfront, since they can be prompted for
> those data explicitly.

> 2. Developer discussion via email. This is vital. There's no way I would
> want to have a technical discussion using text boxes on a website. And
> this discussion should be attached to the issue, of course.

1,2: Same for me.

> 3. Canonicality. I want one name for a bug, and I want one URL that I
> can point people to when referring to it. That URL should have the
> entire history, including developer discussion, of the issue.

> 4. Browseability. There should be some public way of getting a view of
> all the open issues, at a minimum. (Web seems natural.) Other stuff like
> sorting by priority, attachign to releases, etc. are icing on the cake,
> but if people are going to be chipping in on development effort, or
> searching to see if other people have had this bug, they have to be able
> to browse what's out there.

3,4:

Right, I think this is part of the web-page generation tool. Which
given the YAML file will produce web-pages. The only unclear point to
me is: "how to find the archive URL for a discussion given the message-ID?"

> > 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.
> 
> I want a simple one. I can remember JIRA-style "ABC-123" names and
> that's really handy sometimes.

Right, we want short issue numbers. I'm would still be a bit sad of completely
loosing the distributed property. Maybe a solution would be to allow issues
to have an optional short name. In practice it will be just temporarily,
the time the issue makes its way to the central repository, or being just a
local issue.

-- 
Nicolas Pouillard
http://nicolaspouillard.fr
_______________________________________________
sup-talk mailing list
[email-masked]
http://rubyforge.org/mailman/listinfo/sup-talk

---

From: Kevin Riggle <[email-masked]>
Date: Sun, 01 Nov 2009 20:17:31 -0500

Excerpts from Nicolas Pouillard's message of Sun Nov 01 16:52:08 -0500 2009:
(snip)
(snip)
> 
> 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.
> 
This portion of your proposed system sounds to me a lot like SD 
(http://syncwith.us), against which writing your proposed bot would be fairly
straightforward.

- Kevin
-- 
Kevin Riggle ([email-masked]) 
MIT Class of 2010, Course VI-2 (EECS)
http://free-dissociation.com
_______________________________________________
sup-talk mailing list
[email-masked]
http://rubyforge.org/mailman/listinfo/sup-talk

---

From: Nicolas Pouillard <[email-masked]>
Date: Mon, 02 Nov 2009 22:49:39 +0100

Excerpts from Joe Wölfel's message of Mon Nov 02 21:40:21 +0100 2009:
> Excerpts from William Morgan's message of Mon Nov 02 09:50:08 -0500 2009:
> Please ignore this suggestion if you feel it is stupid, but couldn't an
> internal sup-based bug submission perform prompting and validation tasks just
> as easily as a web form? Also, wouldn't it be better for automatically
> including or verifying operating system info, version info, libraries, etc?  
> 
> It seems like this might make for a more natural transition to email-based
> developer discussion, reduce the need for centralized infrastructure, make it
> easier for users to figure out how and where to submit a bug, and possibly make
> critical system and library information more accurate and detailed.

This is indeed a nice option. Add to sup a way to send a bug report. It could
simply be an email in the chosen format for bug reporting. And indeed the
bonus is more precise information.

However in the long run this only complementary with other way to report bugs.

---

From: Mike Kelly <[email-masked]>
Date: Tue, 03 Nov 2009 13:06:52 -0500

On Tue, 03 Nov 2009 12:03:38 -0500, Daemian Mack <[email-masked]>
wrote:
> Having evaluated RT3 for fairly-intense production use at a prior
> job, I can't really say I'd recommend it for our use here.
> 
> I'd suspect, with the glut of ticket-tracker software available,
> there's something a good deal better-suited for sup out there. I'll
> chime in again if I manage to find something that seems helpful.

Yes, feel free to ignore me. It's a pain in the butt to get going. :p

On the hopefully-less-sucky front, there's Bugzilla. There is apparently a
plugin for it that lets you reply to tickets by email, but I haven't set it
up myself.

But, I'm a perl guy, so I'm likely highly biased... :)

---

From: Tero Tilus <[email-masked]>
Date: Tue, 03 Nov 2009 20:33:04 +0200

Sebastian Schwarz, 2009-11-03 18:20:
> Moreover I'd like to advertise/suggest [Roundup][1].

Now that you mention it, I've used it in couple of projects and liked
very much.

> As a note on the ease of installation: Roundup's [documentation on
> installation][4] begins with: "Set aside 15-30 minutes."  But again
> I have no personal experience to back this claim up.  Can anyone
> comment on this or Roundup in general?

I've set it up once long time ago and I don't remember anything about
it really.  Installation was fluent I guess.  ;)

Another one I like is Redmine, but its whole a lot different kind of
tool, nice and fluent tho.  It also might do pretty much what we want,
but I'd guess Roundup does it with less tuning and pluginnig.

---

From: Israel Herraiz <[email-masked]>
Date: Thu, 05 Nov 2009 00:40:22 +0100

Excerpts from Israel Herraiz's message of Wed Nov 04 11:05:45 +0100 2009:
> Check the *_ADMIN permissions. Any user with say TICKET_ADMIN
> permission can remove tickets. Same applies to WIKI_ADMIN (remove wiki
> pages), etc.

I am afraid I am wrong with this. Tickets can only be deleted by
manipulating the database. So Michael was right.

Sorry for the noise.

Israel

---

From: Daemian Mack <[email-masked]>
Date: Tue, 03 Nov 2009 12:03:38 -0500

Excerpts from Sebastian Schwarz's message of Tue Nov 03 11:20:47 -0500 2009:
> > RT doesn't come with a formal, formatted users or administrators
> > guide, but it's likely most of what you need to know to use and run it
> > is contained somewhere within this wiki, so look around a little, be
> > patient... and try not to install RT on a Sunday night when you need
> > to run it in production on Monday: it's big, and learning how to set
> > it up can take some time.
> 
> Can anyone with more experience with RT comment on this?

Having evaluated RT3 for fairly-intense production use at a prior
job, I can't really say I'd recommend it for our use here. As an
'enterprise-ready' solution, it's a bit ungainly out of the box, and
the bulk of its feature-set would probably be overkill for sup's
needs. It makes heavy use of the 'departmental queue' model whereby
many departments, consisting each of many employees, have some
permission set for many queues. Customization was a bit opaque (though
perhaps less so if you're very familiar with Perl), and though there's
an O'Reilly book for RT, I found it often fell short of my needs.

http://daemianmack.com/

---

From: William Morgan <[email-masked]>
Date: Tue, 03 Nov 2009 10:04:26 -0800

> http://www.fossil-scm.org/index.html/doc/tip/www/index.wiki

Is it possible to use the bug tracker without keeping all the code in
Fossil itself? My impression is no.  I'm very happy with git and
changing development to a brand new SCM is extremely unlikely to happen
at this point.
-- 
William <[email-masked]>
_______________________________________________
sup-talk mailing list
[email-masked]
http://rubyforge.org/mailman/listinfo/sup-talk

---

From: Israel Herraiz <[email-masked]>
Date: Wed, 04 Nov 2009 11:05:45 +0100

Excerpts from Michael Stapelberg's message of Wed Nov 04 11:00:43 +0100 2009:
> I am referring to trac 0.11.5, which does not have a possibility to delete
> comments or tickets without installing a third-party plugin (which is
> hard to use because you have to use ticket IDs). If I am wrong, please tell me
> where they hid the possibility, so I don’t need the plugin anymore.

> I consider forcing people to register to post comments/tickets as the end of
> bug reports for my project. I personally would only register at a bugtracker if
> the bug was *really* important and there would be *no* other possibility to
> contact the author of the software. However, I want to get every bugreport for
> my software and thus lower the requirements for users to actually help me
> improve my software by submitting bugreports.

Right. It is not the best elegant solution at all.

Cheers,
Israel

---

From: William Morgan <[email-masked]>
Date: Tue, 03 Nov 2009 09:25:29 -0800

Reformatted excerpts from Sebastian Schwarz's message of 2009-11-03:
> Moreover I'd like to advertise/suggest [Roundup][1].  Apart form a slim
> web interface -- [here][2] Python's issue tracker as an example -- it
> also offers a fully functional [email interface][3], which allows --
> from what I understand -- creating, discussing and setting properties
> like status and labels of issues.

Nicolas suggested this too. I tried installing it locally (late on a
Sunday night, with a screaming infant in my ear) and couldn't get it to
behave. But, bugs.python.org looks great, and it looks like they're using
email to discuss and change issue state, which is awesome. I'll give it
another shot.
-- 
William <[email-masked]>
_______________________________________________
sup-talk mailing list
[email-masked]
http://rubyforge.org/mailman/listinfo/sup-talk

---

From: William Morgan <[email-masked]>
Date: Mon, 02 Nov 2009 06:50:08 -0800

Just my two cents.

---

From: Mike Kelly <[email-masked]>
Date: Tue, 3 Nov 2009 19:07:24 -0500

On Wed, 4 Nov 2009 12:11:31 +1300
Jim Cheetham <[email-masked]> wrote:

> On Mon, Nov 2, 2009 at 10:52 AM, Nicolas Pouillard
> <[email-masked]> wrote:
> > I would like to discuss more the issue of choosing a bug tracker
> > for sup.
> 
> Having had a quick read of this thread, I think that trac
> (http://trac.edgewall.com) would meet your goals.
> 
> It's a simple single-project combination of wiki, ticketing engine and
> repository browser. Tickets can be received by email, ticket updates
> can be emailed to a set of interested subscribers, and checkins to the
> repository can close tickets (via simple hooks). The wiki markup
> provides simple access to changes, tickets & files.

Trac doesn't really allow you to reply to tickets by email. At least,
not with any plugin that I've used.

---

From: Reid Thompson <[email-masked]>
Date: Tue, 3 Nov 2009 12:03:38 -0500

> http://www.fossil-scm.org/index.html/doc/tip/www/index.wiki
forgot to mention, it's developed by the same person as sqlite 
_______________________________________________
sup-talk mailing list
[email-masked]
http://rubyforge.org/mailman/listinfo/sup-talk

---

From: Nicolas Pouillard <[email-masked]>
Date: Mon, 02 Nov 2009 09:46:34 +0100

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:

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

This only miss the "vote for this issue" feature, which we can avoid
in the mean time and delegate to a polling tool afterward.

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

---

From: Jim Cheetham <[email-masked]>
Date: Wed, 4 Nov 2009 12:11:31 +1300

On Mon, Nov 2, 2009 at 10:52 AM, Nicolas Pouillard
<[email-masked]> wrote:
> I would like to discuss more the issue of choosing a bug tracker for sup.

-jim

---

From: Joe Wölfel <[email-masked]>
Date: Mon, 02 Nov 2009 15:40:21 -0500

Cheers,
Joe

---

From: Mike Kelly <[email-masked]>
Date: Tue, 03 Nov 2009 09:50:55 -0500

On Mon, 02 Nov 2009 06:50:08 -0800, William Morgan
<[email-masked]> wrote:
> 1. Web submission. 
> 2. Developer discussion via email.
> 
> 3. Canonicality.
> 
> 4. Browseability.
> 

As much as I hate to suggest it... RT[1] should have all of these
qualities. It's used by CPAN, among other things. And, a sample ticket of
mine[2].

[1] http://bestpractical.com/rt
[2] https://rt.cpan.org/Public/Bug/Display.html?id=45040

---

From: Nicolas Pouillard <[email-masked]>
Date: Mon, 02 Nov 2009 09:30:03 +0100

> (http://syncwith.us), against which writing your proposed bot would be fairly

SD looks indeed really fun, however I think it fails my simplicity goal.
Indeed the tool expose tons of commands and try to abstract how it is made,
I'm in favor of better knowing the underlying store (a YAML file), and simply
storing it with usual DVCS tools.

---

From: Sebastian Schwarz <[email-masked]>
Date: Tue, 3 Nov 2009 17:20:47 +0100

On 2009-11-03 at 07:16 -0800, William Morgan wrote:
> Is it a pain to set up?

I have never installed, administered or used RT before, but curiously
digging around its homepage I found this:

http://bestpractical.com/rt/features.html praises it as "Easy to
install".  However on http://wiki.bestpractical.com/view/HomePage

[1]: http://roundup.sourceforge.net/
[2]: http://bugs.python.org/
[3]: http://roundup.sourceforge.net/docs/user_guide.html#e-mail-gateway
[4]: http://www.roundup-tracker.org/docs/installation.html#installation
_______________________________________________
sup-talk mailing list
[email-masked]
http://rubyforge.org/mailman/listinfo/sup-talk

---

From: William Morgan <[email-masked]>
Date: Mon, 02 Nov 2009 11:20:32 -0800

Reformatted excerpts from Nicolas Pouillard's message of 2009-11-02:
> Right, we want short issue numbers. I'm would still be a bit sad of
> completely loosing the distributed property. Maybe a solution would be
> to allow issues to have an optional short name. In practice it will be
> just temporarily, the time the issue makes its way to the central
> repository, or being just a local issue.

I just think it would be really useful to say stuff like "this is a
duplicate of #154" or "fixing this depends on index-48" or whatever, and
have everyone be able to find that easily, e.g. by going to
http://sup.com/bugs/index-48. Having to refer to the hashes in Ditz was
irritating.
-- 
William <[email-masked]>
_______________________________________________
sup-talk mailing list
[email-masked]
http://rubyforge.org/mailman/listinfo/sup-talk

---

From: William Morgan <[email-masked]>
Date: Mon, 02 Nov 2009 06:58:18 -0800

> tracking service that suits our needs.

I'm not dead-set against a hosted solution, but I am wary of making too
much of the development cycle reliant on third parties. E.g. I see
people who can't get any work done when Github is down. Well, that's not
Github's fault, per se, but they've integrated it into their process to
such an extent that they're now reliant on it.

Not to say that that would happen with just an issue tracker. But still,
our use of Gitorious and Rubyforge is pretty minimal right now, and I
feel good about that.

(And honestly I find Gitorious merge requests a little irritating,
because they're invariably not rebased properly against master and I
have to have the same discussion every time.)
-- 
William <[email-masked]>
_______________________________________________
sup-talk mailing list
[email-masked]
http://rubyforge.org/mailman/listinfo/sup-talk

---

From: William Morgan <[email-masked]>
Date: Mon, 02 Nov 2009 06:53:08 -0800

> Requirement: Bug submission by email?

That's what we have now, basically, and what we had when we were using
ditz, and I didn't like having to do the extra work of making an issue.

> do we need severity and priority?  What would they be used for?

At least one type of ordering would be nice. There are a large class of
feature requests where my basic feeling is "sure, that would be nice,
but I've got a million other things more important to do", which I would
like to keep around as food for later thought, if nothing else, but
would like to basically ignore in the near term.
-- 
William <[email-masked]>
_______________________________________________
sup-talk mailing list
[email-masked]
http://rubyforge.org/mailman/listinfo/sup-talk

---

From: Michael Stapelberg <[email-masked]>
Date: Wed, 04 Nov 2009 11:00:43 +0100

Hi,

Excerpts from Israel Herraiz's message of Mi Nov 04 10:44:02 +0100 2009:
> I have been using Trac since a couple of years now, and it is sensible
> to spam, ok, but you can always delete comments, tickets, or anything

> in general, and force people to register to post comments or tickets,
> to fight against spam.

Best regards,
Michael

---

From: Israel Herraiz <[email-masked]>
Date: Wed, 04 Nov 2009 10:44:02 +0100

> spam, they have false-positives or they are totally cumbersome for the

I am not going to recommend Trac, because it does not fulfill the
requirements listed by William, but that thing you say is simply not
true.

Cheers,
Israel

---

From: Nicolas Pouillard <[email-masked]>
Date: Sun, 01 Nov 2009 22:52:08 +0100

Hi,

(I've made a new thread for clarity)
(This is a cross post of a post[1] on my blog)

Note also that I would make no objection to using a traditional bug tracker.

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.

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.

Then, optionally a simple set of HTML pages can be generated using the YAML file.

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/

---

From: Reid Thompson <[email-masked]>
Date: Tue, 03 Nov 2009 14:30:23 -0500

On Tue, 2009-11-03 at 10:04 -0800, William Morgan wrote:
> Fossil itself? 

I just created an empty repository.  Contains no source code files.

$ fossil new bugtracker-only
$ fossil open bugtracker-only
$ ls -rlt /tmp/bugtracker-only 
-rw-r--r-- 1 rthompso staff 50176 2009-11-03 14:23 /tmp/bugtracker-only

$ fossil ui

did minimal admin/config -> http://localhost:8080/setup_config
then added tickets etc, looks like the data entry is free-form, so not
tied to a source version existing etc.

attached png.

---

From: Nicolas Pouillard <[email-masked]>
Date: Mon, 02 Nov 2009 18:38:54 +0100

> ditz, and I didn't like having to do the extra work of making an issue.

Right, but in this setup only well formatted bug reports are accepted, so
no extra burden on devs.

---

From: Nicolas Pouillard <[email-masked]>
Date: Mon, 02 Nov 2009 21:23:58 +0100

> http://sup.com/bugs/index-48. Having to refer to the hashes in Ditz was

I agree, that's way I proposed it.

---

From: Tero Tilus <[email-masked]>
Date: Mon, 02 Nov 2009 09:01:31 +0200

Requirements collected:
 - Store/track

...

---

From: Dan Falcone <[email-masked]>
Date: Tue, 3 Nov 2009 13:37:22 -0400

Hi all,

Thought I'd chime in regarding RT.  I've never configured it, but we use it
internally where I work, so I can comment on it from a user perspective.  I
mainly use the email interface, which is very finicky.  If you include
attachments that are too large, RT will ignore your message and will not
attach it to an existing ticket or open a new ticket.  Our instance is well
known to modify attachments (changing the md5sums), which causes all kinds
of problems for us.  Maybe this part is user error, but it also sends 2
copies of every message and doesn't always CC everyone on the ticket when it
is supposed to.  So you either get 2 copies of each email, or zero.  Either
way it sucks. We have lots of processes in place to work around the issues
RT creates for us.  Basically the only reason we use it is for archival
purposes.

Again, I did not install and do not administer this instance, so there could
be configuration issues or possibly newer versions that address these
shortcomings.  However, given my past experience, I wouldn't recommend it.

-Dan