Ideas for Patchwork

[Jeremy Kerr]

Hi Don,

> Our current workflow requires us to hold on to a patch for awhile,
> while it goes through the process of getting peer reviewed acks,
> management approval of the bugzilla, and integration testing. 
> Because of this our current scripts use a bunch of meta data to track
> this info.  In addition, management would love to be able to parse
> through all the patches being posted to our internal mailing list to
> get a feel of the queued up patches, what bugzillas are missing, who
> is doing all the work ;-), etc. So having a web interface and a
> database backend makes sense for us (but us kernel hackers are too
> lazy to implement such a thing, hence why I am here).

One feature in the queue is 'tags' for patches. In your case, you have 
have  'management-approved', 'tested', 'peer-reviewed' tags, which you 
can assign/remove from patches where appropriate.

I still need to work out who 'owns' the set of tags, and whether or not 
new tags can be added by users (and if so, whether they are then visible 
to other users too).

> ### Bundle ordering ###
> We hacked up a solution for this that included us using a Django
> keyword 'through' when creating the ManyToMany relation between
> patches and a bundle, like this

I've done most of the work for bundle ordering; I have a similar method 
of implementing it (using the 'through' relation), and a nice drag & 
drop UI on the bundle list. Still a few small details to iron out 
though, and need to get my head around the SQL migration script.

> ### Patch series grouping ###
> We haven't implemented anything, but talked a lot about this.  One
> approach we came up with, but not sure how to implement is creating a
> bundle within a bundle.  Where a particular patch series would be
> contained in one bundle with the patch header containing the overall
> status of the series.  Then the 'queued up' patch bundle could point
> to that particular series bundle from the web view or when you
> download or such.  This would allow us to modularize things better.

Not sure I understand what you're trying to do here - using a bundle to 
hold a single series of patches (eg 1/3, 2/3 and 3/3), then using a 
bundle to collect those series?

> ### ability to update some meta info on the patch ###
>
> We were trying to figure out within the constraints of the patchwork
> framework, what the appropriate way to update some meta fields were
> while still retaining the ability to download the original email (for
> review purposes).

I think it'd be ok to allow the patch's metadata to be updated - we 
still have a copy of the original headers if needs be.

However, this could make it hard to correlate patches between the 
mailing list and the patchwork list.

What kind of metadata changes are you thinking about here?

> And to expand the idea further, one can then envision setting up
> _stub_ Comment blocks to reflect changes that were done by the
> maintainer (that doesn't necessarily need to be reflected back on the
> mailing list).

We could keep a 'history' of the patch, separate from the comments. I 
think this would be a good idea, but requires a reasonable amount of 
work - we have to change most of the modification code to record a log 
item for each change.

> In addition, we wanted to solve dealing with reposted patches by
> pointing the old patch to the new patch.

Another item on the TODO list: keeping 'relations' between patches. For 
example:

 * patch A is a followup to patch B
 * patch A replaces patch B
 * patch A is in the same series as patch B

> Which leads me to one more trick.  Because we wanted to link patches
> and the history together (either through a reposted patch,
> malformated thread, etc) and still view a full mbox of the bundle, we
> needed a way to connect those threads together without losing that
> information in our mailer.  We noticed mutt does this by modifying
> the 'In-reply-To' field.  So our trick would be to add a field to the
> Comment class, in-reply-to, that would override the original thread's
> in-reply-to, if need be, to link various disjoint threads together.

We may have already lost the mail though (eg, if we couldn't find any 
related patch on the first parse).

Cheers,

Jeremy