My projects CVS repository contains code from other projects. It is there to cut down dependency issues (additional downloads needed to compile) and I would like ohloh to ignore these parts. Maybe ohloh could look for files in the repository (like web crawlers look for robots.txt) that tell it to ignore certain directories?
http://www.ayam3d.org/ Ayam, where you get birails.
We've been tossing this idea around for a while. Google code introduced the concept of using robots.txt in the repository to disallow specific directories. While we'll likely support that directive in the near future, we'd like to introduce more semantics as well, including: official project licenses, product vs test vs documentation directories and developer aliases. This would enable us to produce much more interesting analyses. However, at that point this directives file would be pretty different than a robots.txt. I guess we could call it ohloh.txt but we'd be happy to call it something more generic ( project.info? info.txt?).
thank you for the feedback. I am glad to hear that you will probably support robots.txt in the future. As for the other, more ohloh or analysis specific, information, I would prefer to not have and maintain this information in the repository but rather specify those things when managing enlistments. This is, because one wants to specify it in one file per project, but can not manage such a file outside of any modules on SourceForge CVS. If you decide to get this information solely from the repository, a generic file name like project.info would be preferable.
http://www.ayam3d.org/ Ayam, where import means NURBS.
Thanks for the input,
Any update on this support? My web project relies on external libraries that are included within the source (such as Prototype, Scriptaculous) which are highly skewing the statistics.
This sounds useful to other projects as well. We'll look into it and keep everyone posted.
(posting here as this seems to be the original thread re this issue.)
As we start working on improving Ohloh, our top priority is to improve the quality of Ohloh’s data. This obviously includes the ability to choose to ignore certain directories that do not make sense to be analyzed as part of a project’s codebase.
We wanted to get your feedback about our proposed solution.
Short Term Proposal
For the short term, we want to enable both the following approaches: 1. Project owners can specify a .ohloh file in their root directory of their repository, telling Ohloh which directories to ignore 1. Users can specify which directories to ignore through the UI on the Enlistment page of the project. The same moderation/permissions will apply as all other parts of Ohloh, meaning managers of the project can restrict access if needed.
We’ve seen feedback on the forums for support for a .ohloh file (similar to a robot.txt file) that specifies which directories to ignore, like test cases, documentation, 3rd party libraries, and so forth.
For example, the contents of anyFileName.ohloh would simply contain:
Ignore UI on Enlistment page
For project owners who do not wish to include a .ohloh file in their repository or might not be aware their project is being included into Ohloh’s network, we’ll provide a very simple “Ignore” textbox for each enlistment on the Enlistment page of a project.
As a waterfall->agile convert, I’m a big believer in getting simple features out of the door as quickly as possible. We realize that more UI support, like a tree view of the current enlistment to pick and choose what directories to ignore, would be a more ideal user experience, and this is something we’ll want to get feedback on moving forward.
In the short term, I feel that enabling these two initial items (.ohloh file and Ignore textbox) will help address these data quality issues, while providing a good user experience for project owners and end users alike.
Let us know your thoughts!
Just get something working fast.
The .ohloh file approach sounds easy to implement from a technical standpoint, and emulates a standard most developers already know.
You have our vote for this approach.
Sara: The .ohloh file sounds very nice. Just one additional feature to make it really useful: Allow uploading the .ohloh file through the Ohloh web interface.
Scenarios: - The author doesn't like to add anything to their source code which is not (technically) necessary. - The author doesn't care about Ohloh at all (maybe doesn't even know it) but an interested user wants to ensure that code analysis is shown correctly.
So: As an registered Ohloh user I want to upload a .ohloh file to exclude some directory from code analysis so that Ohloh can show me correct statistics for projects where the author does not want to add an .ohloh file.
@Felix Thanks for the feedback. You're absolutely right that we need to handle the case where the .ohloh file is separate from the source code. We're currently figuring out how to best approach this issue, and I'll definitely include your suggestion in our discussions.
I like the idea of moving towards a file to describe various things. Even better if it's an open standard to increase the desire for projects to generate one.
"PAD is the Portable Application Description, and it helps authors provide product descriptions and specifications to online sources in a standard way, using a standard data format that will allow webmasters and program librarians to automate program listings. PAD saves time for both shareware authors and webmasters." http://pad.asp-software.org/spec/spec.php
Please also see the "Open Software Description Format (OSD)" http://www.w3.org/TR/NOTE-OSD http://www.w3.org/Submission/1997/9/Comment.html
A .ohloh file that follows robots.txt syntax is enough, and open enough, for this use, and OSD is overly complex.
I like that idea in general. Don't have any specific suggestions but looking forward to the result :) thumbs up
Whenever this feature is done, feel free to test with the Midgard Create project. I've added the following .ohloh file there:
@bergie Thanks! We'll definitely contact you when the time comes for us to start testing on real-world projects.
I'm very interested in this feature as well. On Google Code projects we keep the JavaDoc in Subversion which causes ohloh to produce totally odd numbers.
Is there a way to "subscribe" to this thread in order to get informed when you start testing the feature?
@rec Go to My Account (shown in navigation bar when logged in) - Notifications, and select Email me: When my forum topics are updated. Cheers!
@Sara: Thanks :) Looks like I already had that activated as I got your reply per mail. Now I'm looking forward to the exclusion feature.
your .ohloh file isn't working for me
I put it on the root directory but when you scan the repo again, it doesn't exclude what I want it to
@Pyritie: This might be because the feature is not implemented yet ;-)
A suggestion: rather than using .ohloh, consider using .ohlohignore and having it only include "ignore" entries. People already have a strong understanding of .gitignore and the equivalents for other version control systems, and .ohlohignore would fit right in. In the event you want other configuration in the future, you could always add a .ohlohrc or .ohloh file at that point.
We deployed our latest updates to the Ohloh site yesterday, which includes a way to specify which files and/or directories Ohloh should ignore!
On the Enlistments page for a project, you’ll see the “Choose files to ignore” link for each enlistment.
This will bring you to the Ignore Files page, where you can specify which files and directories to ignore.
For example, to ignore specific directories, you can use
# Some commonly excluded paths Disallow: lib/ Disallow: tools/
And for specific files, you can use
# Some random files from this repository Disallow: 7zSD.sfx
We have more examples and tips located on the Ignore Files page.
Choosing which files to ignore must be done with the Ohloh web interface. As I mentioned earlier, we were looking into supporting a robots.txt file in the source code itself. But, we felt that this behavior wouldn't be as popular as having a simple web entry, so we went with web-based solution.
If you have any reasons why you would want to use a .ohloh file over the web interface, please let us know.
You can read the full blog post of all the features in this update at https://www.ohloh.net/blog/LatestUpdatesToIgnoringFilesandDirectories
Please give it a try, and let me know your thoughts.
awesome, I'll give it a try
Thanks a lot, Sara. Works very well for me :-)