statistics from patchworks?

[Yann E. MORIN]

David, All,

On Monday 08 October 2012 23:28:59 David Miller wrote:
> From: "Yann E. MORIN" <yann.morin.1998 at free.fr>
> > 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.

Sorry, but I was serious. But let me re-phrase, as I was maybe not very
explicit in my explanations (which is probably very true ;-) )

It is my understanding (from Jeremy's mail) that patchwork currently:
  - does not have a time-stamped history of patches (state change, delegate
    change...)
  - does not have a notion of 'release'

Hence, not all the queries you need can not be fulfilled with the existing
Patchwork DB.


Now, I was only replying to Jeremy's question:

> Sounds like this might be useful for other folks too. Any general
> opinions on which stats would be most relevant?

The only point that makes sense is the second one: the time it takes for
a patch to get from New to a 'terminal state' (whatever that means for
each project).

Of course point three is already possible (not taking into account the
'between any two releases' semantic):
    $ pwclient list -p crosstool-ng |tail -n +3 \
      |awk '{ nb[$2] += 1; }
            END { for( s in nb ) { printf( "%s: %d\n", s, nb[s] ); } }'
    Accepted: 16
    Superseded: 5
    Rejected: 3
    RFC: 1
    New: 10

For the point one, how can we query from the Patchwork's database the
number of patches between release X and release Y, if Patchwork does not
have a 'notion' of 'release' ? Even if a time-stamped history of patches
were available, basing the decision on the date would not be very reliable.

Counting patches applied for a 'release' is easily undestood: they have
been commited to the repository.
But then, how would you consider the number of patches rejected per 'release'?
What if a patch was submitted before a 'release', but rejected after: would
it be accounted for in the next release, or the previous one? Ditto the other
states...


It is my opinion that:
  - adding the time-stamped history could be usefull,
  - adding the notion of 'release' would not; see below.


The notion of 'release' is not as simple as "this is version X, and this is
version Y, and version Y comes after version X". For example, this (very
simple!) release graph (time flows from left to right, each letter is a
'release'):

  ---A---B-------D-------G---------->
          \       \
           \       `-------------J-->
            \                   /
             `-C----E--F----H--´
                     \
                      `--------I---->

Any patch from Patchwork can be applied in-between any two letters, but may
also be applied more than once. For example, a patch can be applied between
D and G, between E and I, and between F and H.

To get the number of patches applied between any two releases, the Patchwork
DB would have to keep track of which 'branches' a patch was applied to, and
which 'branch' a 'release' was cut from. So, we'd need a notion of 'release',
but also the notion of 'branch', and of 'release' on a 'branch'. And then,
the Patchwork DB would also have to keep track of the many 'commit-ref' per
patch.

That would, IMVHO, make for a complex addition to Patchwork.

OTOH, project management tools already handle such complex stuff, and I
believe tracking patches applied on a project is better suited in such a
tool, rather than in Patchwork itself.

IMVHO, Patchwork should stay the simple tool it currently is.

Now, that was only my point of view. Maybe I misunderstood the original
request; and maybe I am talking with my ass, in which case I'm sorry for
the noise... ;-)

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.  |
'------------------------------^-------^------------------^--------------------'