New Release System

I just spent some time in #git to further investigate how our CVS access control scripts would translate to distributed version control systems, in order to help determine the right direction for our new GHOP-powered Git and Mercurial backends (currently being worked on, more on that to come later). Short answer: keep out of that altogether - it's not DVCS style to restrict project maintainers like that. Read on for a more detailed analysis.

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.

Now that Drupal 6 is out, getting the project* family of modules ported to D6 is going to become an urgent task. We want to ensure that by the time the final release candidates are out, we're ready to upgrade drupal.org to D6 (which must happen before the official 6.0 release is possible). That's going to take a lot of effort, and hunmonk and I have some very specific plans for how it should all happen. This page will be the place to keep track of what has to get done, in what order, so that anyone who wants to help knows where to put their efforts. It's obviously a work-in-progress, so feel free to help keep it updated, add issue links where appropriate, cross off things that are completed, or add other steps that need to happen.

I'm cross-posting this to a lot of groups since: a) converting project* to use views is a big part of this effort (so we have significantly less code to support in project* and port to newer versions of core), b) since we need lots of volunteers/help, and c) in case anyone is able to help sponsor some of this work to ensure that everything is completed well before the core maintainers would like to ship 6.0. Thanks!

Garrett Dimon is writing a series of posts on the design of his issue tracking system. The design if for smaller projects than Drupal, but it may provide some inspiration.

So far:

http://garrettdimon.com/archives/2007/8/14/bug_issue_tracking/
http://garrettdimon.com/archives/2007/8/20/the_tracker_status_bar/
http://garrettdimon.com/archives/2007/8/20/tracker_status_amp_comments/

Instead of keeping potentially stale copies of a TODO list in the README.txt files in CVS, I'm moving these list to a wiki page here so there's just a single canonical copy. This is general stuff about the modules. Other to-do lists of interest include:

• Future work for the release system
• Suggestions for improving the d.o issue queue (especially for core)

At http://drupal.org/node/150278 we've started serious work on an official 5.x-1.0 release of project* (project, project_issue, and cvslog).

Here's my current list of issues I'd like to see us resolve for the 5.x-1.0 releases, if possible. Mostly, these are either a) critical bugs, or b) patches I've already written for relatively easy-to-solve problems. Feel free to add comments or update this list. And, of course, please work on any of the issues below -- reviewing, testing, rolling patches, etc. Thanks! -Derek

how long is a release system allowed to describe itself as new?

The project* collection of modules (Project, Project issue tracking, and CVS integration) is the largest set of code running on drupal.org besides Drupal core. They are the key tools that power all Drupal development, including the Drupal issue queue and Drupal release system. Because of the huge user base, high visibility, complex requirements and feature requests, and size and scope of the existing code base (and issue queues) there is a ton of work to be done. This wiki page is how I (dww, the primary maintainer of project*) will try to communicate the best ways for other people to get involved in helping. One of the ways to help is to improve this list, so please add your own ideas here.

Hi,

I'm thinking this may be a good place to start seriously contributing to Drupal. Basically I'm looking for a project that needs help (!) and that will help me to get a strong grasp of how Drupal works. I know Project* fits the first criteria, but I'm a little unsure how well it will help me grok Drupal as a whole.

It is a known fact that the drupal modules page (http://drupal.org/project/Modules) is not perfect. There's a lot of discussion going on about how to gather module quality metrics, wether to enable a voting module or not, etc.
It's quite true that it's currently rather difficult to find what you're looking for. I think that by now I've got quite a good overview about the "hot" modules, but still for me, I often find the modules by using the advanced search or by checking cvs commit track page of the user of which I know he created the module.

this is an idea i've been thinking about. posting it here so other folks can add to it, provide feedback, etc.

Summary

we could really use an install profile that setup a test site similarly to how drupal.org is configured (especially the project* modules and CVS integration). obviously, it wouldn't have the bluebeach theme, but otherwise, it would look fairly similar to d.o in terms of structure, content, permissions, etc.

this would greatly help people who wanted to reproduce bugs and test patches for the project* family of modules, which is something we desperately need more of.

Myself, Webchick and Killes have come up with two proposals for this year's SoC which involve the drupal.org infrastructure and the project module. Both of which could solve some of the worst drupal.org usability problems, and yet are interesting, flexible projects where someone with a lot of creativity and talent could have a huge, highly visible (and valuable) impact on the entire Drupal community.

the Drupal Dojo sounds great, and i'm happy to join the efforts (as both student and teacher, it's a whole spectrum, not a bit). anyone who wants to dive into Drupal development right now can help by mercilessly beating on http://scratch.drupal.org to test out the latest 5.x release candidate code, and submitting issues (with patches, if possible!) about any problems you find.

I've noticed a couple of other helpful resources on there in The Wild(tm) relating to my efforts on the new release system. I figured it'd be nice to list them all here, so other folks can a) benefit from easy access to the additional info and b) add to the list as they see fit. Perhaps some of this can/should be linked to from the CVS handbook pages about the release system on d.o? Anyway, here's the list...

• Lullabot Podcast #28: Derek Wright and the New Release System
• My informal take on using the new release system (post by Earl Miles a.k.a. merlinofchaos).
• Testing the new Drupal release system (post by Kjartan Mannes, original author of the project.module).
• Project of the Month: Drupal Project.module

Cross-posting an email I sent to infrastructure list a few weeks ago, together with Kjartan's response.
It would be great if drupal.org supported distributions by the time Drupal 5 will be released.

The two mails (by Kjartan and me) outline a way to support distributions in an easy way (both for developers and end users). So what are your opinions on this?

Are there any existing guidelines or best practices when it comes to developing specific install profiles and distributions? As far as I can tell, I don't see info on this type of contribution (http://drupal.org/node/22286) or a means to set up a project similar to how you'd do it for a module or theme (http://drupal.org/node/7765).

I think this question is relevant to the context of this group. Any guidance would be much appreciated.