Splitting this off from msg6056.

The goal is to have a page that we could visit that will give us an overview of
the outstanding patch bundles to review and their status.  

Roundup is one tool that we can use for it.  I don't think it should be used for
tracking discussion, but it is pretty good for tracking state.  An advantage to
using roundup is patches and issues can then point to each other seamlessly.

As Simon suggested, we could add a patch type, so that we could refer to patch1,
patch2.

It's easy to get roundup to forward patches to darcs-users without making
darcs-users nosy.

In the future, we could also extend the issue type to multi-link to patches or
perhaps the other way around.

To comment on Simon's KISS suggestion, I would oppose using the current issue
type to track patches.  I may be wrong but I feel that it would be a lot cleaner
to keep the two separate.

Just a status update: thanks to Simon, we now have a patch class in roundup.  It
doesn't do anything yet because we haven't hooked it up to a user interface, but
just know that there is some progress on this front.

Another status update:
- http://bugs.darcs.net/patch?@template=item is the current UI
- I've added a patchstatus class (http://bugs.darcs.net/patchstatus)
- Patches now point back to issue(s)

TODO:
- Email integration (this is the big one)
- Work out kinks in UI - what happens when people send amended versions?

TODO:
- link patch UI from the main interface

Here's the tracking interface: http://bugs.darcs.net/patch

I'm not going to work on any UI for actually doing patch-review for the moment.
 That will continue on the mailing list.  There is a certain cost here where
we'd need somebody to watch the list and update the tracker accordingly, but we
can hopefully mitigate this this with
- cc patches@darcs.net subject: [status=accepted]
- automation via darcswatch

OR we could recognise that the cost is hard to avoid, which I can elaborate upon
on the mailing list if you *really* want me to.

On Thu, Oct 22, 2009 at 08:19:50AM +0000, Eric Kow wrote:
> - cc patches@darcs.net subject: [status=accepted]

BCC might be better capture your intent (i.e. avoid a slew of user
replies also hitting the tracker).

Here's the latest status.  I've fixed the problem of anonymous viewing of
patches and also created some simple links on the main page to show unassigned
patches, all patches, your patches.

This now *almost* useable.  We still need to solve:
- incoming email => patch tracker [spam filter problem]
- patch tracker  => mailing list?
- mailing list back to patch tracker [bcc patches@darcs.net, likely]

I'm hoping that the 1st and 3rd bit could be automated by DarcsWatch, which
would also make the second bit moot.

Alternatively, if we did not have such automation then indeed it would probably
make sense to (1) have a patches@darcs.net that incoming patches go to, which
would then automatically generate a message to darcs-users (2).  As for (1),
this creates a spam filter problem

Right now, to avoid spam on the tracker we pass bugs@darcs.net through a mailing
list bugs@lists.osuosl.org.  I don't want to create a 3rd mailing list because I
don't want to moderate a 3rd mailing list.  Perhaps I'm resisting the wrong
thing.  It would be nice if patches@darcs.net mail could go to bugs@list... and
somehow when it came back to darcs.net we could tell patches mail apart from
bugs mail, for example by looking at who the message is sent to or the subject.

Just noting progress before I wander off again.

- Have procmail rules to pass patches to roundup mailgw using the patch class
(-C patch)
- Have a fake mailbox to test with
- Procmail complaining about extraneous flags and something else, but seems to
work (my local set of recipes)

Passing the attached mailbox through the roundup mail gateway is problematic
- it works if I explicitly put [patch] in the subject line
- it works (I think) if I pass in -C msg (ie. it creates a new message), but
then again, it also creates a new issue
- if I pass -C patch to roundup-mailgw, I get an email from mailgw, asking the
roundup admin to "fix the incorrect class specified as: patch".  I worked around
this issue by patching roundup (will attach), but now...
- if I pass -C patch to the patched roundup-mailgw, it just goes ahead and
creates a new issue, not a new patch (keep in mind that it clearly knows how to
create a new patch, because it can do so if you explicitly say 'patch' in the
subject line)

Another modification to the mailgw may be in order.  Hopefully it won't be too
involved.

Attachments

• fake-patch-mbox

On Thu, Oct 22, 2009 at 10:00:54 +0000, Eric Kow wrote:
> - incoming email => patch tracker [spam filter problem]

- patches@darcs.net created
- this is effectively just an alias for bugs@darcs.net
- we don't currently use the addresses to distinguish between submissions
- the only way we know if we have a patch (as opposed to an issue) is if
  either the sender users 'darcs send', or starts a message with
  'darcs patch:' or with [patch]

> - patch tracker  => mailing list?

- we now have a reactor that sends a message to darcs-devel upon
  creation of a patch object; this will be flipped over to darcs-users
  soon

> - mailing list back to patch tracker [bcc patches@darcs.net, likely]

bcc patches@darcs.net, I think

> Right now, to avoid spam on the tracker we pass bugs@darcs.net through a mailing
> list bugs@lists.osuosl.org.  I don't want to create a 3rd mailing list because I
> don't want to moderate a 3rd mailing list.  Perhaps I'm resisting the wrong
> thing.  It would be nice if patches@darcs.net mail could go to bugs@list... and
> somehow when it came back to darcs.net we could tell patches mail apart from
> bugs mail, for example by looking at who the message is sent to or the subject.

All this was set up on the OSUOSL end in their relays

I think this means we have a working tracker now and we just need people
to test it.  If it works, I'll flip the default email to
patches@darcs.net

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9

Done.  Sorry for all the noise.