Forums : Suggestions for Ohloh 2.0

On another thread, it's been mentioned that the Drupal (contributed) project has been purposely stopped from updating it's enlistment because it got far behind and ohloh hasn't had the opprotunity to catch up yet without halting the enlistments on other projects.

I also kind of feel like the Drupal (contributed) project is counter-intuitive. It seems like it would make more sense for it to be split into the various modules, themes, etc. rather than be one super-project. This makes particular sense given that each Drupal module, theme, etc. has it's own project page, downloads, etc.

So it seems that deleting this project and then letting each module author add his own modules and themes and such back in would make sense to help with both of these issues.

Any thoughts?

Andrew Sterling... over 17 years ago

In the particular case of Drupal contributions, I tend to agree. Pieces of software that are independently developed and independently delivered probably should all have their own independent project pages on Ohloh. And you're right, it's definitely easier for Ohloh to work with many small projects than a single large project.

Technically, I don't know exactly how Drupal packages all this code up, and whether it's even feasible to try to tease it apart. In this case it looks like it's all just one giant CVS module. Ugh.

I've wanted for a very long time to have some ability to create super-projects that include several smaller projects. For instance, if your project requires a library, it's better to not count the library in your own Ohloh report; instead, there should be a sort of 'include' feature that links to the library's original Ohloh report intelligently. As you've proposed, this feature would also let someone create a project that says, Aggregate all of the Drupal modules together into a giant report that will show how much more awesome we are than all those other CMSes.

It gets really interesting when you consider that we have a lot of code in our system, and when your project includes a source file from a library, the odds are good that our system already has the original authorship of that library in our database, and can automatically recognize the inclusion.

Sadly, I think we're a long way from this feature, but it's interesting to think about, and I'd like to get there someday.

P.S. Holy smokes, we are behind on updates for Drupal. I've restarted the download.

Robin Luckey over 17 years ago

Well, Drupal modules and themes are developed as individual pieces in their own forge-style environment (via the Project and Project Issue modules). All the module projects are hosted on Drupal's site and the infrastructure provided is, in my opinion, one of the reason Drupal has been so successful.

Adding a new module for download involves creating a project node on drupal.org, creating the CVS directory in the module directory of the contributed CVS module of cvs.drupal.org, tagging the code as belonging to specially named tags, and then creating a release node which results in a bot automatically packaging your module for release for you.

Basically, they try to do as much as possible for QA purposes (and are slowly adding the infrastructure to improve the QA enforcements more and more). Or at least, that's the process as I know it. I'm not actually familiar with anything in Drupal core or any of the Drupal core devs.

The super-project idea would be great.

Andrew Sterling... over 17 years ago

I would much rather see this continue to be reported in the aggregate. I don't think that many of the individual developers would bother to maintain an Ohloh project.

I would suggest that the Drupal community could offer support to assist with the processing and gathering of statistics, to offload CPU cycles and developer/sysadmin resources.

How could we make this happen?

Djun Kim (puregin [at] puregin.org)

Djun Kim over 17 years ago