bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Ollos <>
Subject Re: Tests and CI (was: A word on Release 2)
Date Wed, 10 Oct 2012 13:26:31 GMT
On Wed, Oct 10, 2012 at 1:27 AM, Peter Koželj <> wrote:

> This my get a bit off topic...
> I agree that testing is important, and we probably agree that testing is
> hard.
> In fact a good comprehensive test of a feature can take more effort to
> write and maintain that the actual code that implements that feature. So if
> plugins do not provide it's own tests and we need to write and maintain the
> tests for them, the benefit of using them get's smaller.
> And if I dare to get a bit more of topic, I still need to come to terms
> with the idea that such a core functionality as ticket relations or multi
> products needs to be a plugin or even worse an external plugin! With all
> the features I would like to see in a issue tracker, I just can not imagine
> how this will work without complex inter-plugin dependencies,
> extremely cooperational plugin authors and last but no least, all the time
> in the world :)

I agree that you may not want the critical Bloodhound functionality to live
externally, and to rely on developers not involved with the Bloodhound
project to maintain it. It might be better to have any critical
functionality be written as a plugin that lives in the Bloodhound
repository. The idea of the functionality not being a plugin is more
difficult for me to imagine.

If Bloodhound is not going to permanently fork from Trac (i.e. never merge
in changes from the Trac core), then Trac is still external, and any
functionality is likely to be written as as plugin (i.e. a separate module
that inherits from Component) for Trac,  which should have tests, and
specifically integration tests. Not writing it as a plugin means you are
just modifying existing Components in Trac (such as trac.ticket.*) to
provide your functionality, and this would make merging from the Trac
mainline more difficult, and in which case the tests potentially become
even more important.

A feature like ticket dependencies could be written as a plugin (i.e.
Component) that is maintained within Bloodhound and is always enabled in
the Bloodhound core, which might get around some of your concerns about
relying on one or more external plugins to provide critical functionality.

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