bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <>
Subject Re: Tests and CI (was: A word on Release 2)
Date Wed, 10 Oct 2012 15:22:26 GMT
On 10/10/12, Ryan Ollos <> wrote:
> 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.

Well . The real benefit is that we'll be able to sleep at night
knowing that if some change is introduced (Bloodhound core ,
trac-hacks , plugins ...) and causes some trouble then we are just one
day away to figure it out ... especially if CI is installed .

For me the benefit exists , but we certainly need to assess the
additional workload involved and write tests when necessary .

>> 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

Notice that we are plugin maintainers of many plugins @ t-h.o , so no big deal

... and I swear I'll cooperate with Ryan as long as at any given time
the number of test cases he writes is smaller than those I wrote ...

>> and last but no least, all the
>> time
>> in the world :)

Oh no ! No way . Exactly the same time as we were doing it using a
plugin delivered by Bloodhound itself . In case plugin maintainers are
not responsive and not willing to grant maintainership ... is not a
chaos ... we can fork the project if there's a merit

> 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

Indeed , we *NEED* plugin authors . There's no community without them

> The idea of the functionality not being a plugin is more
> difficult for me to imagine.

definitely sure . Trac itself , I mean the core (tickets , vcs , ...)
maybe packaged as separate plugins as well .

> 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.

Interesting . Not necessarily harder . That depends . Indeed we have
overridden TicketModule but in a clever way (Gary is guilty for that
;) so as make merge process easier .

> 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.

oh no !
IMO unless there's a good reason to do so , that's a waste of time .
That's what trac-hacks are there for .



Blog ES:
Blog EN:

Featured article:

View raw message