[Teammetrics-discuss] Some quirks I detected in teammetrics

[Sukhbir Singh]

Hi Andreas,

Andreas Tille wrote:

> teammetrics=# SELECT DISTINCT name from listarchives where project = 'neurodebian-devel' and name like '%Yar%' ;
>          name         
> ----------------------
>  Yaroslav Halchenko
>  'Yaroslav Halchenko'
> (2 rows)
> 
> 
> I remember we did some "antoi-quoting" means but these are obviously not
> sufficient.

I think we took care of it for future runs, but the names already in the
database won't be affected unless we fix them within the database
itself. So I guess I will just run an update query manually.

> 2. Commits of Blends team is not calculated
> -------------------------------------------
> 
> No idea why we initially did not measured this team and I tried to fix
> this by
> 
> $ git diff
> diff --git a/etc/teammetrics/commitinfo.conf b/etc/teammetrics/commitinfo.conf
> index bc16af0..c4aca7e 100644
> --- a/etc/teammetrics/commitinfo.conf
> +++ b/etc/teammetrics/commitinfo.conf
> @@ -22,12 +22,12 @@ team =  pkg-multimedia
>          pkg-games
>  
>  [technical]
> -team =  d-i
> +team =  blends
> +        d-i
>          debian-desktop
>          debian-l10n
>          debtags
>          fai
> 
> 
> which had no effect.  May be it is called differently?  It should
> contain SVN *and* Git data.

Surprising. It should work. I will check.

> 3. Missing debian-custom list (solved!)
> ---------------------------------------
> 
> The reason why I started investigating was that debian-blends stats
> looked a bit poor which was caused by the fact that the list
> debian-custom (as it was formerly named) was missing.  I circumvented
> this by (temporarily ?) using
> 
> $ git diff
> diff --git a/etc/teammetrics/listinfo.conf b/etc/teammetrics/listinfo.conf
> index 5309e90..fef5d37 100644
> --- a/etc/teammetrics/listinfo.conf
> +++ b/etc/teammetrics/listinfo.conf
> @@ -25,6 +25,7 @@ lists = debian-accessibility
>          debian-amd64
>          debian-arm
>          debian-blends
> +        debian-custom
>          debian-boot
>          debian-ctte
>          debian-curiosa
> @@ -75,13 +76,3 @@ lists = debian-accessibility
>          debian-women
>          debian-www
>          debian-x
> 
> 
> I'm not really sure why these data were lost because I'm pretty sure I
> included this when I regenerated the database on the new host.  It would
> be good to know *why* these data went away to make sure it does not
> happen again.

So is this solved as you said?

> 4. Name fixing might not work reliable
> --------------------------------------
> 
> When looking at authorstat_debian-blends_year.txt you see a column
> 
>    Vagrant_C  and
>    vagrant at freegeek.org
> 
> Both should be normalised via
> 
>    Vagrant Cascadian               :           %vagrant%
> 
> in names.list - but for some reason they are not.  I have no idea why
> this does not work here.

I will check this also.


> PS: BTW, the DNS service on blends.d.n is somehow broken - I have no
>     idea why but I added the most important hosts to /etc/hosts to
>     be able to run the stats.  That's a bit boring problem which I
>     was not able to solve (/etc/resolv.conf has a bunch of pingable
>     DNS servers meanwhile).  If you have any idea about this - I'd
>     be interested.


I have no idea about such things and I think you must have looked
everything I can, but if you need an extra pair of eyes to go through
it, then I will do it :)

Which brings me to the main thing that before I can check anything, I
should be able to SSH into blends, which is not working.

$ ssh -vvvv sukhbir at 87.98.215.146
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received

(stops here)

On Googling this, I think there is some issue with the sshd. Can you
please check why this is so?

> I was running update-names.py manually and after this 1. and 4. below
> are gone.  Seems the usual import process is not triggering
> update-names.py even if it should.

I removed that on purpose because there was no sense running it again
each time we called a particular script. So in the script I wrote and
added to the cron, it is just called once before generating the graphs
:)

-- 
Sukhbir