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