bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Ollos <>
Subject Re: Proposal: Ticket relations
Date Mon, 04 Feb 2013 19:06:00 GMT
On Sun, Feb 3, 2013 at 11:06 PM, Branko ─îibej <> wrote:

> On 04.02.2013 06:21, Ryan Ollos wrote:
> > I'm maintaining the MasterTicketsPlugin now and I was working on
> > adding parent-child relations support as well. I lost a few patches in
> > my working copy when my VM became corrupt earlier this month, but I'll
> > work to get those recreated and push out a new version of
> > MasterTicketsPlugin that has some critical fixes and parent-child
> > relation support. I see no problem with adding multi-product awareness
> > to the plugin in a way similar to what Olemis did for TracPastePlugin.
> How about donating the MasterTicketsPlugin to the ASF, as part of the
> Bloodhound project? This depends of course on a) whether you want to,
> and b) whether you /can/ (e.g., you'd have to get permission from all
> the contributors in order to re-license the code).

That is an interesting idea. I'm certainly not against it. There is only
one other author besides myself. I've been in touch with him recently and
from another discussion I can say that he is fine with the Apache license.
He moved the plugin from trac-hacks over to GitHub, presumably because he'd
rather work with Git than SVN, but since he's not actively developing it
anymore then it probably won't be a factor.

I'll get in touch with him and perhaps even pull him in to the discussion
in this thread.

That way, you'd get the best of both worlds -- the plugin can remain
> stand-alone in the sense that it can be used without BH, yet we'd have
> enough control (and enough coders) to make it the sort of comprehensive
> ticket relations thing that BH needs.

I can also add additional contributors to the project on GitHub, or we can
pull it back to Trac-Hacks, so one way or another we'll find a way to get
additional contributors on the project. So if anyone wants immediate access
just let me know, and in parallel we can continue to pursue this idea of
moving the project to Apache.

> Just a suggestion, of course; there can be any number of valid reasons
> to reject it.

I have some more questions on how this would work, but let me give it some
more thought while I check whether the original author would support the


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message