project module

I've been evaluating solutions for Project management (for the duration of this post, that includes what i describe as project, issue, ticketing, case tracking, and pretty much anything that falls in that category) solutions with Drupal, over a year actually. I keep being enticed by the features of each individual solution, and new promises that are announced for each module(s) and trying them out and coming to the same conclusion with each of them. And yes, all of them seem to have the same problems that I'm hitting repeatedly.

I've been spending most of the last week working on the project_usage.module. I got a copy of the usage data that's been reported to Drupal.org and spent some time fixing bugs (#167074) and making some small improvements (#167079, #167048). My big goal has been to get some code together to make the usage data visible (#165380). I've attached a few screen shots to show how it works.

As of about 2pm PDT Drupal.org has been tracking the module usage. #128827 has been committed to the project module and installed on d.o. There's a follow up issue to make this usage data visible to users (#165380). I've added support to the metrics module to factor that into the score.
I'm not sure if the metrics module will be installed on d.o until the current database troubles resolved.

There was a quote of someone saying that inexperienced programmers worry about code, while advanced programmers worry about data structures. Don't remember who said that, but personally I find this an excellent analysis.

Let's try to formulate the important questions that need to be answered in order to get the Revision Control API right:

1. What kinds of functionality do users need from the API?
2. What kinds of functionality do different revision control systems provide?
3. How does the data that is delivered to the caller look like?
4. Which functions are required to deliver the data to the caller?

Portland State's wacky quarters system means that, unlike everyone on a trimester system, I don't finish school until next week. I've been busy wrapping up classes and, considering that I haven't been able to devote my full attention to the project, I've made some good progress.

I setup a local test site using my Drupal.org testing profile. The profile generates some basic test data which should be sufficient for my initial work but down the road I'll need a copy of the sanitized drupal.org database dww mentioned.

The next step in my proposal is to identify a few simple metrics to serve as test cases when developing the framework. The data used to build the issue statistics pages seems like it would be a good choice but until I've dug into the guts of the project module to see how they're generated I can't say for sure.

There's a great introduction on git for SVN people like me, which made it twice as easy for me to look into how this thing works. Git only recently released their 1.5 version which is the first one that's supposed to be usable to the masses. (It might not yet be available pre-packaged for your Linux distribution, or available at all if you're running Windows, which could be a small hurdle at the beginning.) After reading the introductory couse and trying it out by myself, I must say I'm hooked.

For those who didn't know, git is the distributed RCS that was created by Linus and the other kernel folks because they needed to get rid of BitKeeper, and as the Linux kernel is a very demanding project both in code size and in patch management, git is quite capable indeed from an efficiency point of view. Currently in use by the Linux kernel itself, X.org, Wine, and One Laptop Per Child, to name a few popular projects.

As promised in my SoC application, here's a short rundown of features that are important to this abstraction layer.

So that's that. After having used the past two months for improving filefield and imagefield, it's about time that I get started with my RCS abstraction project. aclight has been as kind as to publish his work and findings in time with the Summer of Code, so that's a good starting point already. His work on the xcvs scripts (...bootstrapping Drupal, yay) benefits my project a lot, and the issues with password storage are good to know of.

In order to come up with a set of good questions that I'll need to research, I had a first shot on the database schema and the overall idea of how this thing should work. I thought it would be a good idea to see what we want to achieve and what we can rely on, before figuring out how to abstract all the stuff that's supposed to be different among the various revision control systems. Bullet points galore.

Hi there,

just to let you know about the track host module for drupal 4.7 I've just released.

The basic idea is to know the sequence and time-for-reading of users navigation on large content drupal sites (in my case http://roma.cercachetrovi.it)

Project home page: http://drupal.org/project/track_host

Feedbak is very welcome!

augusto
www.fagioli.biz

Andrew Morton
http://drupal.org/user/34869

Synopsis

I propose work on enhancing Drupal's Project module to add a
system that computes a number of quality metrics to assist in rating projects.
These metrics will help users determine which of the many contributed modules
and themes are being actively developed and maintained.

The Problem

Perhaps one of the most frustrating parts of building a Drupal site is
evaluating the many contributed modules to determine which meet the needs of

I just uploaded my application to Google's Summer of Code web app, and I can say I'm quite proud of its current state. The application has seen a couple of iterations based on valuable feedback by Adam Light and Derek Wright, both of which are working on RCS stuff for the Project module. Being fed into Google, this means that the Drupal mentors can now place private comments and supporting votes there.

Given that there are a good number of comments on some of the other proposals in this group, I'm still wondering if there is something I can do to spread the word and get more input from the greater public. After all, work on the Project module severely affects the great majority of drupal.org users, and getting rid of CVS as a hard dependency should really be discussed in the wider community. So do communicate your opinions about my application, its benefits for Drupal, its chances to get elected, its shortcomings, challenges, etc. ...I'm listening.