GNUstep status not updated for over a year.

Avatar

David Chisnall

4 days ago

The Ohloh stats for GNUstep show that it has not been updated for over a year, while the latest svn activity was about half an hour ago (see http://cia.vc/stats/project/gnustep). The metrics also seem wrong, for example claiming that it is mostly written in C when it is 90%+ Objective-C.

User widgets also don't seem to be being updated; mine still says 576 commits while my user page says Ohloh has tracked 831 commits by me...


Avatar

Robin Luckey

3 days ago

Hi David,

It looks like we have been trying to track the following URLs, but it seems that they no longer exist:

http://svn.gna.org/svn/gnustep/tests/gtests/trunk
http://svn.gna.org/svn/gnustep/libs/db/trunk

I've removed these URLs from the enlistments page.

I've scheduled a new update and I'll keep an eye on it.

Thanks, Robin


Avatar

Robin Luckey

3 days ago

BTW if the language metrics do not correct themselves after the update, we can schedule a clean recount, which sometimes fixes the issue. If not, I will dig into the problem.


Avatar

David Chisnall

2 days ago

It's a little bit better, but now it's claiming the last commit was six months ago. Are there any other problems?


Avatar

David Chisnall

1 day ago

Thanks, now it's picked up all of the commits. The language metrics still look wrong though. It lists 48% C, 30% Objective-C, 13% Autoconf. I'd be very surprised if the code is 13% autoconf and given that almost all of it is Objective-C I'm also surprised that it's listing C instead of Objective-C as the majority.


Avatar

David Chisnall

1 day ago

In fact, the autoconf numbers are total nonsense. It thinks I've changed 18,651 lines of autoconf code in a single commit for GNUstep when, in fact, I have never touched autoconf...


Avatar

Robin Luckey

1 day ago

Hi David,

There's a bit of a needle-in-a-haystack problem here because the code from so many repositories is being combined into a single total.

We now have all of the commits, but I haven't run the full recount yet. That will take several days to complete.

Can you give me a pointer to the commit which contains all of the erroneous autoconf? I will take a look and see if I can find a bug in our counter before starting the full recount.

Thanks, Robin


Avatar

David Chisnall

about 7 hours ago

Your UI doesn't seem to let me know which commit your information is coming from and, given that I have never written any autoconf code, I can't tell you which of my commits contains autoconf code (because none of them do). That said, you're only tracking 23 commits by me related to GNUstep, and between them they (apparently) cover 18,651 lines of autoconf stuff, so that should help you narrow it down a bit...


Avatar

Robin Luckey

about 6 hours ago

Hi David,

Sorry, I thought from your post that you actually had seen the specific commit. I did some digging and came up with this:

svn log --verbose -r28730 http://svn.gna.org/svn/gnustep/libs/base/trunk@28730

Which is visible on Ohloh here.

This commit does indeed contain a lot of autoconf changes, but from reading the comment it looks like you made the change on behalf of someone else.


Avatar

David Chisnall

about 3 hours ago

Ah, I see. The configure and config.in files are both auto-generated. The actual change was one line in configure.ac. If the code metrics are counting every addition to the configure file as an addition then that's going to be skewing the statistics quite a lot...

In the latest checkout there are about 32KLOC in config*, but only about 2KLOC of these are human-edited, the rest are generated by autoconf. Ideally, Ohloh should only be counting the human-edited version in the statistics.

In the same checkout, there are 175KLOC of Objective-C, so the ratio of autoconf to Objective-C is quite inaccurate, even if you are counting the machine-generated autoconf instead of the source files.