[Teammetrics-discuss] Git repositories parsing is ready.

[Andreas Tille]

On Wed, Jul 13, 2011 at 12:11:36PM +0530, Sukhbir Singh wrote:
> > Please rediscuss with alioth admin.  I do not care about the account
> > name (but definitely not my account because my password will not hang
> > around inside those scripts ...
> 
> I have mailed them, let's see. What we need is a read-only account and
> I have requested for that.

I just added some comments
 
> We will have separate tables for Git and SVN. Like for Git, we have
> gitstat in teammetrics. Do you want to make Git and SVN come under one
> table? If yes, then it makes sense to add the VCS column. Otherwise
> when we know the table is for Git commits, it doesn't do any good :-)

Ahh, I was not aware of the plan to have more than one table.  IMHO an
SVN table would have the very same structure and contain the very same
information and finally in the evaluation phase it does not matter
whether a project is using SVN or Git.  So having every VCS in one table
(specifically if we might intend to add other VCSes as well in the far
future) a single table makes more sense to me.
 
> > which are poisoning our statistics.  That might be a problem.  We just
> > want to track only changes in debian/.  Is there any way to separate
> > those changes?  BTW, I was never happy about this policy that Git allows
> 
> Interesting point. I am not sure about this, I will check and then we
> will see what can be done.

Good luck with this IMHO quite important point.  From my point of view
in the results the ball package is totally over-represented compared to
other packages and there are people in who never showed up anywhere at
Debian hosts.  There might be two approaches:

   - verify if the commiter is a member of the team on alioth
     or a debian develper (which have automatic commit permissions
     for instance in blends and debian-med repository
     If it is easier to check it might be sufficient to verify that
     the commiter has an Alioth login at all (even if this does not
     get rid of those changes where upstream and Debian maintainer
     are one and the same person)
   - verify if the change happened in debian/
   - perhaps there is another way:  The commits to the Alioth clone
     are usually triggering an e-mail.  Perhaps there is a chance to
     find out what e-mails were sendet.  Or there is an other way to
     find out what commit was targeting to Alioth first and not pulled
     from a different clone.

Both can be a bit hard to implement.
 
> > You remember my promise that encoding problems will always beat you?
> 
> Hehe, it's good that these came out in the open, I will fix them.

:-)
 
> > adds a really new measure to our research.  So I'm quite happy.
> > Thanks for your effort
> 
> Did I mention that thanks() is a recursive function? ;-)

Not yet. :-)  I suspect we might end up in an infinitive recursion.

Kind regards

      Andreas.
 

-- 
http://fam-tille.de