On May 12, 2008, at 9:35 AM, Jason Dagit wrote: >> To open issue tickets in this tracker, send e-mail to >> "[EMAIL PROTECTED]".
> 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 _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
