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-de...@nongnu.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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/