It would be nice to have roundup-darcs integration, so that bugs could be
automatically marked as resolved in various branches based on whether
a certain patch is present in a certain version.

I'm imagining that we'd add two fields to each issue an "introduced-by"
field and a "fixed-by" field, each of which would contain an optional darcs
patch hash.  The first would be used to determine, for example, that a bug
is not present in the stable release, and the second would determine when
it gets fixed.  Roundup would obviously need to know about a few darcs
repositories and how to query them.

We could use a darcs posthook to set these fields based on patch comments.
Then we'd need some roundup code to display the patch in a nice manner
(don't want to display just the hash itself) and perhaps link to the
darcs.cgi script.  We'd also of course need to add code to change the
status of bugs based on the contents of darcs repositories.

I don't have time to work on this (although I've obviously been thinking
about it) so if there's a python coder and/or roundup user out there in
search of a project to work on, this would be wonderful to have.
-- 
David Roundy
http://www.darcs.net

As an alternative, some Python hacker could add an e-mail-integration plugin to
trac [1].  Then trac+darcs [2] would be a good candidate for replacing the
roundup instance, in my ever-so-humble opinion.

Of course, trac+darcs is immature, and one should consider the list of open
tickets [3] before deciding to make the jump.

[1] http://www.edgewall.com/trac/
[2] http://progetti.arstecnica.it/trac+darcs/
[3] http://progetti.arstecnica.it/trac+darcs/report/1

See related issue #491.

We now have some darcs.cgi integration with the work I did earlier today.  

David, what format do we want to use for auto-bug resolution? How about agreeing
on-this pattern:

resolve-in-unstable issue58: my message explaining that I fixed it in unstable
resolved issue58: Fixed everywhere
resolved-in-stable issue58: Fixed in stable now. 
testing issue58: I probably fixed it...needs testing. 

So, the part before the colon is the new status, and then the issue number. 

The post-hook would fire off a perl script on the server which would parse that
and then connect to the roundup PostgreSQL database and run something like:

 UPDATE _issue SET _status = 5 WHERE ID = 58;

There are some details to work out, but this doesn't sound too hard, and would
also serve as a useful for example for how to integrate darcs with other web/db
bug trackers.

Ok, attached is a Perl script that should work for a posthook, using the patch
name semantics described below. It should be clear enough how to modify if you
want different pattern matching semantics. 

I would prefer if it also automatically left a comment in Roundup as well as
updating the status. 

That would be possible if we had the posthook send an e-mail to Roundup instead
of using the CLI, because the e-mail interface supports a syntax like this:

Subject: Re: [issue1] the coffee machine is broken! [status=resolved]

Then of course the e-mail body would become the comment. 

The e-mail could include the full patch comment and a link to the full patch in
darcs.cgi. 

   Mark

Attachments

• update_roundup.pl

While the current "update_roundup.pl" that is attached should be useful, as I
mentioned better integration would come by triggering e-mails to the bug
tracker, as I mentioned recently. To proceed with that, we really need for the
posthook feature to export DARCS_PATCHES_XML, so I'm marking issue686 as a
superceder. 

I'd be happy to finish up this integration work when that's done. 

To recap the work flow: 

- A developer enters "resolved-in-unstable issue123: Fix foo" in the ticket name. 

- David accepts the patch to the central unstable repo. 

- An e-mail would automatically be triggered from this developer to
bugs@darcs.net with the patch name and new status in the subject line, and patch
 comment in the body, causing the bug tracker to be updated, and interested
parties to be notified. Further, the email would include a link to view the
patch through darcs.cgi. 

The process saves the developer (or David, or a usually non-existent bug
triager) the extra step of manually visiting the bug tracker to update the status.

Of course, the downside is that the status change is "locked" in the patch name.
A developer could include "resolved-in-unstable" in the patch name, and David
could disagree about the status change. He could either ask for an
amend-recorded variation of the patch, or manually update the status in the bug
tracker, after the patch has caused an automatic update.

   Mark

I'd actually prefer not to have to notate resolved-in-unstable versus resolved
etc in the patch.  Ideally, the state of resolved-ness would be determined by
the presence of the resolution patch in various repositories.  i.e. when the
"resolve issueXXX" patch is pushed to unstable, the issue should be marked
resolved-in-unstable, and when it is pulled to stable, it should be marked as
resolved-in-stable, and when it is finally tagged as a release, it should be
marked resolved.

But this is still a nice feature, and I'll be adding it to the repository so we
can work on it collaboratively.  Also, I hope it'll be a useful example for
other folks looking to implement similar functionality.

And I note here that issue686 is now resolved.

I'm considering this resolved now. Let's open a new ticket if there more
specific roundup/darcs improvements we want to track.