[development] forking issue tracking development
drupal at dwwright.net
Mon Dec 18 00:31:25 UTC 2006
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
- 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) 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
= convert issue followups to real drupal comments 
= better OG integration (extending my og_project.moudle) 
= 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).  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  (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.
> 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-
More information about the development