Issue tracking and software releases

Suggestions for improving the d.o issue queue (especially for core)

dww — Tue, 03 Jul 2007 19:57:38 +0000

This page is a place to gather suggestions to improve the drupal.org issue queue (provided by the Project issue tracking module), especially as relates to the core issue queue (by far the largest and most active queue on the site). Please add to the list, or edit items to provide a link to the corresponding issue (feature request, whatever) in the project issue queue.

Note: Requests to add or rename issue status values belong in the drupal.org webmaster issue queue (component == 'Site organization') since those are just admin settings on d.o, not hard-coded into project_issue.module.

Mentioned on the devel list:

Add "concept needs feedback" status for earlier discussion of architecture.
Close "active (needs more info)" after two weeks: see issue Dealing with "active (needs more info)" issues.
Add "patch - needs benchmark" status.
Better support for per-component maintainers:
- Automatically assign issues to the component maintainer?
- RSS feeds per component
Ability to re-assign tickets to someone else. http://drupal.org/node/4354
Way to "subscribe" (add it to your tracker/my issues page, and/or email) without actually following up to the issue. http://drupal.org/node/34496
Convert issues to comments. http://drupal.org/node/18920
Rename the current "patch (ready to be committed)" to "patch (ready for final review)". Issue: http://drupal.org/node/156637
Add a description to the Issue Information fieldset that links to handbook pages describing the meaning of the fields and the Drupal development process. See issue #159457.
The "web of trust" be formalized and those developers get a new permission to upgrade an issue from "patch (ready for final review)" to a new, restricted "patch (ready to be committed)" status. (this is already supported by project* module)
Patches that are not marked "code needs work" or "to be ported" be periodically and automatically checked to make sure they still apply without FAILing.
Improvements to advanced search:
- Make it easier to find in the first place
- Selecting in small multi-selects is a pain, perhaps checkboxes are better?
- Selecting all issues for a given series (5.x, 4.7.x), not just specific versions. http://drupal.org/node/97569
- Should defaults include support requests?
- Layout the table more nicely.
- A little bit of descriptive text could help get new users up to speed faster, but not get in the way of power users.
- Land on the URL currently marked by a # on the results page.
Improvements to the results page:
- Getting a specific url for it requires knowing to click the # hidden at the bottom. We should go directly to the permanent link.
- The dropdowns are inadequate to represent your search and are often wrong. A full description of the search should be shown, even if it is not editable. The dropdowns should probably be skipped all together. [note: I partially disagree with this. The dropdowns should be improved to represent the search, but I find it incredibly useful to be able to further refine a search by tweaking the drop-downs in this case]
- There is no way to get to a pre-filled advanced search screen from your current results. Making minor adjustments to the search is impossible, unless you are lucky enough to have it in your browser history.
- A line saying how many issues were found would help with tracking progress.
~~A 'decay feature' that sets a patch back to 'code needs review' after 2 weeks as RTBC?~~: won't fix.
~~Various proposals for voting on moving status values, etc.~~ [note: This seems doomed, that it will generate more work than it'll solve, etc. This has no support, so I'm not bothering with an issue about it.]
somebody mentioned it before, but let's make sure it's counted: a way to perform some mass operations on the results of the search page. like mass changing the status of issues, or mass assigning/unassigning.
AJAX teasers for issues
drupal.org infrastructure needs to scale so that using the issue queues is not so slow and painful.

Some of my other suggestions:

Provide a way to "show all", or "show X results per page" on the pager results.
E-mail issue subscribing should be more visible. http://drupal.org/node/16014

Moshe's suggestions:

add some checkboxes to a followup which indicate the quality of the patch review:
-- i tested the functionality
-- i reviewed the code for standards compliance
-- i reviewed the code for elegance
-- i agree with the proposed functionality
let people register thumbs up or thumbs down without generating a full followup or an email notification http://drupal.org/node/42232

Issue tracking and software releases

Subscriptions vs. Notifications vs. Project issue's mail.inc

webchick — Sun, 22 Jun 2008 23:48:23 +0000

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

Subscriptions module came first. This module has been around a long time (since at least 4.3), and gone through many different maintainers. In Drupal 5, chx re-wrote large parts of it to make a 5.x-2.x branch, and the current maintainer, salvis, seems to be very involved and keen. However, due simply to the age of the module, some of the code is a bit convoluted.

Notifications module is a fork of Subscriptions by the Development Seed guys that has some code clean-up and has made the code more modular. So modular, in fact, that one could argue it's been taken to completely insane levels. ;) But it has some nice features like Mailhandler integration (which is also in mail.inc, although I doubt that anyone's used it since it was coded :P), the ability to send notifications via SMS, etc.

Each module employs a "stack" something like the following:

Basic API functions for managing subscriptions and the queues of what stuff to send to whom: Subscriptions/Notifications modules, which are configured with Subscriptions UI/Notifications UI modules.
The "Send the notifications out" part. Subscriptions uses the bundled Subscriptions Mail module, Notifications piggy-backs off the Messaging module to provide this. Messaging, in turn, provides sub-modules to send things via e-mail (PHPMailer or regular drupal_mail()), SMS, etc.
The "What stuff can you subscribe to?" part. Both modules provide a hook that other modules can implement in order to provide subscription forms. So you have sub-modules like subscriptions/notifcations_taxonomy.module, subscriptions/notifications_content.module, subscriptions/notifications_cck.module, etc., each of which explain how those modules innards work to the appropriate module.

What this means in the practical sense is that whichever solution we go with is going to mean module dependency fever: we need at least 5 sub-modules with Subscriptions module (though html_to_text is included in D6), and something like 9-10 with Notifications/Messaging, in order to get the same functionality as our lovely little mail.inc. Furthermore, we wouldn't be eliminating any code, really. We'd simply be moving most of our logic from mail.inc to project_issue_subscriptions/notifications.module. :\

What I would love to see instead is for someone to write a views_subscribe.module (or whatever) that handles the "list of stuff" that should be subscribed to. This would then integrate with either Subscriptions or Notifications module to handle the queueing/actually send mail/SMS/whatever to people stuff. chx has some notes written about this here: http://drupal4hu.com/node/57

Rationale: Project issue already has Views integration (aclight tells me that Views required in D6). So does Organic Groups, taxonomy, CCK, etc. We install something on Drupal.org like Flag module, which allows people to toggle a "subscribe" flag on project issues (or, heck, anything! forum topics, etc). Then the "My issues" view is adjusted to look for those, and views_subscribe is configured to send out notifications of new/updated nodes within that View by whatever means the user choosesn (RSS, SMS, E-mail, carrier pigeon...)

Thoughts?

Mail

Parsing .info files for dependencies

