statistics from patchworks?

Yann E. MORIN yann.morin.1998 at free.fr
Tue Oct 9 08:12:07 EST 2012


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.

Instead of duplicating the notion of a 'release' (or 'version' or whatever)
to patchwork, it would be nice to:
  - add hooks in Patchwork to call out to some external tools on patch
    change: new patch, state change, delegate change...
  - have documentation for the XMLRPC interface so that external tools
    can query/update the Patchwork instance easily (eg. from a bug-tracker)

Also, such metrics would mean to have a state-flow for patches. Obviously,
all patches start in state New. But:
  - what is a terminal state?
  - what should happen after Under Review? After RFC? After Not Applicable?
  - should Patchwork enforce a state-flow, or should each project use their
    own?

I think each project will have its state-flow, some considering (eg.) Not
Applicable as being a terminal state, while others considering it just a
step before Rejected. Ditto for Superseded, and so on...

For exammple, those two state-flows for Superseded are equally valid:

    New -> RFC -> Changes Requested -> Superseded
    New -> RFC -> Changes Requested -> Superseded -> Rejected

Of course, we could add a single terminal state (for example):

    New -> Accepted -> Closed
    New -> RFC -> Changes Requested -> Superseded -> Closed
    New -> Under Review -> Rejected -> Closed

Unfortunately, I think it mimics too much a bug-tracker, and Patchwork
should strive to keep minimalistic (although with a way for exchanging
with external tools, via hooks and/or XMLRPC).

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'


More information about the Patchwork mailing list