statistics from patchworks?

[Stephen Hemminger]

On Mon, 08 Oct 2012 17:28:59 -0400 (EDT)
David Miller <davem at davemloft.net> wrote:

> From: "Yann E. MORIN" <yann.morin.1998 at free.fr>
> Date: Mon, 8 Oct 2012 23:12:07 +0200
> 
> > David, Stephen, Jeremy, All,
> > 
> > On Monday 08 October 2012 03:57:18 Jeremy Kerr wrote:
> >> > Is it possible to get some statistics out of patchwork
> >> > like:
> >> >   # of patches accepted per release
> >> >   # of days patches reviewed
> >> >   # of patches rejected/superseded etc?
> > [--SNIP--]
> >> Sounds like this might be useful for other folks too. Any general
> >> opinions on which stats would be most relevant?
> > 
> > For what my opinion is worth, I'd say this should not go into Patchwork.
> > I like Patchwork to be a 'dumb' tool that just exposes 'pending' changes
> > not yet acted upon.
> > 
> > To get those statistics would mean that a Patchwork instance be tightly
> > integrated with other project-management tools (eg. redmine, planner,
> > bugzilla...), for which the notions of 'release', 'version'... are more
> > meaningfull, and which already know about the project's workflow.
> 
> Are you kidding me?  We're just asking for some queries into the
> existing database.  That has nothing at all to do with project
> management tools.

What I am looking for is to try and do some queries that will help
with a talk at Linuxcon Europe. These are things that might help
submitters to understand:
  * how long does review process take?
  * how many iterations
  * size of patch vs success rate

There is enough patches going through the flow and the process
is understood enough that some metrics. There are lots of things this
could be used for (good or evil), like convincing managers, users,
and reviewers to do a better job.

The communit (ie netdev and linux-kernel) to get an idea
how are we doing. Are things getting reviewed enough, how fast, what
tends to get not reviewed, and maybe some ideas on how to do better.

If you think of this from a database point of view, it is like looking
at the OLTP versus decision support system. Ideally, there would be some
way to export the transaction log into another database that could
be queried. I imagine that even all of LKML is so tiny in DBMS terms
that even sql-lite could handle it.