Howdy Robin! Actually, I noticed about a week ago right after you'd started that all the stats were updated! I seem to find myself visiting the site for various statistics more and more frequently. ... [More] Needless to say, I was quite delighted. The stats for BRL-CAD look much better now.. THANK YOU so much for all your hard work on running the update. Comparing the final ohloh user stats that you pulled with the stats that I extracted, the numbers were very close.. They weren't matching, though, as I would have expected for at least the older devs that are no longer active so I dug deeper. Fortunately when I did, though, I was able to account for all of the differences and got exactly the same counts for all the devs I compared. The difference was that my stats collapsed all identical consecutive log messages contrary to ohloh's (better) time-based collapse. Once I took that into account, the numbers matched up. From a larger sanity check standpoint, I counted 25836 unique commits where ohloh has 26554 identified, which is pretty much what I would expect given the time-based culling differences. Another sanity check was to look at the year's contribution of the developers (which started this whole inquiry), which also seems much more reasonable now. Thank you again for putting the effort into this and getting the update rolled in. If there is a "donate now" button or other means to convey my gratitude and appreciation, please let me know. Cheers! Sean [Less]

BZFlag migrated from CVS to SVN on sourceforge, so we removed the existing CVS enlistment and added our SVN enlistment a few months ago. To date, the enlistment has still not completed and I'm just ... [More] now getting around to making this request to give it a kick. I remember there being a thread many months about having to manually accept sf https svn certificates manually, but of course dont' know if that's still an issue or if it's simply because the original enlistment failed and it's just been stuck ever since. We would, however, really like to see the stats back in sync. BZFlag's enlistment is at http://www.ohloh.net/projects/189/enlistments. As always, thank you very much for your help and for providing such a great resource to the community! Cheers! Sean [Less]

For what it's worth, I looked back through several years of Bison revision history as my project has the same issue with the GPL detections. I couldn't get all the way back to the original as their ... [More] savannah repo only goes back two years, but I did find other sources through searches that go back several more years on top that indicate that GPL statement has been in there for quite a while. Whether it's "absolute" probably remains to be seen but it does seem to be a pretty safe assumption. Why they bother to list the GPL at all is probably because that template file itself that Bison uses is covered by the GPL, they just provide their exception so that Bison's derivative is separate. There could conceivably be other ways to derive from or otherwise use that template that would remain under the terms of the GPL. They all seem to start off saying "As a special exception" and end up saying "This special exception was added" though the statement and paragraph that follows each has been tweaked at least a couple times. Cheers! Sean [Less]

Hi Robin! Thanks for the info and the reply. It's great to hear that the feature/change will eventually happen and understandable how you need to plan for it. Sounds like I just need to get out of ... [More] your way now and stop slowing you down. :-) Cheers! Sean [Less]

First off, wanted to say that I'm delighted to see the new username aliasing feature. Nice work, great interface, good stuff. That was probably our #3 ohloh gripe, with #1 being listed below and #2 ... [More] sounds like is under development (ignoring dirs). :-) On to the main point, I was wondering if there has been any additional thoughts or considerations put in to having Ohloh process all RCS revisions on HEAD instead of just the latest. This is a follow-up to the discussion held a month ago over here. Basically, it boiled down to using: cvs log -b -r1: Especially significant for older projects, this captures HEAD activity comprehensively and shouldn't affect statistics for the majority of codes that have never changed their revision number. It would, however, resolve our particular activity discrepancy and contribution statistics. Thanks again for fighting the good fight, implementing good code and for providing a great overview interface with useful statistics. Cheers! Sean BRL-CAD [Less]

As for your other comments, I think the hash idea is pretty innovative, but perhaps also rather problematic/limited as that only captures pure movements and not necessarily renames (since a file ... [More] rename might cause a couple lines in the file to be updated with the new name or path). A thought -- you could probably do some sort of time-sensitive diff match, e.g. if the contents of a file that was deleted match within some %% (e.g. 95%) of those in another file being added within the same ## hours (e.g. 24 hours), then treat them as being probably a moved and/or renamed file. Then it'd just be a matter of fine tuning the %% and ## to not have false positives. Might need the files to also have some minimum line count so you don't match pretty empty files being moved around too, but seems easy enough to tweak into something useful... Cheers! [Less]

