Port issue metric sparklines in statistics block on project pages to D7

Drat. The commit (5b125242d) for #1556468: Visualize project issue metrics on project pages was never merged to D7, much less ported. I don't have time to drive this home right now, but that's what happened.

Makes me wonder what else has been committed to the 6.x-1.x branch that wasn't merged to 7.x-2.x. Unsurprisingly, a trial merge is full of conflicts and painful. So, for this issue, we probably want to cherry pick 5b125242d into 7.x-2.x and go from there...

see also #1998410: Review commits on 6.x-1.x since 7.x-2.x was branched to find regressions

Whoops, I thought this was already done, but apparently not:
#1770356: Port views_sparkline to D7

That's step 0 for this...

Unless the flot_views module from Flot makes views_sparkline obsolete... Requires more investigation.

Okay. Perhaps some volunteers will step up to get views_sparkline working in D7, and/or drive the rest of this home.

A couple of options for this in D7:

• Use charts_graphs, views_charts and charts_graphs_flot. Pro: General tools can probably be maintained without d.o efforts. Con: More modules.
• Use flot_views. Pro: Less modules, hopefully enough functionality. Con: TBD? (notice charts_graphs_flot anyway depends on flot module). Sounds like the best idea.

I don't know the details, but I believe views_sparklines did some things that made it particularly well-suited for pulling the data out of Sampler API...

Before we commit to another approach here, we need to make sure whatever it is can deal with Sampler API as the data source. It's still all views, so probably it'd be fine, but sadly most of this stuff was hunmonk's baby and he's since left the community... Mikey_p wrote the sparkline integration, so hopefully he could clarify.

Thanks,
-Derek

I'm totally open to using something else instead of views_sparkline. At the time the other charting solutions didn't seem to expose sufficient flot options for generating spark lines, and they didn't seems to like the way that sampler stores it's data (no aggregation, fast queries, it could need front padding, etc)

However, I'm planning to go ahead and commit marvil07's patch and open the D7 branch.

If there's a test site with the D7 version of Sampler running, I'd be willing to test and wrap up any remaining issues with views_sparkline.

The sparklines were really helpful for a quick estimation of a project's activity: how the issue queue activity is over time and so on.

This is needed for #2200813: Add an "average time for an issue to receive a response" metric.

Some basic work has been done on the metrics in D7, but they have had little QA since they are not visible.

Sampler's nodes, comments, and users; and project_release's new_releases metrics are running. project_issue's new_issues_comments_by_project OOMs while loading an entity. We need to find the code path used, and remove static caching.

I've been chipping away at this. #2210709: Populate DB storage by key instead of sequentially is causing the cron job to error out at the moment.

The metrics are now gathered and stored successfully. The next step is to graph them, and make sure they make sense.

Great to see there is progress on this! Thanks Neil!

Since #1770356: Port views_sparkline to D7 isn't done, I took a look around for what else is available.

https://drupal.org/project/d3 has a Views integration module built in. I was able to get a line graph working. Based on that, I simplified to a sparkline, https://drupal.org/project/d3_sparkline.

Since D3 uses SVG instead of canvas, the graphs look crisp on high-resolution devices. As far as I know, D3 is more flexible and has a more active community than Flot.

Great move, I've been using D3 more, and was planning on re-writing views_sparkline with D3 anyway.

I compared re-calculated numbers for August with what production has from pre-D7.

• new_issues_comments_by_project looks good. Comments are higher, consistent with the auto-generated comments added for the migration.
• opened_vs_closed_by_category has the same numbers every week.
• reporters_participants_by_project looks good. Participants are slightly higher, also explained by auto-generated comments.

opened_vs_closed_by_category does have a historical option. That could need manual enabling for recalculation.

The participants graph is now deployed on Drupal.org.

reporters_participants_by_project's data has been recalculated on production too.

opened_vs_closed_by_category has been cleaned up quite a bit, but still has the same numbers every week.

Definite progress. Thanks @drumm for making this happen.

However I've looked at the top 25 projects on Drupal.org and I still don't get it. Are the sparklines marking two years worth of data on the number of participants? It's unclear. It would also be good if it lined up, but that should be a trivial fix.

These should be useful to give us a sense of he health of a given project. I'm not sure that they do right now.

If we're tracking open bugs we want those numbers to go down. If we're talking number of participants in the issue queue than we need those numbers to go up. Would be nice if you clicked on the graph and got more detail.

Anyways, great to see this coming along. Know it's a lot of work.

The last commit includes the remaining 2 sparklines. On Drupal.org, all metrics are working and have been recalculated.

Now deployed.

Each sparkline is rendered twice. Tiny, annoying bug? :)

I'm not seeing that. What browser/OS?

Broken on my Mac:

• Chrome Version 36.0.1962.0 canary
• FF 29.0

Works fine on Safari & Opera.

I tried FF 29.0 & use Chrome 34.0.1847.131 on OSX. I can't reproduce this, logged in or out.

This is caused by a bug in the D3 Drupal module, which happens to be surfaced only dreditor at the moment. #2255069: Only run attach behavior once (and general cleanup)