incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <ole...@gmail.com>
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 <ryan.ollos@wandisco.com> wrote:
> On Wed, Oct 10, 2012 at 1:27 AM, Peter Koželj <peter@digiverse.si> 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.

+1

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

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

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

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:

Mime
View raw message