On Sat, Sep 03, 2005 at 06:23:35AM -0400, Ian Lynagh via RT wrote:
> I think pretty much everyone I've seen interact with darcs' RT has
> disliked it.

The one major advantage of RT is that it works with email, which many of
the alternatives do.  Trac, for example, doesn't seem to have any email
support.  I'm not a big fan of RT, but I also don't enjoy installing or
configuring web apps, so I'm not excited about doing any change myself.
And I see email support as pretty much a required feature (although I could
imagine being convinced otherwise).

I see the fact that RT can accept bug reports by anonymous email as a major
advantage.  It would be *nice* if it were even more email-oriented like the
debian BTS.

> The various deficiencies of RT, coupled with not seeing anything that
> seemed perfect to me when looking around, motivated me to start writing
> a BTS that worked the way I want it to, rather than one that required I
> work how it wanted.

It'd be nice to not have the work of dealing with one's own system, but as
you say, if there isn't a decent BTS out there already, perhaps creating
one's own is a reasonable option.

> You can have a play with the current state at
>     http://urchin.earth.li/cgi-bin/ian/Index

It seems a bit buggy to me, but I can see promise.  I wonder if one could
just go with a google link for the search feature? I don't see how one
could use that to restrict searches on fields or categories, but it would
seem to be the easiest way to get some sort of a search feature.

> I'd be interested to know what people think of replacing RT with this
> (once it is a bit more finished), as well as any problems you have with
> its design.

I wouldn't mind darcs being the testbed.  Bark does look like it's got
email integration, which to my mind is the only important feature missing
from most BTSs.

One *very* nice feature would be to do just a bit of integration with darcs
to allow tracking of when a bug is broken, and in which versions it's
fixed.  I'm always torn when closing bugs between whether to close them
when the fix goes into unstable, stable or an actual released darcs.  And
this information would also be useful to users... if they can browse bugs
exisiting in their darcs, and see whether they've been closed in a later
darcs, that would be great.  I'm not sure the best way to do this sort of
integration, but figured I'd throw the idea out.

We might be able to do something as simple as add a "introduced-in" and
"fixed-by" pattern to the database, which would be --match style patterns,
and then for a given darcs repository (or tag in such a repository, or
darcs "context"), the bug exists if the "introduced" patch exists, but not
the "fixed" patch.
-- 
David Roundy
http://www.darcs.net

_______________________________________________
darcs-devel mailing list
[email protected]
http://www.abridgegame.org/cgi-bin/mailman/listinfo/darcs-devel

Reply via email to