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.
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 drupal.org), 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
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
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
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
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 drupal.org! This is a major leap in issue queue functionality, including:
- multiple file attachments per followup
- tracker integration
- ability to edit followups (unpub/delete for admins as well)
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.
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
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:
* http://drupal.org/node/165380 -- Make usage statistics visible (see especially comment #75
* http://drupal.org/node/96971 -- Make better use of tabs and subtabs on project nodes
A comprehensive list of other issues related to the project node UI:Read more
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!Read more
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 http://www.petsovits.at/versioncontrol/ 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
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
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.Read more
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.
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! -DerekRead more
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