Ideas for Patchwork

[Don Zickus]

On Wed, Feb 04, 2009 at 09:48:23AM +1100, Jeremy Kerr wrote:
> 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.

Interesting.  How would you handle failure cases?  For example, to
differentiate between something that _was_ tested but failed and something
that _was not_ tested.  Another tag?

> 
> 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).

I would assume the maintainer (and anyone else who has permission to
modify things in the project) would own the tag and they would be made
visible for others to see where their patch is in the queue.

> 
> > ### 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.

Cool!  Yeah, I can't imagine a migration script being very fun.
I am willing to test and provide feedback whenever you think it is ready.

> 
> > ### 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?

Yeah, sort of.  Currently, I think people use a bundle to hold a
collection of patches.  If inside that collection of patches is a series
of patches, it would be nice to be able to make sure they are committed as
one group, hence turning the particular patch series into a bundle or
something.  It was just an idea to convert a patch series into a group (or
bundle) that needed special attention.

> 
> > ### 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?

I think I confused you.  The metadata I was implying had nothing to do
with mail headers.  Instead it was something like Bugzilla number and
status (management approval is handled in the bugzilla), peer-review
status (and comments for why it is being held up), CVE numbers if the
patch warranted it.  Stuff like that.

> 
> > 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

Right.

> 
> > 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).

I think you assume this would be automated.  :-)  Most of the time it
can't, which is why we had every intention of creating an xmlrpc command
that would manually link patches together.

If maintainers are going out of their way to use the 'SUPERCEDED' status,
you might as well tell patchwork what patch superceded it.  Which usually
has to be done by hand.  I was just trying to put in a hook that could be
used to store the particular information.

Cheers,
Don