Re: patch tracking tools (was Re: Maintainer abuse)
On 18/12/2014 14:25, Fam Zheng wrote: > > 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 we want to keep it simple. Patch series dependencies complicate the job for the maintainer too. Andrea Arcangeli reminded me later of the obvious: for Linux such a tool could simply use the linux-next tree as a base. Paolo -- 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/
Re: patch tracking tools (was Re: Maintainer abuse)
On 18/12/2014 14:25, Fam Zheng wrote: 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 we want to keep it simple. Patch series dependencies complicate the job for the maintainer too. Andrea Arcangeli reminded me later of the obvious: for Linux such a tool could simply use the linux-next tree as a base. Paolo -- 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/
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-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/
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-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/
