[Teammetrics-discuss] Updating commitstats

Andreas Tille andreas at an3as.eu
Tue Apr 16 12:06:12 UTC 2013


Hi Sukhbir,

On Sat, Apr 13, 2013 at 07:47:13PM -0400, Sukhbir Singh wrote:
> Yes, this is expected because of the kernel repository :(

Hmmmm.
 
> The problem is, that the repository is so big that commitstat.py hangs
> in between and doesn't go further.

I have not spend time to check this code but in any case we need to find
a solution to somehow handle large repositories.

> I have tried to debug this and to
> optimize it so that it works, but I was not successful. Initially, I
> thought that this issue was limited to the first-run but I found it to
> be there on subsequent runs also.
> 
> For now, I recommend that we run it removing the kernel repository.

This is what I did but as I wrote in another mail we are missing

SELECT * from commitstat where project in ('debconf-video', 'debian-desktop', 'debichem', 'fai', 'pkg-kolab', 'pkg-mc', 'pkg-mono', 'pkg-ocaml-maint', 'publicity', 'python-apps', 'python-modules', 'soc');      

The old server contained data for these projects.

> I
> will look into this again, but I don't think we can make much progress
> given how our "architecture" is.

???
 
> Should I run it? Where do I put graphs after generating them (given the
> new VM)?

The new VM has the very same directory structure as the old one and I
moved all graphs I generated in an initial run to

   /var/lib/gforge/chroot/home/groups/blends/htdocs/liststats

so for the moment at least "some" graphs are there.

BTW, I have kept a DB dump from the old host that we could use as
initial state as well but I would really prefer if our algorithm
would be stable enouth to always work from an empty database.

Kind regards

    Andreas.

-- 
http://fam-tille.de



More information about the Teammetrics-discuss mailing list