Implement CVS sparklines for project pages
Gerhard Killesreiter - February 10, 2009 - 09:13
| Project: | CVS integration |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
| Issue tags: | download & extend, drupal.org redesign, sparkline |
Description
see http://infrastructure.drupal.org/drupal.org-style-guide/prototype/core.html
http://infrastructure.drupal.org/drupal.org-style-guide/prototype/module...
The module version has a distinction between maintainer and other commits, which I think is rather pointless.
The core version has a link to "full project timeline", I guess this would be a full version of the graph similar to the ones produced by cvsmonitor.pl.
#1
The sparkline listed in the mockup isn't particularly self-documenting or illuminating. I think the following would be more useful:
A) "CVS commits" -- number of commits to the project per week
B) "CVS lines added" -- number of lines of code added to the project per week
C) "CVS lines removed" -- number of lines of code removed from the project per week
Ideally, B and C would be merged into a single sparkline, with the bar above for lines added, and the bar below for lines removed. Unfortunately, I haven't seen any sparkline libraries that support this sort of thing with 2 y values per x value. So, we might have to keep them as separate graphs for phase 0.
It's a *shame* to be adding this stuff directly to cvs.module instead of versioncontrol API, but I'm not sure there's much we can do about that in the short term...
Also, in discussion with Mark Boulton in DC, he's ok with me "going nuts" with a few other useful sparklines, so you can really visualize the health of the project at a glance. We'll be working on this stuff at the d.o redesign sprint this week in SF, so I'm going to be tagging other issues with "sparkline", see http://drupal.org/project/issues/search?issue_tags=sparkline for the growing list.
#2
eheh... sorry, I'm still stuck in work until mid May so I haven't been able to do the last mile push. Maybe you could develop cvs.module and Version Control API implementations in parallel? :P
#3
"eheh... sorry, I'm still stuck in work until mid May so I haven't been able to do the last mile push."
No worries, I totally understand.
"Maybe you could develop cvs.module and Version Control API implementations in parallel? :P"
Fat chance, sorry. ;) I'm already way too overcommitted as it is, I can't do double duty on features like this, at least not in the short term during the sprint this week.
Thanks for caring, though. ;)
Cheers,
-Derek
#4
Here is an untested patch for implementing this on project pages. I *think* it will work, but I don't have any CVS module tables to test with. At the least, it's a good example of actually creating a sparkline. As the sparkline module automatically caches images, whatever code is implemented will need to check if the image exists (and isn't stale), or it will need to be moved to a cron job to regenerate the images.
When using the Sparkline module, be sure to check out HEAD as the -dev release for Drupal 6 is from a different tab.
#5
I think we want a standard way of collecting data from project module and other sources. It should be a separate module so project* stays relatively lightweight and other modules can produce sparklines. There are two in-progress modules to do just this.
Community Analytics is a Summer of Code project. It looks quite incomplete at this point; the schedule is "pencils down" in mid-August. I am guessing Damien's original proposal was tailored to Drupal.org's use case.
Stats looks like a complete, but new, system. It was built by Gravitek Labs for a large network of sites.
Both seem somewhat similar, so what works best for Drupal.org?