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