Darcswatch is a darcs patch tracker written in Haskell.
The key feature for me right now is that it's already running :-)

See DarcsWatch tracking the darcs darcs repo here:
  http://darcswatch.nomeata.de/repo_http:__darcs.net_.html

I'm creating a ticket to track the state of darcswatch, specifically of
things that we think would make it easier for us to adopt darcswatch
into the workflow.

Normally I like splitting things into a bunch of separate tickets, but
in this case, I think it's probably better to have a sort of mother list
pointing to everything.

Here's a starter list

1. Slow - Firefox complains about query.js seeming not to respond when I
   do things

2. Lack of web interactivity (would be nice to 'push a button' to reject
   a patch); but would probably need a login of some sort

3. UI design: needs somebody to work out how to make the website more
   useful from a design standpoint

4. Needs issue tracker: it may be good if the darcswatch project had its
   own bugtracker (perhaps Joachim could consider creating one on
   trac.haskell.org?).  Then we could link to the issues which are
   important to us from there.

Thanks!

5. Another thought: rather than directly trying to solve the problem of building
a nicer web interface to darcswatch : how about using darcswatch as a gateway to
a general purpose tracker such as roundup?

I like the idea of number 5. An extension to darcswatch could be written that
monitors the tracker, gathers any submitted patches from there, links them to
the correct ticket on the tracker and, for these patches, makes the
"Applicable/Obsolete/Rejected"-state reflect the state of the ticket.

Additionally, if it finds a patch applied, it could automatically close the
corresponding ticket (or at least add a note that the ticket may be closed).

On Wed, Sep 09, 2009 at 15:32:01 +0000, Joachim Breitner wrote:
> I like the idea of number 5.

Yay!

> An extension to darcswatch could be written that monitors the tracker,
> gathers any submitted patches from there, links them to the correct
> ticket on the tracker and, for these patches, makes the
> "Applicable/Obsolete/Rejected"-state reflect the state of the ticket.

> Additionally, if it finds a patch applied, it could automatically close the
> corresponding ticket (or at least add a note that the ticket may be closed).

Are you able and willing to work on this in the near future?
If so, is there anything we could do to help?

I suggest actually taking roundup as a first tracker to experiment with
(i) for the selfish reason that we're already familiar with it and (ii)
because it's so versatile.

See http://roundup.sourceforge.net/doc-1.0/design.html
It just provides a way of defining bricks and linking bricks together.

Thanks!

I’d welcome any help, as my own motivation is not too great here (darcswatch
fully fulfills my needs at the moment) - I hope understand that POV. Also, I
don’t know much about roundup.

If one would be willing to write part of the code in python, one could re-use
code from the bts-link project, e.g. here is the roundup module:
http://git.debian.org/?p=bts-link/bts-link.git;a=blob;f=remote/roundup.py;hb=HEAD.
It only supports reading the status though, and not download patches.

So, what would be the best way to read data from roundup? Make it send out mails
upon each change (included attached patches and status changes)? Scrape the web?
Run some script on the roundup side that neatly formats the required data?

I've started an email thread here.  We're now waiting for the outcome of that
discussion:

http://lists.osuosl.org/pipermail/darcs-users/2009-September/021248.html

I think this is fixed by Joachim's work over the sprint.  Woo!