On 10/10/12, Ryan Ollos <[email protected]> wrote: > On Wed, Oct 10, 2012 at 1:27 AM, Peter Koželj <[email protected]> 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:
