One part of my GSoC is to add support (of some sort) to VersionControl API for having multiple branches within a project (like a drupal.org project) with different user permissions. The idea is to allow a more DVCS-like workflow, where people can work independently on their own branch and then request an admin user to pull their changes into the master repository. I won't be starting this for a few weeks, but I wanted to get a discussion going about what it should look like.

I'm working on the Git hooks (specifically the 'update' hook right now) and am trying to figure out what sorts of things we would want in a pre-commit (or pre-push, in the case of DVCSs) hook.

What I have now

For now, I have only been checking whether the user attempting to push has an account with the given repository. Combined with the "admin must approve accounts" setting on repositories, this seems good enough to be useful.

Planning poker is fun, but if you're on a distributed team how do you play?

There are online tools to do this, but I'd like a simple way to do this in Drupal. Some thoughts:

• If all your issues are stored in Drupal then you could play poker with a node that consists of a nodereference field and a number field and then display the results of those node submissions. This feels like a sledgehammer solution.

This are just some random ideas about how we could organize drupal core development when/if it would be powered by git.
Every (core) dev can request a personal git repo for drupal development. Here he can push his stuff too, in a special layout.
The branches are named after issues the dev is assigned to. The base for them is the current HEAD (it's left to the dev pulling it in before starting his work!). Then the dev develops his patch. Whenever needed, he pulls the current HEAD in. When he's done with his patch, he uses a special tag name, and the magic starts:

Overview

This project objective is provide all tools to make it easy a possible drupal.org migration to another Version Control System(aka VCS). By the way, after this, drupal VCS's interaction will be improved, so it provides more flexibility to use it as project managment system for development.

This propose started like a jpetso propose.

Introduction

Some drupal.org developer tools, like the auto-releasing module versions feature, are CVS dependent, which is one of the reasons why drupal project is using CVS now.
Drupal developers are used to recognize others work, so it would be really natural to use a Distribututed Version Control System(aka DVCS) where this concept is implicit(authors and commiters can differ).
On GSoC 2007, Jakob Petsovits developed Version Control API, making it possible to integrate various VCS backends in drupal.
I'm really interested on VCS's, and specially dreaming about commiting to drupal with git(that's why I wrote a guide for maintainers).
Now, there are some details that make Jakob solution not production ready, so I want to take it all to this state.

It's been a long time since I last posted an update on the state of the Version Control API, assuming we disregard short teasers on Planet Drupal. Since this last article, Version Control API nearly died during my attempts to wholly restructure the data model for practically everything involving commits, branches & tags (now unified as "labels") and repository items (= files and directories). Luckily, the story has come to a good end. Well, "end"? Depends.

D202 is a full service web development shop headquartered in New York. We build beautiful content managed websites with a focus on online communities and social networks. Our team is distributed, with members from across the world. Our portfolio includes sites like www.data.org, www.roushfenway.com, www.jewishideas.org and more, and we're steadily growing.

D202 is looking for a Senior Drupal Developer who will be responsible for engineering features and functionality across multiple Drupal-based projects.

Location: You can live anywhere in the world

It's time to fix the last of the bugs before we create a new branch and start committing D6 porting patches for project*. That means we need a 5.x-2.3 release of Project issue tracking. Here's the working list of issues to resolve before we can tag/release the next version.

This is a site building recipe to build a private issue tracking system. It is still pretty experimental.

When I gained cvs access, I read the drupal book pages on cvs and also merlinofchaos blog, and polled irc drupal-support.

What I came up with was that there are 2 ways of maintaining releases for contributed modules.

1) Always have the latest code in head, and only release a branch when the new version of drupal comes out. For example when working with module and it is for drupal5 the code is found under HEAD, when the module is upgraded for drupal6, create a branch DRUPAL-5 for the drupal5 module.

Here are some notes that I took while comparing these system, based on a couple hours of poking around and reading code. Anyone feel free to jump in here and correct me on any of this stuff, especially if you've actually /used/ either of these modules before. :P

Idea came up on this issue (twice) http://drupal.org/node/265450

This information would be useful for a couple of reasons:

Showing dependencies automatically on project pages - some maintainers are kind enough to list them in the description, but what's in the .info file is the best bet.

Showing related modules - modules like token, views, voting API could show dependent modules, modules with dependencies could show other modules with the same dependencies (cck, jQuery UI).

The following issues are all (at the time I'm writing this) either RTBC or CNR

• project* namespace bugs in $node (http://drupal.org/node/98278)
• Code style fixes on 5.x (http://drupal.org/node/324639)
• Prevent/limit project_usage abuse (http://drupal.org/node/168009)
• Make usage statistics visible (http://drupal.org/node/165380) -- Fixed on 2008-10-23
• project_page_overview() should use {project_release_supported_versions} (http://drupal.org/node/235037)

Note: Project issue 5.x-2.2 has been released. See http://drupal.org/node/249127.

Here's a list of issues to finish up for the upcoming 5.x-2.2 release of project issue:

• Russian Translation: http://drupal.org/node/221640 -- Fixed 2008-04-13
• Unaccessible project titles and uris visible: http://drupal.org/node/233785 -- Postponed from this release pending further discussion of the implementation
• Advanced search only matches an exact phrase: http://drupal.org/node/235097 -- Fixed 2008-04-13

I like Case Tracker because it is Drupal. It has some weirdities, but otherwise it's a good baseline and I've extended it pretty easily with cck and views and it's really starting to hum. So I thought it was time to share where I'm at with Case Tracker.

I tried Organic Groups integration with Case Tracker in an earlier trial (my current support site is the 4th and final attempt). I have a client node-type and I use the CCK node reference module to link projects to clients. I then have half a module worth of glue code to improve navigation and usability.

I like Case Tracker because it is Drupal. It has some weirdities, but otherwise it's a good baseline and I've extended it pretty easily with cck and views and it's really starting to hum. So I thought it was time to share where I'm at with Case Tracker.

I tried Organic Groups integration with Case Tracker in an earlier trial (my current support site is the 4th and final attempt). I have a client node-type and I use the CCK node reference module to link projects to clients. I then have half a module worth of glue code to improve navigation and usability.

Hi everyone!

My name is Markus Schanta, I'm a 21 year old Computer Science student from Vienna, Austria and I would love to participate in the 2008 SoC and do some work on the project* modules.

The project* modules provide project management for Drupal sites. Generally projects are assumed to represent software that has source code, releases, and so on. 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.

Added to official ideas list at http://drupal.org/node/234735

(draft project outline).

Contributing a theme to Drupal.org currently requires a CVS account. This isn't good for getting new designers and themers involved. So this project would involve creating a UI so that themes can be uploaded via a browser, yet still have a project page and versions. Some developers are likely to want to continue managing their themes directly from CVS of course.

Added to official ideas list at http://drupal.org/node/234735

(draft project outline).

Contributing a theme to Drupal.org currently requires a CVS account. This isn't good for getting new designers and themers involved. So this project would involve creating a UI so that themes can be uploaded via a browser, yet still have a project page and versions. Some developers are likely to want to continue managing their themes directly from CVS of course.

Here's the more detailed plan for views-i-fying the project and project issue tracking modules.

NOTE: As of April 10, 2008, the current timeline for adding views integration is to quickly finish the basic Views 1 functionality for the project issue module in Refactor project issue to use views, commit that code, and then begin the port of project* to Drupal 6. During that port, Views 2 integration will be added and Views 2 will be required for the Drupal 6 version of project*.

dww, hunmonk, and I will be meeting at MIT for the DrupalCon 2008 Boston code sprint around 10:00am today. If any of you are interested in helping out and are in town, feel free to join us-we'd love to have additional help. If you aren't in Boston right now, drop in the #drupal-project channel on irc.freenode.net and talk to us there.

I wanted to write down our current plan (as I understand it) for the day to help us organize assistance better. The items below are those that we want to tackle, roughly in this order.

dww, hunmonk, and I will be meeting at MIT for the DrupalCon 2008 Boston code sprint around 10:00am today. If any of you are interested in helping out and are in town, feel free to join us-we'd love to have additional help. If you aren't in Boston right now, drop in the #drupal-project channel on irc.freenode.net and talk to us there.

I wanted to write down our current plan (as I understand it) for the day to help us organize assistance better. The items below are those that we want to tackle, roughly in this order.

Yeah, those were the times. Weekly status updates during the Google Summer of Code... well, I'm too lazy to do that when I'm not forced to :-P
Let's see... the version control api term says that the last status update was in September '07. Way too long ago. So what's up going on in the Version Control API realm at the moment? Lots of good stuff. (Read on! It's just the <!--break-->.)

Yeah, those were the times. Weekly status updates during the Google Summer of Code... well, I'm too lazy to do that when I'm not forced to :-P
Let's see... the version control api term says that the last status update was in September '07. Way too long ago. So what's up going on in the Version Control API realm at the moment? Lots of good stuff. (Read on! It's just the <!--break-->.)

A while back catch created a feature request for the Project issue tracking module to allow free tagging on issues (see http://drupal.org/node/187480). The use case he indicated was to be able to attach certain labels to issues, for example benchmark, needs re-roll, needs doxygen, etc. Other use cases would include tagging issues that need testing in certain ways (eg. MySQL, PGSQL, Javascript, IE, etc.) and tagging issues that are good for certain audiences (eg. newbie, GHOP, DROP, etc.).

A while back catch created a feature request for the Project issue tracking module to allow free tagging on issues (see http://drupal.org/node/187480). The use case he indicated was to be able to attach certain labels to issues, for example benchmark, needs re-roll, needs doxygen, etc. Other use cases would include tagging issues that need testing in certain ways (eg. MySQL, PGSQL, Javascript, IE, etc.) and tagging issues that are good for certain audiences (eg. newbie, GHOP, DROP, etc.).

Some of you may have seen Kieran Lal's pitch to the Drupal community to help get Derek Wright (dww) and Chad Phillips (hunmonk) to DrupalCon Boston to work on the crucial Project* modules, and many of you chipped in to help Derek and Chad reach their goals. But the project* team can still use your help!

Adam Light (aclight on Drupal.org) is also trying to get to DrupalCon to work on Project*, and trust me, it will be worth ten times whatever you can give. I have only had limited interactions with Adam, who I don't know personally, but even those limited interactions have blown my socks off. Adam was a tireless volunteer for the GHOP program, and his work with these students was truly out of this world (take a look at any of the GHOP issues that Adam helped out with and you'll see what I'm referring to). As Webchick noted on her blog post asking for help for Adam and Jimmy "boombatower" Berry: "Adam was the one primarily carrying the torch during the latter half of the GHOP program, and was critical to ensuring its success."

I happened upon a blog post Adam wrote in which he requested assistance on the DrupalCon Boston feed, and I think that Adam is a bit too modest to post his request here, so that's why I'm writing this. Here's how Adam describes his contributions to Drupal:

Some of you may have seen Kieran Lal's pitch to the Drupal community to help get Derek Wright (dww) and Chad Phillips (hunmonk) to DrupalCon Boston to work on the crucial Project* modules, and many of you chipped in to help Derek and Chad reach their goals. But the project* team can still use your help!

Adam Light (aclight on Drupal.org) is also trying to get to DrupalCon to work on Project*, and trust me, it will be worth ten times whatever you can give. I have only had limited interactions with Adam, who I don't know personally, but even those limited interactions have blown my socks off. Adam was a tireless volunteer for the GHOP program, and his work with these students was truly out of this world (take a look at any of the GHOP issues that Adam helped out with and you'll see what I'm referring to). As Webchick noted on her blog post asking for help for Adam and Jimmy "boombatower" Berry: "Adam was the one primarily carrying the torch during the latter half of the GHOP program, and was critical to ensuring its success."

I happened upon a blog post Adam wrote in which he requested assistance on the DrupalCon Boston feed, and I think that Adam is a bit too modest to post his request here, so that's why I'm writing this. Here's how Adam describes his contributions to Drupal:

How to grant access to repositories at all is an important issue, and it potentially comes with a slight regression compared to the current work flow for managing CVS accounts. One advantage of CVS is that it's easy to administer - in terms of user accounts, that would be a simple "passwd" file that contains all usernames that are allowed to commit. Dead easy to generate, and at least possible to keep in sync even in an automated way. However, more recent version control systems are less nice to handle - also caused by a better eye on security concerns. An overview.

How to grant access to repositories at all is an important issue, and it potentially comes with a slight regression compared to the current work flow for managing CVS accounts. One advantage of CVS is that it's easy to administer - in terms of user accounts, that would be a simple "passwd" file that contains all usernames that are allowed to commit. Dead easy to generate, and at least possible to keep in sync even in an automated way. However, more recent version control systems are less nice to handle - also caused by a better eye on security concerns. An overview.

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

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.

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

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

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

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 Right^TM 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.

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 Right^TM 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.

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.

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.

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:

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

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:

1. multiple file attachments per followup
2. tracker integration
3. 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.

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.

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.

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: