[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