[darcs-users] a new issue tracker that darcs developers could consider using (Re: bugs.darcs.net issues)

Mon May 12 16:39:15 UTC 2008

On May 12, 2008, at 9:35 AM, Jason Dagit wrote:

>> To open issue tickets in this tracker, send e-mail to  
>> "darcsbugs at allmydata.org".

> I did that, http://allmydata.org/trac/darcs-2/ticket/7  But now I  
> can't seem to edit the bug nor did I receive confirmation email.   
> Is an account required?  If so, that's not so bad for devs, they'd  
> probably want an account anyway, but I can see that being very  
> annoying for users.

I just changed the setting to allow anonymous users to edit tickets.   
(I've seen spammers abuse such functionality in the past, but if they  
do so again then we'll just clean up after them and then reconsider  
this setting.)

>> The key feature which makes trac more interesting than roundup for  
>> darcs development is integration of source code and revision  
>> control.  This enables easy interlinking between the tickets, the  
>> source code that the tickets are about, and the patches that  
>> change the source code and close the tickets.

> Could you show us how to do this source code linking in the  
> ticket?  I wanted to play around, but I can't edit the ticket I  
> made.  I'm also not convinced that trac is inherently better than  
> roundup.

I added a comment to your ticket #7: http://allmydata.org/trac/ 
darcs-2/ticket/7

> Trac has the advantage that it is fairly well maintained and  
> growing a lot the last few years.  There is a lot to be said for  
> using software that has momentum.  But, I have often felt like trac  
> is a bit obnoxious to use.  I recall sumbitting a cut&paste bug  
> report in some trac ticket once and as I recall it assumed I wanted  
> to use wiki markup so it ignored all the whitespace.

This behavior of trac has bothered me more than once in the past,  
until I got used to bracketing all of the literal text between  
{{{ }}}.  Now I'm used it it, and I appreciate distinction between  
text and literal in tickets (because it is useful to reformat text in  
a variable-width font to fit your web browser page, but it is better  
to preserve indentation and line wrapping verbatim in a fixed-width  
font for source code snippets or shell transcripts).  However, if you  
want I can figure out how to disable that behavior and make it treat  
all text as literal unless specified otherwise.

By the way, a lot of "[tool] is a bit obnoxious to use" is a matter  
of personal preference or familiarity.  This particular behavior of  
trac was obnoxious to me several times until I finally trained myself  
to adjust to it.  On the other hand, it is the only behavior of trac  
that I can think of at the moment which was obnoxious.  I've had a  
lot more "obnoxious moments" with roundup over the years than with  
trac -- too many to list in the margins of this e-mail.  Your mileage  
may vary.

> Those rXXXX numbers are not such a good idea with darcs.  I'd much  
> rather have a link to the patch name.

That would be cool.  Trac already supports mercurial revision ids,  
which are a string of hex chars, so this feature could be added by  
various hackers including the trac folks, Lele Gaifax, myself, and  
the members of this list.

In the meantime, the way to reference patches at http://allmydata.org/ 
trac/darcs-2, by revision number, like this:

http://allmydata.org/trac/darcs-2/changeset/5706

Is better than the way to reference patches at http://darcs.net,  
which is currently "There is no way to do it.".  There used to be a  
darcs.cgi, but David Roundy disabled it because it was (if I recall  
correctly) leaking memory and because nobody, least of all David, had  
time to debug and administer it.

> The "view changes" button that appears on some pages seems broken  
> or silly.

What's the "view changes" button?  Oh, there it is.  <Zooko tries it.>

Yeah, that's useless.  I've never noticed its existence before.   
Instead, click on the "Revision Log" link at the top of the page when  
you are viewing a file.  It shows you a list of all patches which  
have touched that file and allows you to diff any pair of them.   
Cool, eh?

>> The "Buildbot" button takes you to the buildbot, of course, and  
>> the "View Tickets" and "New Ticket" buttons do just what you'd  
>> expect.

> I went looking for this promised "New Ticket" button but I cannot  
> find it.

You want anonymous users to be able to create tickets, too?  Okay,  
done.  Now there is a "New Ticket" button even if you haven't logged in.

> Next I looked at the search page.  From here, I can do a search of  
> tickets, but it seems extremely limited.  I think even the current  
> roundup search, which I'm not terribly fond of, is better.

Can you be more specific?  I personally find that it is hard to find  
tickets on http://allmydata.org/trac/tahoe (the trac that I use for  
my work and my most important open source project), but that it is  
even harder to find tickets on http://bugs.darcs.net .

> Is the site indexed by google?  Given the current URL I think if I  
> specified site:allmydata.org I would get too much.

You can use the google "inurl" feature:

http://www.google.com/search?q=site%3Aallmydata.org+inurl%3Adarcs-2 
+dagit

But a better solution would be to make http://bugs.darcs.net be the  
name of this trac instance.

> Yes, the annotate feature is pretty nice, although I found it  
> tricky to actually go visit the patches that are linked in the  
> margin.  It seems to require some combination of clicking and then  
> hovering.  And then I was told:
> OperationalError: database is locked

Both the "seems to require a combination of clicking and then  
hovering" and the "database is locked" are because it took darcs a  
long time to do the file annotate.  Trac could potentially be  
improved by giving user feedback indicating that your click is being  
served before the revision control tool finishes generating the  
content, and by releasing the database lock while waiting for the  
revision control tool to answer queries, but of course the more  
interesting improvement to me would be to make darcs faster at  
answering such queries.

For what it is worth, trac+darcs caches the results, so subsequent  
views of the same data will be fast.

> Ultimately, I see a change as expensive.  People that currently use  
> roundup have to learn something new and then there is the migration  
> of urls and existing bugs (which will have broken links internally  
> now).

I might be able to migrate the existing URLs and even internal links,  
i.e. to make "http://bugs.darcs.net/issue693" denote the contents of  
the original issue #693, but now in the trac instead of in the  
roundup.  (For starters I need someone to send me a fresh dump of the  
roundup db, as mentioned in http://allmydata.org/trac/darcs-2/ticket/ 
7 .)

> I appreciate your hard work Zooko.  You obviously want to make  
> darcs better and darcs development easier.  Is migrating to trac  
> the right way?

Thanks!

It's not perfect, but it's pretty good.  Also, what's the  
alternative?  Currently if you go to the darcs front page at "http:// 
darcs.net", it says:

  * The Darcs Wiki
  * Bug Tracking System
  * Darcs repository browser

Those are three different tools, two of which are currently broken.   
(The bug tracker has been broken for around 48 hours now, the  
repository browser has been broken for weeks or months.)

And who is going to fix them?  I'm not.  I hope David Roundy isn't,  
because he has better things to do with his time.

If we switch to trac, then we get three main advantages:

1.  All three of those services are integrated with each other in one  
tool.

2.  Active development of trac means more people to fix bugs and  
extend functionality

3.  I'm willing to system-administrate it.

(Partly because I already administrate http://allmydata.org/trac/ 
tahoe , http://allmydata.org/trac/pycryptopp , and several other trac  
instances, so managing the darcs one as well isn't that much extra  
effort.)

Regards,

Zooko