catch — Wed, 04 Jun 2008 14:12:01 +0000

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

I guess we've already got code which determines what the dependencies are (although I've never looked at it) so showing dependencies on a project page might not be the hardest thing in the world, using it for recommendations would of course be a bit trickier. Does this sound like something that'd be workable? Should it be a feature request against project* if so?

Module metrics and ranking

Project module 5.x-1.3 release roadmap

aclight@drupal.org — Mon, 21 Apr 2008 11:32:58 +0000

The following issues are all (at the time I'm writing this) either RTBC or CNR
* ~~Add possibility to retrieve a list of projects from the server (http://drupal.org/node/157514)~~
* ~~Prevent/limit project_usage abuse (http://drupal.org/node/168009)~~
* Make usage statistics visible (http://drupal.org/node/165380)
* ~~project_page_overview() should use {project_release_supported_versions} (http://drupal.org/node/235037)~~
* ~~Add search block for just project nodes (http://drupal.org/node/168819)~~
* Browse by date does not work without project_release and taxonomy modules (http://drupal.org/node/239240)
* {project_release_default_versions} table is not dropped in update 5200 (http://drupal.org/node/235035)
* Inconsistant handling of 'access own projects' permission (http://drupal.org/node/234463)
* Restrict node access by versioncontrol_project too (http://drupal.org/node/186856)

Not ready to go yet, but would be nice if we could finish this up soon.
* project* namespace bugs in $node (http://drupal.org/node/98278)

Issue tracking and software releases

Project issue 5.x-2.2 release punch list

aclight@drupal.org — Sun, 13 Apr 2008 15:15:33 +0000

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
~~Default values of component should be translatable: http://drupal.org/node/245363~~ -- Fixed 2008-04-13
~~Module dependency checks: http://drupal.org/node/186259 (having infinite loop probs w/ initial patch on intel mac, php 5.2.5)~~ -- Fixed 2008-04-13

Possibly:
* ~~always allow users to leave the version alone when replying: http://drupal.org/node/97145~~ -- Fixed 2008-04-13

BTW, here's the task for creating the 5.x-2.2 release itself: ~~http://drupal.org/node/234180~~ -- Fixed 2008-04-20

This probably shouldn't hold up a 5.x-2.2 release, but if it's ready by the time we're otherwise ready to make the release it wouldn't hurt to have it in [ACL]:
* ~~Refactor to use Views: http://drupal.org/node/76725 (Initial patch for Views 1)~~ -- Postponed from this release -- needs more review time.

Issue tracking and software releases

Case Tracker, Services and Timesheets

sime — Mon, 31 Mar 2008 18:25:14 +0000

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 also have two modules that I use to extend Case Tracker:

Case Tracker Services (beta) allows my customers to review, add and comment on cases from their own site - with all data stored on my support site and displayed dynamically in their site using the services module.

Case Tracker Work (alpha) is a basic work/time recording module. It's nothing special but I'm trying to get it thorough with good views support and some nice timesheet displays for the beta.

Hope this is useful
Simon

Project Management

Project* SoC project

adebar — Sun, 23 Mar 2008 16:54:49 +0000

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.

I think there are several reasons why this module is important for Drupal. Fortunatley there's also good deal of work to be done here: see here.

It seems that there's really a big amount of "smaller" issues there. However, I'm not sure if any of theese is wide-ranging enough to consitute a SoC project.

Do you think it's desirable if a project consists of fixes to multiple problems, which need to be solved, rather than imlpementing "the one new big feature"?

If so, which issues would you recomend for a SoC project?

If not, can you think of any other project*-related work that can be done as a SoC project?

Looking forward to your answers,
Markus

UPDATE: After reviewing all the feedback I've been getting so far, I decided that I'm probably going to propose a Version Control related project. See this comment for more details.

UPDATE: I submitted my application through the GSoC web app two days ago. See this comment for the most recent version.

Issue tracking and software releases

A new theme upload system for Drupal.org

catch — Sat, 08 Mar 2008 20:39:35 +0000

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.

Issue tracking and software releases

Roadmap for project* views-i-fication

aclight@drupal.org — Fri, 07 Mar 2008 16:38:26 +0000

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

There is currently a patch for project issue that is largely functional and exports the various project issue related fields for views to use. See Refactor project issue to use views. There is also a patch in progress for the project module, but it is not as complete. See Refactor project to use views

The following pages need to be made into views. drupal.org paths are given below, however you can also use the Drupal.org testing installation profile on your local site for testing and creating these views. If you want a sample script that you could use (you might need to modify it some for your own setup) to easily create a test site, go to the documentation link at that project page.

Project

~~1. Projects browse by category (eg. http://drupal.org/project/Modules, http://drupal.org/project/Themes, etc.)~~
~~2. Projects browse by name (eg. http://drupal.org/project/Modules/name, http://drupal.org/project/Themes/name, etc.)~~
~~3. Projects browse by date (eg. http://drupal.org/project/Modules/date, http://drupal.org/project/Themes/date, etc.)~~
~~4. Project releases "All releases" page for each project (eg. http://drupal.org/node/16013/release).~~
~~5. Project types page (http://drupal.org/project)~~
Regarding the above, code can be obtained from https://aclight.devguard.com/svn/project and no username/password is required. Project browsing has been changed quite a bit to make the views much less complicated and hopefully provide a more user-friendly browsing experience. The old paths, such as project/Modules/category, etc. are no longer active, so we still need to write a simple module that provides redirects from the old paths to the new paths.

Project issue tracking

All issues listing page (http://drupal.org/project/issues)
Per-project issue listing pages (eg. http://drupal.org/project/issues/project_issue, http://drupal.org/project/issues/project)
Issues advanced search results page and search building page (http://drupal.org/project/issues/search/)
My Issues listing page (http://drupal.org/project/issues/user) which also handles the My Projects page (http://drupal.org/project/user).

Ideally we'd have the ability to turn all of these views into RSS feeds as well.

Issue tracking and software releases

March 7, 2008: DrupalCon Code Sprint Plans

aclight@drupal.org — Fri, 07 Mar 2008 14:06:14 +0000

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.

~~1. Discuss plans for views-i-fication of project and project issue tracking modules.~~ See http://groups.drupal.org/node/9500.
~~2. Discuss roadmap for Drupal 6 port.~~
~~3. Finish up Inaccurate release table image captions~~ (http://drupal.org/node/230763)
~~4. Do a whitespace cleanup of project~~
~~5. Branch project module for Drupal 5, create a release.~~
~~6. Finish up Allow theming of changes in project issue table and email~~ (http://drupal.org/node/219734)
~~7. Create a Drupal 5 2.1 release of project issue tracking module and a 5.2 branch.~~
8. Fix project* namespace bugs in $node (http://drupal.org/node/98278). This is going to be a PITA to fix and is boring, but if we all take a file or two I think we can bang this out and get it committed today. That way, we can work on other patches knowing that they won't have to be massively reworked once this issue gets committed.

Issue tracking and software releases

State of the Version Control API

jpetso@drupal.org — Mon, 18 Feb 2008 23:49:55 +0000

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

Backends on the rise

That's right: thanks to a task idea and management by chx and aclight, reviews by myself and dww, a highly open participation contest by Google, but most of all thanks to the awesome GHOP students ezyang and boombatower, we now have working backends for Mercurial and Git. Both of those backends cover all of the necessary functions for log retrieval, so if you want to view the commit messages of all those different repositories on your server, you know you can do it now.

Additionally, I have just gotten around to implementing a basic Subversion backend (unfortunately, the GHOP task for that one didn't succeed), which makes a total of 4 (four!) different VCS backends that are basically working. Considering that there are five popular version control systems out there, that doesn't leave much for a complete list! Of course, all of those new backends might still be a bit rough around the edges, but we're getting there.

drupal.org deployment deferred

hunmonk was already working on a script that ports data from cvs.module to the Version Control API + CVS backend + project node integration, but in the end there's too much to do for an instant switch of drupal.org. So the plan is to do a plain port of cvs.module to Drupal 6 and initially deploy that one. Version Control API should then replace cvs.module sometime in the Drupal 7 release cycle, when the database schema is stable and the remaining features are on par with cvs.module.

Stable release and further plans for the API module

I finally pushed out Version Control API 5.x-1.0 last week, with a minor bugfix release following yesterday. That release incorporates a lot of progress and testing - also made possible by the new backends - and is at least capable to show your commit logs in a pretty nice way. Probably more, but there are again large changes looming on the horizon... reviewing the new backends and input from ezyang made me think a lot about how the database tables could look like, and I finally have a plan on how to solve all remaining problems in one single stroke... well, something like that.

When I first drafted the rough architecture of the Version Control API and the data that is stored by the API module, I chose to leave file revision data to the backends so that it would theoretically be possible to retrieve logs without storing stuff in the database. That's a good premise, however two points now speak very much against it:

All backends utilize their own item tables, and it's unlikely that backends appear make use of this possibility.
Plus, calling the VCS binary each time when we need logs or even filter commits by path is going to be a major performance hit.

That's two good arguments against leaving out item tables, and the argument in favor is that centralizing this will make things easier for the API module - where easier also means that it will approximately improve performance to the level of cvs.module, and that's going to be important for deploying that stuff on drupal.org. The nice side effect is that centralizing stuff also takes work away from the backends, and that will essentially reduce the backends to little more than a simple interface between VCS and Version Control API, with hardly any commit/branch/tag management code left. If you're interested in the details, you can head straight for the Version Control API issue queue and look for "major issues".

So the plan is decent, it now just needs to be implemented timely. Along with that go small and not so small improvements in the API - amongst others, I want to kill off commit actions in favor of standard "items" with additional information, and if all goes well then we'll be able to query for commits, tags and branches with a single function call and get the information back in a unified format. (Displaying tags and branches next to commits in the log? You'll have it!) On the downside, I'm already creating the Subversion backend for post-1.0 versions only, so you either need to use development snapshots or wait for 5.x-2.0 in order to use it. Also, the Drupal 6 port will have to be postponed until these changes are done.

CVS backend on par with cvs.module

Last month I also got to (finally) port the log parser from cvs.module to the CVS backend, which means that the backend is now really as nice as the "backend part" of cvs.module. Feature-wise, in terms of polish, etc. - ok, if you don't take into account that cvs.module got an additional safety against branch creation through the backdoor in the meantime, which needs to be ported too.

The not so nice fact is that being on par with cvs.module is not sufficient, as we need more functionality in order to redo the (still pending) release node integration in a nicer way. That mostly includes retrieving directory listings as well as tags and branches for a given file (or directory), so that the release scripts don't have to base their data on post-commit hooks being tracked but can query CVS directly and still in a VCS-independent way. So, more work up for the CVS backend as well. Of course, if you look at it in a more optimistic way then you recognize that the same functions will help implementing the (eventual) repository viewer functionality for CVS :D

To infinity, and beyond!

Well, given all the workload that is mentioned above, it's going to be a tough schedule again, especially if I don't have the time that I was able to dedicate last summer. For the port of the release node integration (and release scripts) I'm relying on dww and hunmonk, whereas I still got to do a more advanced commit notification module (and some more stuff) for my late but ongoing university practical. Sometime later, we'll also want more fine-grained log/repository view permissions - I heard that request from a few people already - and write a unified solution for SVN/Git/Mercurial/Bazaar VCS user account authentication, as discussed in here.

Tons of stuff to do, you see. The good news is that you (yeah, ...you) can step up and make a difference! Whether that means porting aclight's hook scripts for Subversion to the new Subversion backend, or implementing the functions interfacing with CVS that are required for drupal.org deployment (thus speeding up the unmerciful destruction of cvs.module), or creating a module that synchronizes VCS users known to Drupal with the actual .htpasswd or SSH key files - there should be interesting stuff for everyone who wants to see Drupal shine as management and viewer tool for all kinds of version control systems.

Ok, enough of ongoing novel writing work, that should suffice for some time again :P

Revision Control Systems

Want issue tagging? We're now one step closer.

aclight@drupal.org — Mon, 18 Feb 2008 01:11:36 +0000

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

Webchick originally wrote a skeleton module called Comment alter taxonomy with the intention of allowing comments to nodes (including project issues) to add/remove/change the taxonomy term(s) assigned to nodes. I took her code from there and added the data storage capabilities to make it actually work. I've created the project and committed my working but not yet finished code at http://drupal.org/project/comment_alter_taxonomy.

I'd love to get reviews of this code as well as have people make suggestions of potential use cases for this module outside of project issues. Right now the module will work with nodes of all types but there is no capability to display changes made in individual comments outside of project issue nodes. Off the top of my head I can't think of how this would be necessary in other node types, but I'm sure some of you would have good suggestions.

I hope that once this module is complete and well tested that it can be deployed on d.o for use with project issues. I'm not sure what kind of implementation we'll eventually have (ie. free tagging vs. administrator created terms), but I think the functionality provided by this module could really improve the workflow in the d.o issue queue.

I've attached a screenshot of this module in action in a simple use case.

Here are the specific things that I'd like suggestions on:

Non project-issue use cases. How would you want changes to terms in individual comments displayed?
At the moment, this module disables editing taxonomy terms that can be altered by comments when editing (but not creating) a node. Likewise, editing of terms in a comment (but not when adding a comment) is disabled. These decisions were made to increase the integrity of the history of terms attached to the node. Will this be a problem in certain use cases?
When a comment that alters taxonomy terms is deleted/unpublished, the term changes made in said comment are not reverted. This behavior is different than how the project issue module treats changes in metadata (such as status) but is the same as how the Google Code issue tracker treats deleted comments. I'm not convinced that the current behavior is the most desired, but it turned out to be easier to code :)

For the sake of completeness, even after this module is finished there are still a few more steps that are necessary to make this useful:

To display the term changes in an issue, #219734: Allow theming of changes in project issue table and email needs to be finished.
To allow searching for specific terms within issue queues for a given project, I think we'll need to add on something to the current project issue tracking module, because I don't think it's possible to do this yet in its current state. The refactoring of project issue to use views (#76725) should help out with this.

Taxonomy

Help the Project* module! Help get aclight to DrupalCon Boston!

Alex UA — Wed, 06 Feb 2008 03:54:31 +0000

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:

Getting free tagging for issues (or at least tagging) up and running on Drupal.org. Depending on the final implementation, this new module will allow users with the appropriate permissions to change the taxonomy terms assigned to a node from within a comment on that node (example). Ever wanted to tag an issue with "newbie", "pgSQL", or "javascript" terms? This module will make it happen.

Comparing other issue trackers to get an idea of what we're doing right and where we have room for improvement. For example, I recently posted a thorough comparison of the Project issue tracking module with the Google code issue tracker.

I was one of the administrators of the Google Highly Open Participaton (GHOP) project. We've gotten students to complete about 120 tasks of various natures.

I was the mentor for two Project* related GHOP tasks. One task added automated creation of project issue nodes and comments, and one that adds a filter that turns issue node references in posts into links to the issue itself.

If you can, please help the project* modules, and help get Adam Light to DrupalCon Boston! If you'd like to know more about Adam, take a look at Webchick's Contributor Spotlight that featured Adam.

Issue tracking and software releases

User authentication in non-CVS repositories

jpetso@drupal.org — Tue, 29 Jan 2008 16:57:34 +0000

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.

Options for the administrator

Compared to the straight-forward approach of CVS, pretty every other version control system has a multitude of ways to access the repository. Both Subversion and all relevant distributed version control systems are providing SSH and HTTP(S)/WebDAV as proposed solution, and maybe even a proprietary protocol (svn://, git://) for quick private projects. Depending on the access method, that requires one or more of the following configuration options:

For the proprietary protocols, it's relatively easy. The git:// protocol doesn't provide any authentication at all (so it should only be used read-only) and Subversion has a simple text file that specifies users and their passwords - although this requires passwords to be stored as plaintext (baaad!) and is thus highly unsafe and not recommended as well. Might be the only choice for servers with many restrictions, though.
HTTP(S)/WebDAV requires configuration of Apache, which in turn can involve any authentication mechanism that Apache supports. The most widely used of these mechanisms is definitely an .htpasswd file... so that too would involve only one file to be maintained for user account management. This approach is also the preferred solution for Subversion, and for Subversion one can even have an even more detailed access control list that is stored in a separate file and controls how and which directories may be accessed by which user.
SSH (the preferred way of authentication for all the distributed VCS) is arguably the most difficult authentication method to administer in an automated fashion, as it normally involves creating real system users on the server, and assigning them the right privileges. When taking this approach, one would also need unique groups to each repository so that different project maintainers can write to the same repository. I imagine this insanely hard to manage and integrate this with Drupal.
As a further alternative when using SSH, it's also possible to retrieve users' ssh-keys instead of creating new system accounts and granting them shell access. There's a bit of effort involved in setting this up ("Shared SSH" docs for Mercurial, Gitosis daemon for Git) but once it's up and running, this should be easier on the administrator than the real system accounts.

Options for the Version Control API

As you can see, that's loads of possible ways on how to set up user authentication. I'm asking myself whether we should
a) try to support them all, and have a switch in each repository configuration that tells us which one to use (the most work intensive of all options), or
b) just try to support the ones that involve one or two files at maximum which can be generated automatically by a cronjob-called script, or
c) write up a howto that exactly explains how the admin has to set everything up, and depend on this, or
d) leave all of this crap to the site administrator and don't interfere with authentication at all - just provide the means to associate accounts with committer names and be done with it (current state of the non-CVS backends for Version Control API).

One more thing that might need further thought is the current per-repository view on accounts - with SSH's approach involving multiple users, it's much rather one user account on the whole server that enables access to further repositories. So instead of applying to each repository separately, there would be just one "SSH access" tab in user/*/edit instead of a "[repository] access" for each repo. And for distributed VCS, the "Commit access" tab on a project would not let one more directory through the access check but rather add or remove the user's system account to the user group of the repository.

The discomforting thing is that there's so many possible combinations, some behaviour depending on how they're combined, and that many of the differences are not even similar between multiple usages of the same VCS (or backend, for that matter). I can't tell the answer to all of that, just wanted to have everything written up in one place so that people with good ideas have a grasp of the scope of this issue. As always, input is highly appreciated.

Revision Control Systems

Commit restrictions in distributed version control

jpetso@drupal.org — Tue, 29 Jan 2008 16:47:17 +0000

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 those who are not totally familiar with the CVS access control scripts, they're currently doing two things basically:
1. They only allow the commit to happen if the commit location is part of those projects where the user is registered as project maintainer. In addition, sandbox commits are allowed to every CVS account owner.
2. They forbid non-standard tag and branch names.
3. Not implemented currently, but would also be possible: checks on the code itself, say, for making sure that the code adheres to coding standards or satisfies all unit tests.

Is it necessary?

Now, repository layouts work very differently in distributed version control: instead of having a huge repository where everybody commits to, there are usually lots of small repositories for each project. That kinda makes 1. obsolete: users don't have commit access to other projects anyways because those are contained in wholly different repositories. Also, users would probably have their own sandbox as separate repository, or even more probable, they'd have a separate repository for each of their sandbox projects.

As for 2., controlling branch and tag names needs to be done in CVS because branches and tags exist repository wide, so granting users more freedom on that would cause chaos all over the whole repository. However, in distributed version control, branches and tags are always local to the respective project and can easily be deleted too (which means that the chaos won't appear without active maliciousness of the maintainer), so this main reason for restricting branch and tag names does not apply here.

Of course, branch and tag names are also used on drupal.org for determining how release tarballs should be named, and restricting names means that one can rely on the fact that each branch or tag can be transformed into a release name (and subsequently be released). The folks on #git didn't consider that alone a good reason to disallow branches and tags that are differently named, and indeed the lack of super strict name control could enable more possibilities for developers, the most prominent one being feature branches that can be developed in the open before being merged back into the master or stable branch. This wouldn't hurt other projects or developers - the only precondition is that the release scripts don't try to package everything but only consider tags and branches with "release compatible" names.

Which leaves us with 3. as the only remaining "valid" justification for access control, and doing it for just this purpose been countered by the people on #git with a couple of points:

Stuff like style checks can be done locally in the commit hook instead of server-side on receiving the commits. The latter would be a problem anyways as there are many potential commits in a "push" operation, and if, say, the first one is "invalid" then all the rest of the locally committed changes has to be reverted and redone. Not good.
If people intentionally remove the commit hooks from their local repository copies, they don't deserve project maintainership and their commit access should be revoked anyways.
Running unit or compilation tests on each commit is likely very hard on the server, and would be better suited to run as cronjob (together with a "dashboard" to report errors or other issues).

Conclusion

So, overall, the design and workflow of distributed VCS makes a good point against pretty much all of the arguments why access control scripts would be needed for those repositories. drupal.org is already one of the most restricted repositories that I know of, and if we could get by without these measures then anybody can. (Also mind that admins and organizations that disagree here could still do all of these access control checks, of course - it just wouldn't be integrated with Drupal.)

Revision Control Systems

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

aclight@drupal.org — Sat, 26 Jan 2008 22:07:39 +0000

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.

Project issue tracking module

Basic issue tracking

To create an issue on drupal.org, a user clicks the Create menu link and is taken to a form with several fields to fill out, including the Title and Body of the issue, as well as several issue metadata fields such as Project, Version, Component, Category, Priority, Assigned, and Status. At the top of the form is an area where the project's maintainer(s) can add some instructional text to remind users to search before submitting or anything else (Figure 1).

Figure 1: Creating an issue

All issues have a table displaying the current metadata values for the issue at the top (Figure 2). Notice also that issues can have links, code highlighting, and other features which are all provided by various input filters. At the bottom of each issue is the comment form where a user can update the issue or provide feedback on the issue as necessary (Figure 3).

Figure 2: Issue display

Figure 3: Issue comment form

The Project issue tracking module provides an overview table that displays some of the important information about many issues at once (Figure 4). The displayed issues can be filtered by the project the issue is associated with, the status of the issue, the category within the project that the issue relates to (eg. Code, Documentation, User interface), and the priority (eg. Minor, Normal, Critical). Issues of different statuses are color coded for quick identification. Issues can also be sorted by the displayed criteria by clicking the table header links.

Figure 4: Issue table

A link from the issues overview table takes the user to an Advanced search page, on which the user can search for issues that meet many different criteria (Figure 5). A link to the issue subscription interface is also on the overview table. Users can choose to subscribe to None, Own issues, or All issues for any particular project (Figure 6). A subscription to an issue means that the user will be notified via email whenever a new comment has been posted to a given issue, or when a new issue has been created for a given project. Own issues are issues which a given user created or has commented on. Therefore, if one wants to subscribe to an issue, he has to post a comment to the issue, even if the comment is as simple as "Subscribing".

Figure 5: Advanced search

Figure 6: Subscription options

Administration

Project maintainers have permission to edit their project(s), and from the edit page there is an Issues tab. The maintainer can add additional categories that will be available for users to select from and can also add text that will be displayed in a box above the submission form for all new issues (Figure 7). Finally, the project maintainer can choose to have e-mail messages sent to an address and/or have a list of all critical issues for the project sent weekly to an address.

Figure 7: Project maintainer issues settings

Project administrators (who are often also administrators of the entire site and not just one or more projects) also have the ability to create additional statuses (Figure 8). Administrators also have the ability to specify the default status (all new issues have this status, unless the submitter changes it to something else), and to specify which statuses should be included in the query that results in the default issues table discussed above.

Figure 8: Project administrator statuses

Google code issue tracker

Basic issue tracking

The Google code new issue form is a bit simpler than that created by the Project issues module (Figure 9), because Google stores most metadata by using Labels instead of having separate fields (I'll go into this in more depth a bit later). There is a Summary field (analogous to the "Title" field in Project issue tracking) and a Description field (same as the Body field). Once nice thing is that by default the description text area is prepopulated with a template that in many cases might lead to the user providing a more useful bug report, etc. The text of this template can be set by an administrator (see below). The owner and status metadata fields are separate fields, and then a user can add one or more labels to describe the issue. One nice feature is the yellow star, which (somewhat confusingly) means that a user is subscribed to that issue and will receive e-mail updates whenever a new comment is added to that issue. Any user can click or unclick the yellow star to toggle their subscription status to that issue.

Figure 9: Google tracker: Create issue

When viewing an issue that has already been created, the Google code tracker has a similar look to the Project issue tracking module with a few exceptions (Figure 10). The issue metadata is on the left and a bit more separated from the similar Project issue table, but a similar result could be accomplished via Drupal theming. More notable is the complete lack of HTML or links in the issue description. Issues all have Prev and Next links at the top which allow a user to first create a list of issues via some query and then go through them one by one. Another big difference is that, unlike with Project issues, it is not possible to edit an issue or comment using the Google code tracker. Some might argue that this is desired so that once something about an issue is created it can never change. However, the downside is that minor typos, etc. cannot be corrected easily. Just like with the Project issue tracking module, the Google code tracker highlights any changes to issue metadata made in comments.

Figure 10: Google tracker: Issue

As with the Project issue tracking module, the Google code tracker provides an overview table with listings of multiple issues at once (Figure 11). Searching for issues is very easy and fast (not surprising considering we're talking about Google). A drop down menu next to the search box allows one to search for open issue, all issues, etc. The search box allows for searching by metadata as well (eg. a search for "status:open filter" would return all open issues with the word "filter" in the body or title). An advanced search link provides an interface to restrict the search to certain words and works in a similar way to the advanced search provided by the Project issue tracking module.

Figure 11: Google tracker: Issues table

As I mentioned before, once nice feature of the Google code tracker is that any CamelCase label with a hyphen is interpreted as a category for the purposes of display in the issue listing table. The ClaimedBy, DueDate, and DrupalIssue columns are all generated by adding labels such as "ClaimedBy-kourge", "DueDate-2008-01-15", and "DrupalIssue-123456" to individual issues. An individual user can add one or more of these CamelCase fields to his table view by clicking on the "..." in the upper right corner of the table (Figure 12).

Figure 12: Google tracker: View additional columns

At the upper right corner of the table a user can select the Grid view, which displays issues with one attribute along the X axis and one along the Y axis (Figure 13). Individual issues can be displayed by issue number (see photo) or by # of issues or title of issue. Such a view makes it easy to see at a glance how many issues with each status each user has.

Figure 13: Google tracker: Grid view

Administration

For users with access to administer a project's settings, it's easy to set different status values and to define which values are considered to be "Open" and which are considered to be "Closed" (Figure 14). It's also possible to predefine labels and to give each a description so that users are more likely to select the appropriate label(s) when submitting issues or comments. It is possible to specify label prefixes that can be used at most one time on any individual issue (eg. "ClaimedBy"). Finally, as mentioned above an administrator can set the default template text for issues of different types, and can also set the columns and sort order of those columns that are used in the issues table view (Figure 15).

Figure 14: Google tracker admin: Labels

Figure 15: Google tracker admin: Columns

Direct Comparison

Project issue tracking module

Pros
1. Ability to edit issues and comments
2. Input filters can be used to allow HTML code and links
3. Good use of color in tables listing issues makes it easy to get a sense of the number of issues of various statuses (such as code needs work, review, fixed, etc.)
4. Open source, can be modified as desired, can be run on your own site
5. Issues and contributions across all projects by a specific user can be monitored in one place
Cons
1. Adding additional types of metadata requires coding and even then is not easy
2. Fixed issue listing table does not allow user to view additional fields
3. Impossible to subscribe to individual issues without posting a "Subscribe" comment
4. Impossible to unsubscribe to individual issues
5. Free tagging of issues is not possible
6. Some administration options (such as the possible statuses) are per-site, not per project

Google code tracker

Pros
1. Search capabilities are very good and robust
2. Additional metadata fields can be created using "CamelCasePrefix-value" labels
3. Tables can be customized by individual users as well as project administrators to display the most useful fields
4. Subscribing and unsubscribing to individual issues is quick and does not require creating a comment in the issue itself
5. All configuration options are per-project, not per site
6. Since it runs on Google's massive server farms, search and use is usually very fast
Cons
1. No editing of issues or comments makes it impossible to correct typos, etc.
2. Lack of links and code filters makes it difficult to display certain types of information, such as code, in a user friendly way
3. Closed source and cannot be used off of code.google.com
4. No RSS feeds of issues (as far as I can tell)
5. No cross-project tracking/monitoring of a user's individual issues/comments

Recommendations

From the list of pros and cons above, it's probably pretty clear that I feel that the Project issue tracking module has room for improvement. However, I do want to point out that I feel the pros of the Project issue tracking module are much more important than the pros of the Google code tracker. In my opinion, the lack of links and code styling in the Google code tracker is a significant usability hurdle. For GHOP this wasn't too big of a deal because there wasn't the need to post code in the tracker very often, but for regular development this would be a deal breaker, in my opinion.

Looking at the cons of the Project issue tracking module (and the pros of the Google code tracker), most of the items fall into three categories: viewing lists/tables of issues, subscribing/unsubscribing to issues, and categorizing/tagging issues.

Viewing lists/tables of issues

As specified in the Project* roadmap for D6, the planned conversion of the issue queues into being Views enabled (#76725)will be a big step forwards in terms of allowing for more customization of the listings. The code in the Project issue tracking module that currently handles these queries and display of the data is very much legacy code and it is extremely complicated. Offloading this onto the Views module should help to greatly simplify a key part of the module.

Subscribing to issues

The Subscriptions module has recently been rewritten and is currently in beta testing. Using the Subscriptions module (#34496) instead of the code currently built into the Project issue tracking module could be a great way to provide added subscription options while at the same time allowing us to rip a good chunk of code out of the Project issue tracking module. On a related note, the Views Bulk Operations module might provide a way to mimic the ability to subscribe/unsubscribe to an issue while viewing a list of multiple issues. [Edit: dmitrig01 has suggested that the Views Bookmarks module may be useful for this purpose as well.] [Edit again: In Drupal 6, Views Bookmarks has become the Flag module.]

Categorizing/tagging issues

I am currently working on a patch to the Project issue tracking module (#187480) that will soon allow the use of free tagging vocabularies on drupal.org and on other sites using the Project issue tracking module.

Conclusions

While I think there are many ways in which the Project issue tracking can be improved, it is clearly a very useful tool at the moment and will only become more useful in the near future. I'd like to get feedback from others who are familiar with the Google code tracker to find out if I'm missing pros or cons of that system. Comments from GHOP students and other administrators would be especially helpful since these users have been intensely involved with both trackers recently.

Suggestions are always appreciated, but your contributions are even more valuable. You can start by reading the Project* roadmap for D6, because there's still a lot to get done there.

Issue tracking and software releases

Project issue 5.x-2.0 release worksheet

hunmonk — Tue, 15 Jan 2008 16:30:15 +0000

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

Bugs:

~~http://drupal.org/node/210256 -- auto closer broken when anon can't access issues~~ Fixed on 2008-01-16
~~http://drupal.org/node/89673 -- project issue to link filter, causing segfaults on d.o~~ Fixed on 2008-02-04
~~http://drupal.org/node/196478 -- changes to project don't appear when previewing a comment~~ Fixed on 2008-01-21

Low-hanging fruit (none of this has to be done, but a lot of them look pretty easy):

~~http://drupal.org/node/200097 -- Remove duplicate code for issue attribute labels~~ Fixed on 2008-01-19
~~http://drupal.org/node/162760 -- add pager/tablesorting to project/issues/statistics~~ Fixed on 2008-01-20
~~http://drupal.org/node/138054 -- Include comment numbers for issues in email~~ Fixed on 2008-01-21
~~http://drupal.org/node/151984 -- display the initial issue metadata with the initial issue post (This might be easy thanks to the schema used with IFAC, right?)~~ by chad: displaying the data would be easy, but deciding the layout is going to require some discussion, and probably some alteration of the existing design of the page, so i think this is out of scope for 2.0

Issue tracking and software releases

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

mikey_p — Wed, 26 Dec 2007 23:07:10 +0000

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.

They are designed with too specific a project system in mind, and are not ultimately extensible.

Project module and it's family are designed mainly to run drupal.org, and it does an amazing job at it. However project attributes are not easily modified or extended. I know that dww has taken on what is no doubtly the most crucial element to the entire Drupal project[1] with this module, and he has made amazing progress with it. However, one constraint to this awesome capability is that new and advanced features...no that's not right, dww and crew and getting tons of new features and such into project, the issue I'm noticing, is that features that wouldn't be used on d.o, are less likely to be committed. This is no fault against the project maintainers as they are already plenty busy, keeping up with the necessary features for d.o. Don't get me wrong here, Project* is amazing, and I'm grateful to the maintainers, however its very requirements but some limitations on it. (of course I know that I am welcome to submit patches to project*, but I fear that would just place added burden on the maintainers to review and commit them)
Enter Casetracker. It's newer and seems shiny and featured packed at first glance, but once again it ultimately fails in terms of extensibility and features. As in most cases of Drupal modules, it begins with a fairly specific task in mind, becomes more configurable, but ultimately doesn't give the user all the options they desire.
Taslklist and Tasklist advanced are another option, designed for more personal level. There's some good stuff in these, but they just aren't designed for the same type of collaborative uses, and extensibility that casetracker and project* are. And they suffer the same problems that project* and casetracker do as well.

My solution to this problem as I keep trying to write new glue-modules to tie functionality between all these, is that I need to just stop and rewrite the whole module from scratch to do what I need. This will solve all of these problems once and for all. At least as far as I'm concerned anyway. But surely, I've realized, someone must have had the same conclusions I did? And their module to solve all these problems would be different from mine wouldn't it? What do we do in Drupal when we start having several projects covering similar and duplicate functionality?

An API you say?

Enter the idea of what I have termed the TaskAPI (could just as easily be Project API, but that seemed to close to existing project*). Why not write a module that handles helper modules to assign project attributes to a node, and their display and then a module to display all that content different ways? Finally, extensible project/task management!

For the uninformed, I've just summed up CCK/Views rather well. They already do this. There is already an issue to convert Project* module to CCK and it's being written to use Views as we speak. So is that it? Can we already to everything we need with other Drupal modules? Pretty much. I'd even say for probably 80% of sites out there (maybe more) CCK/Views can do almost all of their custom content needs. So is that the end of the TaskAPI? I don't think so.

Actually I think it is still needed now, more than ever, as the glue between all these modules, and to provide the ability to hook, non-data, non-display task behavior to tasks through various means. I can't explain that very well at the moment, but I already have several use cases, that would not work well, with just CCK/Views. Also, some new field types/formatters may be needed, maybe not. I'm not even sure of all the functionality that the TaskAPI would provide, other than to be widely extensible.

So now that the idea is out there, I'd like thoughts and ideas on it. Specifically, what behavior would you add to CCK/Views to have your dream task manager? Is there interest in this type of project? Would anyone like to contribute? Finally, if this model proves to be successful, what would have to be done, in order to make it a central API to extending Drupal? Would project* or casetracker ever require the Task API?

Please note, that while currently no code exists in the repository, or my sandbox on this, that doesn't mean that it hasn't ever been attempted. This article is the summary of 3 attempts to provide the basic functionality described. Once, I tried hacking casetracker and organic groups to get the functionality I required, another time I built a site specific module to combine functionality which didn't really work. The last attempt, was a generic Casetracker/Organic Groups integration module, which I intended to release, but the features just weren't workable, without hacking Casetracker or Organic Groups. This time around, I'm trying to get input, and advice from the community, and I am trying to assess which current codebases could be workable to modify as well.

So let me know what you think!

[1] Without Project module and it's family of helpers, drupal.org wouldn't have an issue queue, and all development on Drupal itself would grind to a sudden halt.

Project Management

Unified solution to current problems with project* and update_status

dww — Mon, 03 Dec 2007 00:40:02 +0000

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.

Existing problems

Basically, all of the above boils down to two things:

The logic in update_status where when it decides to warn admins to upgrade.
The project node UI.

Fundamentally, the problem is that the notion of the "recommended version" is being overloaded to mean too many things:

The version new users are suggested to download via the project browsing pages.
What you see on the front page of the project node.
If people should drop an older release and upgrade because their series is no longer supported

Proposed solution

After thinking about it more, I believe there's still value in the notion of a single recommended release for each core API. However, this needs to be more strictly defined. It should only mean "what version the maintainer thinks new users should download". So, this will be the single release listed with the project teaser on the various browsing pages. This will also be marked as such in the project node and update_status UI. However, update_status will NOT automatically warn you to upgrade if you're running a different version. update_status will only warn you if your release is specifically marked as insecure, abandoned, or unpublished.

So, all we need is:

Add 2 more terms to the "Release type" vocabulary on d.o: "Insecure" and "Abandoned".
Fix update_status logic accordingly.
Use the dev snapshot release nodes to represent a "release series".

I think point #3 would actually make some of the project_release code make more sense, and I believe it'd simplify the project admin UI. If you marked a given dev snapshot node (release series) with "abandoned" or "insecure", we could update all the release nodes from that series the same way. Plus, on the project release editing page, all the series would be listed, so they could mark which ones are recommended for each core, which ones are visible on the project node, etc.

project* would still automatically update the download links and release table stuff with the right version from each series, so admins would still get that for free instead of introducing any more manual effort to the process.

That probably sounds like a lot, but I suspect I could pound out this code in the order of hours, not days. Especially if there was help with reviews, testing, documentation and support, I think this is totally doable in the very near future.

Any comments, suggestions, or volunteers? Please comment here! ;)

Thanks,
-Derek

(With slight edits by Edward)

Issue tracking and software releases

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

dww — Fri, 30 Nov 2007 18:37:51 +0000

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.

Project

~~http://drupal.org/node/155697~~ fixed 2007-12-22
http://drupal.org/node/185354 (This issue is marked as closed but is really a bug fix for how #155697 was originally committed. So, when backporting #155697, be sure not to make the same mistake so that we can leave #185354 closed instead of having to backport that, too. ;) Thanks!) fixed 2007-12-22
~~http://drupal.org/node/169841~~ no fix necessary
~~http://drupal.org/node/196247 "Project registers the same menu path multiple times"~~ fixed 2008-01-06
~~http://drupal.org/node/126554 "edge cases in edit/releases tab on project nodes: default release broken"~~ hunmonk: Postponed pending http://drupal.org/node/203313 -- and i suspect that this is a d.o specific problem, anyways.

Project issue tracking

~~http://drupal.org/node/36619~~ Fixed 2008-01-01
~~http://drupal.org/node/44833~~ Fixed 2008-01-01
~~http://drupal.org/node/104583~~ Fixed 2008-01-01
http://drupal.org/node/112909 Fixed awhile back
http://drupal.org/node/140473 [aclight: I will take care of this once #200097 gets committed.] hunmonk: this doesn't deal w/ the 5.x-1.x releases, so it probably shouldn't be on this page.
~~http://drupal.org/node/157512~~ Fixed 2008-01-01
http://drupal.org/node/200097 [aclight: I will take care of this when we figure out what cases to use, etc.]hunmonk: this doesn't deal w/ the 5.x-1.x releases, so it probably shouldn't be on this page.
~~http://drupal.org/node/206502 "improper or missing uses of project_issue_category() causing translation bugs"~~ Fixed 2008-01-06

Issue tracking and software releases

project module, issue followups as comments -- needs testing

hunmonk — Tue, 23 Oct 2007 06:10:05 +0000

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)

This is also an important step along the road to porting project* to Drupal 6 (which has to happen before we officially release Drupal 6 -- see http://groups.drupal.org/node/6180 for our current project* roadmap).

We're at the final stage now, and need your help testing the UI and reporting any bugs you find. To make things super easy, I've configured http://project.drupal.org with the new code, so you can simply go there to perform your testing -- this is a clone of drupal.org, so your regular username and password will work fine there.

Couple of things to keep in mind:

We're looking for bug reports and UI tweaking suggestions. If you have a feature request or other major structural suggestion, you're about two months too late, I'm afraid... ;)
If you have admin privileges, and you'd like to see what the site looks like from an auth user's perspective, you can login with user: test, pass: test
If you're surfing old issues, be aware that the file links will give you a 404, b/c the files aren't on that server.
If you find a bug, or have a UI tweaking suggestion, please first search for an existing issue at http://drupal.org/project/issues/project_issue, and file a new one if you don't find yours reported already.

If you have any questions, find me in #drupal.

Thanks, and happy testing!

hunmonk

p.s. Thanks to chx for the original IFAC code, and to dww for the extra guidance and help along the way...

My 2 Pence

I may be a total d*a, but I could not find a difference to the old surface - apart from it being muck quicker. So change has taken place behind the scenes? What I somehow miss is a possibility to rate modules right in the place of the project page. Nonwithstanding my lack of knowledge: wouln't that be the place to do it?

Thomas

Issue tracking and software releases

Getting data offline

fgm@drupal.org — Thu, 18 Oct 2007 15:27:14 +0000

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.

Issue tracking and software releases

Post-SoC progress

jpetso@drupal.org — Mon, 24 Sep 2007 09:00:41 +0000

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.

Backends can now provide import/export functionality for accounts in a given repository.
Added blocks for "Most active developers" and "Most active projects".
The account list is now paged and can be filtered by account status and repository.
Small new features that went into cvs.module have been ported to the Version Control API, namely Postgres support and an external cron script that prints out exported accounts.
More straightforwardness for having multiple repository registration pledges. (You know, the "I want to maintain a module, theme or translation" and "I'll put it under the GPL" ones.)
A small feature that allows branches and tags to be created only in specified directories.
RSS output that rocks.
More phpdoc friendly API documentation.
In the project node integration module, only unpublished projects are now retrieved by default.
(Optional) project.module specific code for only allowing project directories if they match a project type (e.g. Modules, Themes, ...) specific regexp.
Added a 'message' property for tag operations, as CVS seems to be the only version control system that doesn't support this.
The "authorization method" (which specifies if and how you can create new accounts in repositories) is now a per-repository setting instead of a global one. That means it's now finally possible to have a Drupal core repository where only admins can create new accounts, and a contrib repository that requires applications and approvals. In order to keep the code sane, I dropped the site-wide application for access to all repositories, but the admin-only mode should more than make up for this minor loss, imho.
A bit more caching, and tons of bug fixes.

Quite a lot, right? Looking through this list, it now finally occurs to me why I spent less time on earning money and more on getting Version Control API up to speed ;-)

Some of these changes also involved changes in the table structure, and while I had released a few beta releases, they didn't include automatic upgrade paths. That's now a thing of the past since I pushed out the first release candidate (5.x-0.9-rc1) yesterday. Starting with this one, there will be update functions in case something changes (which I believe will not be necessary for 5.x anymore).

Way to go

You might remember the list of missing functionality from the SoC wrap-up part 2, and it got a lot smaller. Most of the improvements mentioned above were part of the "Minor bugs and TODO items" bullet point, it seems those were not so minor after all :D ...anyways, those are now done, and the items left are now really the only ones that need to be done still. Right, that's a good thing.

That is... in the Project UI redesign BoF session at DrupalCon, I noticed that project.module itself also contains two (small, but still) features that need to get imported into the project integration module as well. So that leaves five missing features until we'll have covered all the existing version control related functionality. This time, it's really only those five ones (three of them carried over from my last post):

Release node integration. (Yeah, you know that one already.) Still not done, still critical, but rumour has it that the notorious dww has agreed to take this on. And that's a great thing, because I can now see a real chance for Version Control API being rolled out on drupal.org.
Commit notification mails. You might have noticed that this hasn't been a top priority for me, but as the more important stuff has been taken care of, it seems very probable that this is getting implemented soon now. Done.
CVS log parsing. Probably the next thing I'll tackle, assuming I can obtain a decent log file for testing this stuff. Done.
Port the "Developers" page from project.module. There might be changes to this page anyways, but for now I find it most important to get a plain port of everything and worry about user interface improvements later on. Together with this feature, I'm pretty sure that this time I'll not get around implementing a commit statistics API function, which is the real meat of this feature. Done, and also the user page integration that I also missed at first.
Restrict project creation for users that don't have a version control account. Which will be optional, of course, controlled by some checkbox in the settings. Done. For better usability on project.module, there's also this additional patch.

When all of these are there, we're going to have a 1.0 release. Nice, eh? But wait, it's even getting better!

World news, world news

Goodness #1. Well you probably noticed already, but Derek stated his intentions to deprecate cvs.module starting with 6.x, and having Version Control API plus the CVS backend as the official replacement. Which is teh awesome! w00t! (Also mentioned in the Project* roadmap for Drupal 6.)

Of course, this means that I can't wait too long with the Drupal 6 port of Version Control API & friends, so this is going to be one final considerable effort until we're, er, "officially done". (?) But I believe some more effort in the short term will pay off for drupal.org, Version Control API and everyone else.

Goodness #2. In my continued effort to abuse official sponsoring for my own personal interests, I've been able to attain a university practical where I will implement a Subversion backend plus some other, more high-level (workflow-ng powered) commit subscription stuff. Coached by Univ.Ass. Amin Andjomshoaa. You can also spell him without the "d". So, good stuff is coming!

Best DrupalCon ever (tm)

Yes, I've been to Barcelona too. It's a unique experience somehow, exciting and a bit scary at the same time. (Of course, the excitement clearly prevails.) Lots of interesting talks, a two-part BoF, and most of all a number of new people that I encountered there. You know who you are! The only drawback was that neither Derek nor Andy were able to get there, but you can't have everything. I came home yesterday, and am still trying to get back to normal life :)

...and on a totally unrelated note...

Maybe I should register my blog with Planet Drupal, but as I haven't yet done so and still need to get the news out:

Filefield 2.0 has been released! Whoo! Like, er, ... "Filefield 2 - upload your files with style."
Or something.

...you know, I should really get a life now. See you!

SoC 2007