I propose to change the darcs bug tracking and wiki from roundup to trac+darcs,
e.g.:

http://allmydata.org

It integrates, wiki, issue tracking, and revision control.

On Fri, Jun 29, 2007 at 08:02:37PM -0000, Zooko wrote:
> I propose to change the darcs bug tracking and wiki from roundup to trac+darcs,
> e.g.:
> 
> http://allmydata.org
> 
> It integrates, wiki, issue tracking, and revision control.

But also doesn't support email, unless its status has changed.  I like
responding to bugs by email.
-- 
David Roundy
Department of Physics
Oregon State University

> But also doesn't support email, unless its status has changed.  I like
> responding to bugs by email.

I, too, prefer e-mail to Web.

This trac plugin apparently does what we want:

https://subtrac.sara.nl/oss/email2trac/wiki

Regards,

Zooko

The TracDarcs plugin still has some kinks to work out.

For example, it sometimes does not like it when you move files or directories
(if I remember correctly).  Then again, this only affects the browse source or
browse changeset stuff.

Also, it might be nice to wait until the plugin supports multiple repositories,
so that we could have both stable and unstable branches traced by the same
instance.  Then again, how would referring to changeset by number work?


Seems like an answer might be yes if
* somebody is willing to migrate everything (moinmoin => trac; roundup => trac)
* we can make email work just as well

See related issue #58.

I personally much prefer MoinMoin to the wiki Trac provides, and switching over
the wiki and the bug tracker sounds like a big pain.

Trac now has email-to-ticket functionality:

http://trac.edgewall.org/ticket/250

Also, the bug that kowey mentioned in msg1815 below has long since been fixed. 
For an example of trac+darcs that works, please see http://allmydata.org .

Just to review, the reason why switching to Trac would be interesting is that
Trac can be integrated with darcs, to integrate patches, bugs, and wiki pages.

I don't have an opinion about MoinMoin vs. Trac Wiki.  Actually, I do: I hate
them both and wish the world would go back to HTML.  ;-)

Seriously folks, Trac has darcs integration.  That should be make it
interesting.  Check it out.  Also, Trac is, I think, the bug-tracking tool with
the most development effort and extensions and so on nowadays.

Because it would be significant effort to migrate the wiki over, it 
seems worth nailing down the "integration" benefits which would be new 
to us. Right now the following is possible:

- We can resolve tickets in the stable or unstable branches by how we 
nave the patch.
   - When that happens, we link to web-based repo tracker for details.

- Each issue links to all the related patches for it.

Plus, MoinMoin is generally an excellent wiki built to do just that.

What, specifically, would trac+darcs enhance for us?

And even when the benefits are known, there is the matter of the 
volunteer labor to complete the migration.

I'm not opposed to the idea, so much as I'm not volunteering for it.

    Mark

"I'm not opposed to the idea, so much as I'm not volunteering for it."

Understood.  I'm not volunteering for it either, at this point, although I might
in the future.  So far I've set up two trac+darcs installations, but that was a
year ago.  If I set up another one (for pycryptopp) in the future, then I might
decide that it is easy enough that I would volunteer to do it for darcs.

For the record, here is what trac+darcs offers over roundup+customizations.  The
following is a guided tour -- please click on the hyperlinks to observe for
yourself what is described in this ticket.

With trac+darcs, you a uniform interface to your bug tracker, wiki, revision
control history, and buildbot.  For example, at http://allmydata.org there are,
on every page, a series of buttons across the top:

Wiki, Timeline, Roadmap, Browse Source, View Tickets, Search, and Buildbot.

The Wiki link takes you to the wiki, which can have links in it like
"[source:README]", which are automatically turned into hyperlinks to the current
version of the README file in revision control.  Or you can write
"[source:README@1222]" to link to revision #1222 of that file.  Or
"[source:README#L99]" to link to line #99 of that file.  Please try it out to
see what I mean: http://allmydata.org/trac/tahoe/wiki

The Timeline link takes you to a unified history showing changes to the source
(i.e. darcs patches), changes to tickets, changes to the wiki:
http://allmydata.org/trac/tahoe/timeline .  See?

