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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list