On Mon, 08 Oct 2012 17:28:59 -0400 (EDT) David Miller <[email protected]> wrote:
> From: "Yann E. MORIN" <[email protected]> > 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. _______________________________________________ Patchwork mailing list [email protected] https://lists.ozlabs.org/listinfo/patchwork
