On Wed, 11 Feb 2009, Max Spevack wrote:
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).
Well, the goals and deadlines that the CommArch team is operating under demand that progress be made, in particular on the enhancements and new features around the time slicing, and it is those features that have triggered the larger architectural discussion.
Yaakov, I'd like to see from you, preferably before Wednesday night EST (because I need it for a meeting that I have on Thursday), your development roadmap for the rest of February and as far into March as you can give.
Be relatively detailed about the technical stuff -- even if some of it goes over my head, some of the real programmers on the list will understand it, and I know more than I let on. :)
Thanks, Max