Let's get away from the language debate, and discuss the design and architecture of the code. Maybe the language falls out of that discussion.
=======
Ignoring what currently is implemented in v1 and v2, here is what I care about:
(1) Pulling data down from wherever *exactly once* and storing it in a database forever after that.
(2) The primary feature of the config file is a "list of projects", which represents the projects that EKG will analyze. For each project in the list, the pieces of data that are collected will probably expand over time, so it's important to take this into account when we architect. Maybe we're only starting with mailing lists, but we'll eventually expand to commits, maybe to bugs, etc. Basically I want the program to think of something like Spacewalk not just as the spacewalk mailing list(s), but the various other sources of data that exist.
(3) Having an "update my data" feature that basically looks at the list of projects that EKG cares about, and can say "well, my data on Spacewalk hasn't been updated since January 12th, so let me go get all the new data" or "oVirt has just been added to the list, so let me go and get everything that exists".
(4) Being able to analyze the data in time slices. Monthly, quarterly, and yearly are what interests me most. I'd like to be able to get that either from a calendar point of view (year starts on January 1) or a Red Hat fiscal year point of view (year starts on March 1).
(5) Some use cases:
* There are 100 projects in the database. Show me the report of the last quarter for all of them.
* Here is a list of 10 projects that are most important to Brian Stevens. Show me the breakdown for the last two years, with quarterly deltas.
* Show me all projects where the external mailing list percentage is greater than 50%.
* Show me all the projects where @redhat.com is committing more than 75% of the code.
* Show me the projects where the total volume of mailing list traffic has increased/decreased by more than 25% since the last quarter.