[development] forking issue tracking development

[Derek Wright]

On Dec 17, 2006, at 1:32 PM, Michael Favia wrote:

> I think that a hybridization of the two (CT + Project) could also be
> beneficial if we were able/willing to refactor the code management and
> release aspects of the project module out into new modules.

- release management is entirely separate already  
(project_release.module)
- code management is mostly separate already (cvs.module)
- the code management separation isn't the most elegant/slick/hook- 
ful in all of drupal, but it's getting better...

> At the foundation i think these two can serve the same purpose from a
> consolidated foundation with a bevy of associated modules for improved
> customization for the task at hand.

agreed.  this has been my goal all along, and is why  
project_issue.module is a separate module now, too.  again, the  
separation isn't ideal (and in fact, is currently broken such that if  
you turn on project_issue, you actually need to enable both project  
*and* project_release (tee hee) -- but that's an easy fix[1]) but  
it's getting better, and i'd like to keep moving it in that  
direction.  once D5 porting is done, my next big priorities for  
project_issue.module are:

= convert issue followups to real drupal comments [2]

= better OG integration (extending my og_project.moudle) [3]

= make it so you can configure what node types should act as your  
"project" so that you can use project_issue with things other than  
project.module (much like casetracker already does). [4]  basically,  
define your own CCK "project" type to be whatever you want, and  
attach a project_issue-provided issue queue to that.

= optional views integration [5] (i.e. a separate module we won't  
enable on d.o, but that exposes issues to views).  possibly similar  
workflow/actions integration add-ons (once i start playing with  
workflow and/or actions and see if it's worth doing).

> The ability to add code management and release capability,

see above, you basically have this now.

> or maybe to disable one mail module and enable
> another that enables MIME HTML, etc.

sure.

> It would require a small amount of concession from each side but maybe
> its time to select the best feature sets from each and move forward?

this is *exactly* what i've been trying to do with the monolithic  
project codebase for most of the last year.  split it up into  
smaller, more grok-able parts that handle 1 aspect or another, and  
allow the parts to optionally extend the whole as needed.  i'm all in  
favor of making it so these optional parts could be shared between  
project and casetracker, if that wasn't going to require massively  
more work or more ugly code.  in many cases, allowing this would  
probably force more elegant, hook-ful design, instead of project- 
specific hacks.

cheers,
-derek

[1] http://drupal.org/node/97095
[2] http://drupal.org/node/18920
[3] http://drupal.org/project/og_project
[4] http://drupal.org/node/85049
[5] http://drupal.org/node/76725