Damien

This is now working for series. It'll be possible with the list of patches once we port that page over to the REST API/new filter framework.

Don't forget to mention the new supervisor/celery/redis trio for background tasks

Part 1 done: http://patchwork.freedesktop.org/patch/msgid/4b5190547226b82cc34ee5250c7949cee8c90f78.1440681672.git.jani.nikula@intel.com and: https://lists.ozlabs.org/pipermail/patchwork/2015-October/001806.html What's left here is the series part. Changing the title accordingly.

That's a question I'm asking people right now

After having talked to Jari, we came up with some ideas to start with: Metrics - number of patches per month/week - number of series per month/week - number of...

I do love the python script idea. If git-pw is already in the path, maybe we could even put that support threre: print the patch/series URL in stdout from am...

Note that is some ambiguity to sending a series as a reply of a previous series. It's currently used in two cases: - A full new revision of the previous...

Absolutely! that's indeed what I had in mind these days, relative dates. As you say though, low priority.

What about using go sub-tests? https://blog.golang.org/subtests (search for "Setup and Tear-down") As for the more friendly asserts, it seems the consensus is https://github.com/stretchr/testify/assert (look at the star numbers!)

Sub-tests aren't a package, just a new method `Run()` on the `t *testing.T` object. One can call a Setup()/TearDown() function around a multitude of t.Run(): subtests sharing the same setup/teardown...