Re: [libvirt] Publishing libvirt 'patches' JSON database?
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