[libvirt] Publishing libvirt 'patches' JSON database?

[Kashyap Chamarthy]

On Wed, Mar 23, 2016 at 12:09:29PM -0400, Cole Robinson wrote:
> On 03/23/2016 11:34 AM, Kashyap Chamarthy wrote:
> > I'd imagine most developers on this list have their own workflows to
> > track/apply/test patches from the mailing list.  I normally just save
> > patches in Mutt's Maildir and apply them manually to a Git branch.  I
> > recently began using the 'patches'[1] tool, that some of you on this
> > list must be familiar with, to test arbitrary QEMU patches from the
> > mailing list, and found it relatively easy large patch series from
> > mailing list.

s/easy/easy to test/

> > I'm writing this to check if the libvirt upstream community finds it
> > desirable to setup such a patches database.
> > 
> 
> I haven't played much with 'patches' so I can't give a first hand
> opinion. But if it's low effort to set up and maintain seems like a
> no-brainer to generate and publish the metadata so libvirt devs can
> start playing with it.

I haven't set up the database myself, I'm afraid.  From my quick look at
patches/patchlib/scan.py, it uses a `notmuch` database (an .xz
conpressed file), and I just need to have a config file.  I use
`notmuch`[*] for email indexing sometimes, so I can try to play with
this and setup a database.

I was just a bit hesitant to start as I'll be away on leave for 2 weeks
starting this weekend.  Still, I'll try to see if I can squeeze this
task in before I leave, since I brought it up.

> Although your details don't cover it, one of the major benefits of
> 'patches' is that it also scoops up metadata like Reviewed-by:, and
> gives an easy way to get those tags into commit messages. Good for
> giving prolific reviewers credit (and shaming those that don't do
> enough reviews :) ).

:-) Understood.  You can see the kind of prefixes it supports in the
README.md.

> The corollary is that you can search for unreviewed series, which IMO
> is desperately needed for libvir-list; the review time is pretty bad
> and I can't begin to count the number of drive-by patches we've
> received on list over the years that go completely unresponded. And I
> say this knowing full well I probably have the worst
> review-to-patches-authored ratio of all libvirt committers... but I
> don't live on libvir-list and often go 3-6 months at a time where I
> don't have any libvirt patches, and usually during those times I just
> skim-and-archive the list contents. If we had a programmatic tool to
> show me the unreviewed patches, 

It shows something closer to unreviewed patches, looking at the terms
supported by its query language (using `notmuch`; see the "Search
Language" section in README.md):

    [...]
    - `status:rfc` show RFC postings
    - `status:committed` show committed series
    - `status:applied` show series with a "Thanks, applied" reply
    - `status:unapplied` short hand for `not (status:broken or status:obsolete or status:pull-request or status:rfc or status:committed or status:applied)`
    [...]
    - `status:reviewed` show series where every patch has at least one Reviewed-by
    - `reviewed-by:ADDRESS` show series if a patch has a Reviewed-by by `ADDRESS`

> I could run that on occasion and pitch
> in much more easily, at least reviewing bits that don't need a lot of
> context. We could even have an informal policy like 'theres XXX number
> of unreviewed patches on the list... no @redhat people post patches
> until we review the backlog'
> 
> What if a patch series is NACKd or abandoned, is there a way to get it
> out of the patches metadata?

Seems like NACKed patches are displayed (I don't find any search term
for "abandoned") can be fished out of the repo:

    [...]  # I snipped out some of prefixes
    - `nacked-by:ADDRESS` show series if a patch has a Nacked-by by `ADDRESS`
    - `acked-by:ADDRESS` show series if a patch has a Acked-by by `ADDRESS`


[*] https://notmuchmail.org/


-- 
/kashyap