On Wed, Apr 3, 2013 at 6:41 AM, Andrej Golcov <[email protected]> wrote:
> Hi everyone,
>
> I spent some time investigating possible solutions for BEP-0006 Ticket
> Relations [1]. So far I can see two real candidates for adding the
> functionality into Apache Bloodhound: MasterTicketsPlugin[2] and
> TicketLinks [3]. I don't mention "write from scratch" intentionally
> ;).
>
> I'd like to summarize my feelings regarding candidates in a few words
> (IMO).
>
> - MasterTicketsPlugin - currently, only "blocked by/blocks" relation
> is supported but, as far as I understand, there are plans to include
> parent/child ticket functionality. Integration with UI is implemented
> via ITemplateStreamFilter. I have feeling that the plugin code should
> be forked to be BH friendly (maintaining Trac and BH compatibility can
> be hard at the beginning) with theoretical possibility of merging Trac
> and BH specific codebase later. It will be nice to have code as part
> of Apache BH to avoid possible compatibility and installation
> problems, but, IIUC, it is still open if we can get code grant to
> include source in our repository.
>
> - TicketLinks - introduces Trac code changes on branch. Designed with
> different ticket relations in mind. Code quality is good and covered
> by unit-tests. My understanding is that code is accessible under the
> same license as Trac and can be copied into Apache BH repository. From
> proposal wiki page [3]:
> {{{
> The approach from this patch was preferred over the ones from existing
> plugins (TH:MasterTicketsPlugin, TH:SubticketsPlugin,
> TH:ChildTicketsPlugin) as none was providing a really extensible
> starting point, in the spirit of #31. The first two use a specific
> table dedicated to the relation they're dealing with (respectively
> mastertickets(source, dest),subtickets(parent,child)), and the latter
> is using a parent custom field. That is not to say there are no
> interesting ideas to lift from there ;-)
> }}}
>
> Personally, I would take TicketLinks code and extract it as BH plugin.
> Changes in Trac core should be minimized to a couple of interfaces
> that could be potentially accepted by Trac community.
>
> What do you think?
>
> If we want having ticket relation feature in 1.0 release, it is time
> to start code integration soon.
>
I did not look at the TicketLinks solution when starting work on the
MasterTicketsPlugin, so maybe I should give that a closer look. If it is
the better candidate, we should go that with it.
I'll push my integration of MasterTicketsPlugin with SubticketsPlugin to a
branch latter today in case we want to give that some closer consideration.
