Issue tracking and software releases

This group should probably have more organizers. See documentation on this recommendation.

This group is a place for developers who are interested in how Drupal manages issue tracking, software releases, integration with CVS and other revision control systems, and related areas of functionality. Currently, the project module and casetracker module are the main modules in this space.

aclight's picture

Issue Tracker Comparison: Project issue tracking module vs. Google code tracker

For the past two months, I have been acting as one of the administrators of the Drupal side of the Google Highly Open Participation program (GHOP for short). Briefly, this is a contest that is sponsored by Google in which secondary students (ages 13-18) can claim and complete short one week tasks created by the Drupal community for cash prizes. One of the requirements of the program is that everyone has to use the Google Code task/issue tracker for tracking the "official" progress of the students throughout their tasks. As I have been pretty involved with development of our own issue tracker (the Project issue tracking module used on, I thought it would be useful to provide a comparison of the features of these two different systems and make some suggestions of how we can improve the Project issue tracking module to make it even better than it already is.

I'll start by giving an introduction to the main issue tracking features of both the Project issue tracking module and the Google code tracker. I'll also give a description of the administrative user interface from an individual project owner/maintainer's perspective. Next, I'll provide a feature comparison and point out the pros and cons of both systems. Finally, I'll provide some recommendations on specific areas where we can add or improve the Project issue tracking module to make it better than it already is. I want to point out that I am not mentioning any of the features of either tracker that allow it to interface with code, releases, or repositories since we did not use any such features for the GHOP program and thus I would not be able to make a fair comparison.

Read more

Project issue 5.x-2.0 release worksheet

Following is a worksheet of necessary items to complete in order to get Project issue 5.x-2.0 out the door:

Update: Now released: project_issue 5.x-2.0

Read more
mikey_p's picture

A complete solution for task/project/issue/case/ticket management with Drupal

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.

Read more

Unified solution to current problems with project* and update_status

There are a few limitations and problems with the current interaction of project* (project and project_release) and update_status. One of them is a fairly serious bug, something that was part of the existing design but that was omitted in the current implementation of update_status. Since we have to fix this problem anyway, we might as well Do It RightTM and fix the other limitations while we're at it. Moreover, time is very short to fix this in D6. Read on for an explanation of the problems and my proposed solution to all of them.

Read more

Issues to resolve before next round of official project* 5.x-1.x releases

checklist complete -- just need to cut the releases. releases cut. ;)

Part of the Project* roadmap for D6 involves getting another round of official releases out for project and project_issue. We've fixed a bunch of bugs, and it'd be nice to get new releases out at this point, before we start committing changes to views-ify project*. However, there are some lingering issues that either need to be solved, or in most cases, backported, before we're ready for the releases. If anyone can work on any of these, that'd be great.

Read more

project module, issue followups as comments -- needs testing

This was posted to the devel list, and I'm cross-posting here because I think there might be some interest...

Issue followups as comments is almost a reality on! This is a major leap in issue queue functionality, including:

  1. multiple file attachments per followup
  2. tracker integration
  3. ability to edit followups (unpub/delete for admins as well)
Read more's picture

Getting data offline

Following a request on the dev list, an issue and first-version code has been created to return a list of current issues as a single set of data, to be downloaded and used offline.

It includes, in a single JSON object:

  • the issues, selected by project, priorities, categories, and states
  • the followups/comments
  • the attached files

See the issue for more detail and to submit revisions.

Read more
jpetso's picture

Post-SoC progress

Seems I haven't given up on Version Control API & friends by now, which one could say is a good thing. Due to my rather silent nature, there haven't been as many g.d.o posts as during the Summer of Code (namely, none until now). Nevertheless a good share of remaining issues have been resolved, and missing features have been added. Here's a short rundown of what has been achieved since part 2 of my wrap-up, which was written a month ago.

Read more

Project node UI redesign

Prompted by some recent confusion regarding the project node UI (e.g. what a project node looks like on d.o), webchick, hunmonk and myself were just discussing the need for a more coherent plan on redesigning the UI.

Some background issues of interest:
* -- Make usage statistics visible (see especially comment #75
* -- Make better use of tabs and subtabs on project nodes

A comprehensive list of other issues related to the project node UI:

Read more

Project* roadmap for D6

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 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!

Read more
Chris Charlton's picture

Are you storing your Drupal sites or configs in a version control system? If so, which?

SVN (Subversion)
48% (112 votes)
6% (14 votes)
Other (please comment which)
8% (18 votes)
No, but I'd like to!
30% (70 votes)
No, I don't store my drupal sites in a version control system of any kind.
9% (20 votes)
Total votes: 234
jpetso's picture

Version control wrap-up, part 2: comments

If you already had a go at part 1, you have been waiting half a week for this one. Lack of internet, party intermezzos and my first company outing caused a minor delay, but here you are!

Read more
jpetso's picture

Version control wrap-up, part 1: modules

It's over! Google Summer of Code 2007 had its official "pencils down" on Monday, 19:00 UTC - which was 21:00 at my place, perfect for a last sprint... but I digress. According to Google, mentors are supposed to evaluate projects based on the state that they were in at that time. Which means it's time for me to wrap it up and explain what I achieved in those two or three months. In addition to these writings, I set up a test site at where you can try out most of these things in action.

The wrap-up is becoming too long to conveniently fit into one single blog entry, so I'll split it up into two halves. This one basically covers the hard facts: which modules I wrote during the Summer of Code, what they do, and how they work. (Part 2 is now also available.)

Read more
jpetso's picture

Progress, aims & challenges

The end of the Google Summer of Code is nearing, and stuff is coming together in my version control modules. It seems to me like I'll not be achieving everything that I would have liked, but most of the important stuff is going to be ready next Monday. And now for a short report of the last one-and-a-half weeks.

Read more
drewish's picture

Project metrics, a diversion through project_usage.module

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 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.

Read more
drewish's picture

Project Metrics -'s tracking project usage

As of about 2pm PDT 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.

Read more

Project* TODO list

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:

Read more

Issues to resolve in project* before a 5.x-1.0 release

At 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

Read more
jpetso's picture

VCS management

This week, my Version Control SoC Project saw further completions of the API functions' implementations (the API itself is completely implemented now, if I'm not mistaken) and the creation of extendable admin screens, mainly for repositories for now. There's now a list of repositories separately for each version control system, and each backend can easily customize creation, editing and display of repository information by means of hook_form_alter() and a small number of more specific hooks. Repository management is now at the same level of functionality as the one in cvs.module, only that it's generic at the basics and other backends can without much effort provide their own custom stuff, just like CVS provides CVS modules and different methods of commit information retrieval. Sure, you want screenshots:

Read more
jpetso's picture

Show me your logs

Er, right, this update post has taken longer than it should have. I've been active on the code though, and this time I even have a screenshot for you. Without further ado, I present Commit Log:

Read more
Subscribe with RSS Syndicate content