linux-kernel - Re: patch tracking tools (was Re: Maintainer abuse)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20141218132505.GB21344@fam-t430.nay.redhat.com>
Date:	Thu, 18 Dec 2014 21:25:05 +0800
From:	Fam Zheng <famz@...hat.com>
To:	Paolo Bonzini <pbonzini@...hat.com>
Cc:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Borislav Petkov <bp@...en8.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Stefan Hajnoczi <stefanha@...hat.com>
Subject: Re: patch tracking tools (was Re: Maintainer abuse)

On Thu, 12/18 11:14, Paolo Bonzini wrote:
> 
> 
> On 13/12/2014 14:52, One Thousand Gnomes wrote:
> > Is it the year for a Google summer of code project or similar to turn
> > patchwork into a proper patch management tool (one that collects the
> > patches, provides a good maintainer interface, tells people automatically
> > that their patches are queued, deletes repeats, gives them status urls
> > they can give to managers or check, and also has the right bits
> > maintainer side to actually do stuff like send out "your patch set no
> > longer merges, please update" emails, and tell the maintainer if it
> > merges, the coding style important bits, etc and with buttons for "merge
> > me"
> 
> People from the QEMU project are working on something like this.
> 
> Right now the only public tool is "patches", which is a) a server that
> gathers patch series and Reviewed-bys, and detects when they are
> applied; b) a tool to query the list and also apply patches/pull
> requests; c) a notmuch plugin that lets you query the list from Emacs.
> The tool is pretty simple; the server produces a simple JSON file with
> the patches from the last 30 days, the client tools download it and
> operate on a local copy.
> 
> These tools are at https://github.com/stefanha/patches.  A sample
> database is at http://wiki.qemu.org/patches/patches.json (you can play
> with it: "patches fetch http://wiki.qemu.org/patches/patches.json").
> 
> If you want to see how a server is set up, see
> https://github.com/stefanha/qemu-patches.
> 
> Also, we've added a "--message-id" to "git am" in order to help the
> "patches" server detect what was applied.  The client tool already did
> that when applying patches, but the next version of git will let
> submaintainers contribute to the tracking even if they prefer "git am"
> to "patches apply".
> 
> The "patches" tool is operated mostly from the command line.  There is
> also a new tool in the works which scans the mailing list, applies what
> it founds, checks it with checkpatch.pl, and compiles them.  It uses
> Docker to quickly set up a compilation environment (and of course for
> buzzword compliancy).  It also has a web interface that lets you do
> simple searches.
> 
> This is more experimental and does not yet have a public instance
> (source is at https://github.com/famz/patchew).

FWIW, I've just setup an server instance today on a public available VM, which
is starting to subscribe to qemu-devel@...gnu.org and testing the patches:

http://209.132.179.37/

This tool wants to do two things to aid maintainers/reviewers:

1) Reply and complain if coding style violation / broken building / "make check"
failure is seen.

2) Provide an easy to use web interface to query patches.

> 
> One thing that makes automation a bit easier for QEMU is that it does
> not have a merge window; while we do have a central committer that takes
> pull requests, the phases are a bit more traditional (2 month
> development, 2 weeks preparation for freeze, 1 month feature freeze).
> For Linux it would be more important for the tool to know which patches
> are for which tree, possibly based on the destination mailing lists.

Things can be complicated, for example patch series dependencies.  It's a
question to think about whether we need it to be complete or want to keep it
simple.

I think such as a tool has to start as an auxiliary before becoming part of the
process.

Fam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/