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.
Version Control API and family changes
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.
Version Control API in Drupal 6 and beyond
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.
Read moreProject issue tracking 5.x-2.3 release roadmap
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.
Read morePrivate client issue tracker using Project + OG modules
Last updated by greggles on Tue, 2010-09-21 18:29
This is a site building recipe to build a private issue tracking system. It is still pretty experimental.
Read more
cvs contrib procedure
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.
Read moreSubscriptions vs. Notifications vs. Project issue's mail.inc
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
Read more
Parsing .info files for dependencies
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).
Read moreProject module 5.x-1.3 release roadmap
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-23project_page_overview() should use {project_release_supported_versions} (http://drupal.org/node/235037)
Project issue 5.x-2.2 release punch list
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-13Unaccessible project titles and uris visible: http://drupal.org/node/233785-- Postponed from this release pending further discussion of the implementationAdvanced search only matches an exact phrase: http://drupal.org/node/235097-- Fixed 2008-04-13
Case Tracker, Services and Timesheets
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.
Read more
Project* SoC project
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.
Read moreA new theme upload system for Drupal.org
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.
Read moreRoadmap for project* views-i-fication
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*.
Read moreMarch 7, 2008: DrupalCon Code Sprint Plans
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.
Read moreState of the Version Control API
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-->.)
Want issue tagging? We're now one step closer.
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.).
Read more
Help the Project* module! Help get aclight to DrupalCon Boston!
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:
Read moreUser authentication in non-CVS repositories
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.
Read moreCommit restrictions in distributed version control
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.
Read moreIssue 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 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