getting meta-data out of patchwork

[Finucane, Stephen]

On 23 Mar 09:01, Andy Doan wrote:
> On 03/22/2016 10:41 PM, Jeremy Kerr wrote:
> >Hi Stephen,
> >
> >>Is there anyway to get statistics out of patchwork about how long
> >>patches sit around, reject/accept rates, and patch sizes?
> >
> >There's no exposed interface for stats at present, but if it's a
> >once-off on patchwork.ozlabs.org I'm happy to do a query. For more
> >general stuff, we can certainly looking at adding a report to the
> >patchwork UI.
> >
> >Note that we don't (currently) track 'log' data (ie, when updates
> >actually occurred), so there's no way to tell (for example) if a patch
> >was accepted on the day it came in, or three months later.
> 
> We had a similar thing at Linaro. My solution isn't great, but I
> basically keep a "last_state_change" attribute and then use
> "last_state_change - date" to get time-to-acceptance[1]. This
> doesn't necessarily give a good metric, because its not taking into
> account a patch going through multiple revisions. That, however,
> might be a separate issue to tackle.
> 
> Do you guys think something like a "last_state_change" attribute
> would be worth adding models.Patch?

I like what you've done with that dashboard, and I'd love to see it
hosted/mirrored on 'getpatchwork' as some point as a project within
the patchwork tree, or as a new project like you've done.

I think adding timestamps would be a good first step and explored
this myself a while back [1]. I think we can go much further, however,
and track all state changes. Damien has suggested one approach, but we
want state changes to be tracked in the UI (like Launchpad [2]). IMO,
subclassing "Comment" to reflect state changes seems like a promising
solution. Using the Cover Letter support patches would provide a great
model for how to convert a model into a Base Model for use in concrete
inheritence [3].

In addition, if you go to the admin interface you'll notice a pane on
the right where all recent changes in the database are stored. I don't
know how far back these logs go, but it should be possible to extract
a lot of information from the admin records [4] to populate our
initial records. This should mitigate the issues you've seen with
providing statics, Andy [5].

FYI I've all this information tracked in the issue tracker [6].

Thoughts?
Stephen

[1]: https://github.com/stephenfin/patchwork/commits/feat/timestamped-models
[2]: https://bugs.launchpad.net/nova/+bug/1529534
[3]: https://lists.ozlabs.org/pipermail/patchwork/2016-March/002492.html
[4]: http://stackoverflow.com/q/987669/613428
[5]: https://patches.linaro.org/
[6]: https://github.com/getpatchwork/patchwork/issues/13