If you view one of the changes, e.g.:
http://allmydata.org/trac/tahoe/changeset/2179 then it shows you which files
were changed (whose filenames are, of course, hyperlinked into the source tree),
and if the revision control patch description contains ticket numbers, then that
becomes a hyperlink to the ticket.  Here's an example of the latter:
http://allmydata.org/trac/tahoe/changeset/2137 .  If you click on the ticket
number on that page, #237, then it takes you to this page:
http://allmydata.org/trac/tahoe/ticket/237 -- the page describing that ticket. 
The comments on the ticket page can include hyperlinks to darcs patches, such as
the final comment on that page which shows which patch fixed this ticket.

This is very nice for being able to easily investigate which patches are
supposed to have fixed (or caused) which bugs.

Okay, the next link in the list is the RoadMap.  That is a convenient way to
group tickets into Milestones which are associated with a schedule. 
http://allmydata.org/trac/tahoe/roadmap  Hm.  That shows that allmydata.org
v0.8.0 is due to be released in 15 hours.  I'd better hurry up with this note
and get back to it.

The next link in the list is the Browse Source link.  That is like darcsweb or
darcs.cgi, but of course it is integrated with the rest of trac, so that you can
easily navigate from the source tree into the Timeline, and the Tickets, and so on.

The next link in the list is the View Tickets link.

The next link is the Search link.  You can search in Tickets, Changesets, or
Wiki.  Personally I don't find the search link very useful.  (Nor do I find
roundups search feature that useful.)  In fact, I often just google for
"site:DNS.NAME.COM ticket description" instead of using the search engine built
into a bug tracker.

The next link is the BuildBot.  This isn't strictly a feature of Trac (it is a
separate project due to Brian Warner), but the fact that it is barely integrated
into Trac (by inclusion on the button bar at the top of every page) is
indicative of how much positive development energy Trac has.

BuildBot is an excellent tool that runs your unit tests and builds your binary
packages, on a host of platforms, automatically, every time you push a patch. 
Darcs should really use a BuildBot.  But this is mostly a separate issue from Trac.

Zooko,

Your description of trac+darcs does sound very nice.  Let me briefly list
the few features of our customized roundup that I'd rather not live
without.  These may be addressed by the little python script you
referenced, but I figure by listing them here, you (or anyone else) will be
enabled to go out and see if trac can do the same.

Any user can submit bugs to the system simply by emailing bugs@darcs.net
(possibly with a delay for moderation if they've never submitted a bug
report before).  When they do so, an account is automatically created for
them, associated with their email.  Any future traffic on the bug CC's
them.

Developers (or users) can configure roundup to automatically include them
on all email related to darcs bugs matching a given topic (and the All
topic exists to allow users such as myself and Eric to be on the CC list
for all bugs).  It's also useful for our Windows developers to be
automatically included in all discussion of Windows bugs.

Every bug report is CCed to the -devel list, but later traffic is
restricted to persons interested in those bugs (as defined above).

Anyone who replies to a bug report email (or is cc'ed on a reply to such an
email) is included in future mailings regarding that bug.  This last
feature is key, as it allows us to easily include interested parties,
without ever worrying about someone dropping folks from the cc list.  It
also means that people interested in bugs don't need to know anything about
the system in order to include themselves in the process.
-- 
David Roundy
Department of Physics
Oregon State University

See Zooko's trac instance here
  http://allmydata.org/trac/darcs-2

And also my notes on how to use this (Roundup) bugtracker better
  http://wiki.darcs.net/index.html/BugTracker

Zooko, I think your next step would be to try importing Roundup bugs (with our
help) and to respond to each of David's wishes one-by-one.  I'm reluctant to
change (by sheer inertia), but hey, if you're willing to make it work, let's
see!  Plus, your buildbot call makes me more inclined to trust you on these kind
of things...

Thanks for pushing on this!

Okay, I'll keep plugging away at bits of configuration for the trac instance.

Thanks for the compliment re: buildbot.  However, I don't think that switching
from roundup to trac is nearly as important as switching from
no-automated-testing to buildbot.  I would be okay continuing to use roundup.

I don't see trac matching roundup's mail handling any time soon, and don't think 
"deferred" is useful status, so closing this. Feel free to re-open if this becomes 
a hot issue again.

I don't intend to re-open this ticket, because people like Thorkil and Eric Kow
who are more directly responsible for issue tracking are satisfied with roundup.
 However, I'm not currently aware of any "mail handling ability" that roundup
does that trac doesn't, so if that is really the only difference which is
important to someone, let it be known that I can make tracs work through e-mail.
 I previously implemented this on the demonstration-darcs-trac and David Roundy
tried it out to see if it worked.