Robin, AHA!.. that explains a lot .. and no need to apologize. I'm sure there are constant fires that need to be put out on top of all of this trouble-shooting, support, all while actually trying to ... [More] still provide new and improved features. The detailed response is, however, incredibly appreciated and I think will actually be rather enlightening to both of us for several reasons. I should have thought to check if you were using cvs log -b myself -- t'was an oversight as we actually rarely use branches for active development. What it did unveil, however, is what could be construed as a bug with "cvs log -b" or at least a somewhat unexpected and probably undesirable behavior. To put it in other terms "I don't think that means what you think it means." .. to explain .. The -b option provides information about the latest revision on the default branch. Most projects only have one revision (numbered 1) and the default branch is of course usually HEAD. More to the point, if you have a project that utilizes RCS version numbers, "cvs log -b" will not report previous revisions even for HEAD developement. I'd call it a bug myself in the cvs log command, but it's more one of those detail behaviors of CVS that is carried over from it's RCS heritage/limitation days. While in general I do agree that I probably would want even branch efforts to be represented somewhere in the statistics, and there's certainly questions and design complications on how to go about that, I can appreciate limiting the statistics to HEAD development for now. That's not the case here, though, as the predominance of activity is HEAD activity. It's noticeable with BRL-CAD since our sources were in RCS for years and then later imported into CVS so that history was be retained. That import process preserves RCS revision numbers too and with RCS, it was somewhat more common practice to actually use the RCS number for various purposes. For example, you could have it imply api compatibility, simply serve as a means to denote new development phases, or even just to "reset" the minor revision number. You can actually even still do this with CVS, though it's done via flags during commit that will bump the major revision or via dreaded cvs admin commands. All of this mucking with revision numbers actually has really nothing to do with branching as it just increments the major revision number. To see an example of this in BRL-CAD, you see in the same log you mentioned for jove, i.e. "cvs log jove/jove.h", that the head revision is currently set to 11 (with the latest version before it was moved showing revision 11.8), but that there have also been revisions 10, 2, and 1 as well for that particular (bad example) file. Those are all on HEAD. This can be seen on just about every file in our repository where the RCS major revision number has been incremented over time and other numbers can be seen. If you were to check out HEAD using timestamps going back in time, you will get all of those other revisions as they existed. To truely get "all activity on HEAD", the "cvs log -b" command isn't really sufficient as it not only ignores branches, but it also ignores previous revisions. Instead of -b or at least in addition to it, you can get all HEAD activity by specifying that the revision range should start from RCS revision 1. cvs log -b -r1: I threw in the -b just to make it (doubly) explicit that the logs should be limited to the default branch, though it's actually redundant when you specify a major revision range. The "1:" basically means from major revision 1 to whatever the latest major revision number there is, which limits results to those found on the default branch. Perhaps this -r1: could be added? :-) I bet you'll find at least a handful of (older) projects where this will make a significant difference in the statistics being reported. I updated my script tables at http://ftp.brlcad.org/statcvs/cvs.html using "cvs log -b -r1:" and you can see there is a difference, but not nearly as substantial (which is what I would expect). In any regard, thanks again for the insight into the processing being used as well as for the productive discussion. Hope to see the revision numbering taken into account... :-) Cheers! Sean [Less]

Hello, this is a follow-up to the previous feedback topic but staying limited to a single topic this time (thanks for implementing a few of the features mentioned, we noticed). In particular, the ... [More] thread uncovered what seems to be some failure to process a huge portion of BRL-CAD's commit metrics so I went about determining just how much might be missing through some data-mining of my own. The results were rather interesting to say the least and do seem to concur with the previous assertion that much of our commit traffic is not being accounted for causing a cascade of incorrect values. I extracted all of our project's commit log messages and processed them with some simple scripting (also provided for your reference), with the results being visible at http://ftp.brlcad.org/statcvs/cvs.html. One of the metrics, shown in the second column, is that the number of unique commit messages, regardless of author, was 28409. Ohloh's commit statistics currently shows that same metric as being just 14760. Sorting by time on the ohloh commits page, you can see that in 1983 Ohloh found 2 of the 3 apparently unique commits; and in 1984 it found only 1 of the 137 unique commits. Similarly, my data-mining of the log messages unveiled 48 usernames that have committed, whereas Ohloh lists that only 39 were found. Similar issues seem to be prevalent in the "year's contribution" being computed for the various authors, although I suspect it's probably all caused by what seems to be roughly 50% of the commits not being accounted for. My hope is that the direct data-mining report at http://ftp.brlcad.org/statcvs/cvs.html might help track down what the cause is. Numbers in parenthesis on the "per-person" columns are where I collapsed two usernames where they were the same person, but I show the original values individually too that Ohloh should have been able to match. Thanks again for the hard work and great site! Cheers! Sean [Less]

As robin mentioned, this has to be a high-request item (for many various reasons) and would be a great feature to have. Every project I work on that has an ohloh project page could actually use this ... [More] feature (mostly 3rd party dependency sources that need to be ignored). That said, I'm sure there'd be some dissention on how to go about specifying paths to ignore or classify them. Personally, I wouldn't want to have a file in my project's SCM system (whether it be CVS or SVN or otherwise) that was specific to ohloh if I didn't have to. A .ohlohignore or something similar to a .cvsignore might be fine, but it would seem better to keep the metadata with the context that needs it -- i.e., as part of the ohloh project page through the web interface. Especially given that it seems like project enlistment updates are progressing more automatic now, the stats would eventually sort themselves out per any ignore/classification settings. [Less]

ogourmet, There is nothing that prevents you or anyone else from adding the Tcl/Java project yourself. Having the ohloh project admins/devs add other people's projects when it's been as open and ... [More] flexibly designed towards community involvement would be a certain waste of their time. If you want the project added, add it. Cheers! [Less]