analysis: scaling burndowns for short-term (eg hackathon) vs long-term (eg linux) projects

short-term, eg https://github.com/lunchpals/open-now: <100 commits, across 48 hours
- suitable timescale: every hour
- probably takes negligible amount of time to process
long-term, eg https://github.com/torvalds/linux: >648,000 commits, across >27 years
- suitable timescale: every month or 2 months
- can take over an hour to process (example in https://github.com/src-d/hercules notes a Linux burndown took 1h 40min to generate)

will need to scale timelines dynamically.

[x] implement https://github.com/src-d/hercules/issues/238 (PR at https://github.com/src-d/hercules/pull/245) (pulled in 013252a8976936fc387c9b682be618ecdf8f148c)
[x] project "duration" detection of some sort - ~need to work out how commits are clustered~
- for now, probably just go with the implementation in f22e174 etc - commit cluster detection can come later, if it's actually an issue
[x] update DB to account for potentially volatile timescales

bobheadxi / timelines