summer of code

This is copied from my current project site:

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.

Things are finally getting started. So for the first week Drupal 6 was settled on. So I was able to get a little familiar and get a good test environment set up for development. Some initial changes were made to file saving so that a private/public flag would be set (right now everything is considered public). Unfortunately the power supply on the computer I use for development died. So things might be a little slow until I get the new power supply on Thursday. Thus is life and so I'll get to really push myself over the next weekend ;).

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 the Summer of Code is started and getting private and public files working is now on the top of the list of my priorities. The first issue to solve, should this go in Drupal 5 or Drupal 6. Because of the nature of the fixes Drupal 6 would make sense but may contain too many problems to work around (bugs, wildly changing code). What has really left it up in the air is this patch which would associate files with users rather than nodes. So the first step is to figure that out.

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.

Adding Semantic Web support into CCK

Motivation

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.

For this Summer of Code, I'll apply for reworking the Project module to free it of CVS specifics. The greater plan is, of course, to get SVN support into project.module (and pave the way for other RCS backends), but if I am to believe knowledgable developers like dww and chx, getting the revision control functionality abstracted out into an RCS API module is already a lot of work. In case it should work out faster than expected ("unlikely" :D ) I figure I can still do the SVN specific bits in the time that remains.

You can find my application here. It's essentially complete, but before submitting it to Google I'm still waiting for feedback from dww, and yours can be helpful as well! As a short teaser, here's the introductory part of my application as copied from my website: