Forum Posts

Any news on this? It's now possible to ignore directories, but that really doesn't fix the issue (I'd like to exclude some generated Unicode CLDR data in XML format that we ship with, but I can't do ... [More] it for every branch...) Basically, it would be nice if Ohloh simply counted activity across a whole repository, and then, people could define a subdirectory of that repository to be taken for the "how much of each language, how many lines of code, ..." metric. Otherwise, too much stuff is counted several times. [Less]

Hi Robin, thanks for your quick reply! I deleted the enlistment, but the problem is that the summary, metrics etc won't disappear - at least they didn't last time. Hence my question if you could ... [More] remove those by hand as it was done back when I had the same problem (see the thread link). Hope that clears it up a bit! Thanks so much, David [Less]

A user added our SVN trunk again, and now summary info is back with "decreasing year-over-year development activity" etc since we develop mostly in version branches. Project ID is "agavi". Sorry for ... [More] bothering you with this again. Andy was kind enough to go ahead and flush the info last time ( http://www.ohloh.net/forums/10/topics/1096 ). Btw... is there any news on the separation of activity statistics and metrics? I noticed it wasn't on the list of GSoC ideas. [Less]

Okay, then I think it's fine if you go ahead and remove the report. I just hope nobody else adds an enlistement soon afterwards or I need to bother you guys again. Any idea when a new system for this ... [More] is implemented? I once proposed that activity is measured using an entire repos (or parts of it), and then one would add a separate, dedicated repository path just for the code metrics. [Less]

The coding experience does not worry me, but the kudos... hm. I have fewer kudos than the project has stacks, though. How does that work exactly? And isn't that stuff added again when I add enlistements back in?

Can you please fix this for project 5907. It's just so annoying to see nonsense like "decreasing development activity" etc there, just because ohloh's measurement approach is so horribly broken and ... [More] cannot work on a complete repository. Sorry for being bitter, but this hurts projects. Especially with your comparison feature. Before you do that, you really should get a proper foundation done that allows fair comparisons. That includes giving the option to exclude certain paths from the metrics (say, generated XML data or vendor libraries or whatever). Would that be possible, please? I'd really much rather have no statistics than completely wrong statistics. Thanks. [Less]

Yeah sure, I understand that suggestion, but it doesn't help projects who develop in branches a lot ;)

They can't :( See http://www.ohloh.net/forums/8/topics/385

Any news here? Ohloh team? I'd really love to hear some feedback on this. Such a functionality is now getting really important as you added the project comparison tool recently. But the comparison ... [More] simply is not fair as it does not measure activity or contributor count correctly. Please with a cherry on top at least tell us you're considering it, or if not, why not. Thanks a lot for an otherwise cool service. -David [Less]

Hi folks, as we all know, a lot of projects have incorrect activity ratings because they develop primarily in branches, for instance. But if a whole repository is added, the codebase analysis will be ... [More] totally wrong, as the same code is counted multiple times. This affects Agavi ( http://www.ohloh.net/projects/5907 ), for instance, where for months development has been done in a branch, and a lot of contributors aren't listed or listed incorrectly due to measurements being pulled from trunk. So what about splitting up the two? Let people define one or more repositories that are used to measure activity, show commit history etc, and one path in one repository that is used to analyze the codebase, LOC, total cost etc. Does that sound reasonable? Oh and maybe give the ability to exclude parts of the project from the codebase analysis, so third-party stuff does not get taken into account. But if you add that feature, give projects that do so a "badge of honesty" or so ;) [Less]