Mailing-List: contact bloodhound-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: bloodhound-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
Sender: peter@xlii.si
In-Reply-To: 
 <CAGMZAuNO-K1imLE7F-pcRu-yDw5FGOJb-KM+6MENAqiXvbpwWQ@mail.gmail.com>
References: 
 <CAPt9QwQdaC+cEwVRe__CxhX7vvqk40Uckc3bDBVn5y+K6e5VZQ@mail.gmail.com>
	<CAGMZAuOpvdRPBTwkv7LgWUixdg5qttTxGq71UBbrsVi=V7mY2Q@mail.gmail.com>
	<CAPt9QwTXEcCDLoF67AANki_LCYtKFqSW583KTE3S_X1Uq-3uig@mail.gmail.com>
	<CAKE9Bs8seSW4hM=gV+RnyFhBtJJMGLE3JvFFLtUPH75MbY4pmQ@mail.gmail.com>
	<CAPt9QwTuq+uKQM979XcbxYixbsR1NN1JGEgsCRAB_vWg3+Kb+Q@mail.gmail.com>
	<CAGMZAuNO-K1imLE7F-pcRu-yDw5FGOJb-KM+6MENAqiXvbpwWQ@mail.gmail.com>
Date: Wed, 10 Oct 2012 19:26:36 +0200
Message-ID: 
 <CAKE9Bs-_OSY4+Tu9jhR1XzdEVwGmP4Czy3-0n3QBXWJ7K2O8WA@mail.gmail.com>
Subject: Re: Tests and CI (was: A word on Release 2)
From: =?UTF-8?Q?Peter_Ko=C5=BEelj?= <peter@digiverse.si>
To: bloodhound-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=e89a8f838a55b8830904cbb7c123

--e89a8f838a55b8830904cbb7c123
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I admit it, some of my fears could just be the cause of the fact that I am
not familiar with Trac plugin architecture and the Trac plugin ecosystem as
a whole yet.

Just a few use cases for quick "does it float" test:
1. Let's say we adopt some plugins for multiproducts, ticket relations,
data import/export and so on...
2. Then we want to add user (admin) defined ticket relation per product
3. And then we want to support custom ticket workflows per product and per
ticket type
4. And now we want the ticket import/export from/to Jira to work across
Trac and all other plugins (including ticket relations, multiproducts and
custom per product workflows plugins)
5. Add white labeling across Trac and all other plugins
6. Implement new search query language that will understand tickets,
products and relations
7. Add REST API's for all of the above
8. ...

Now, all this plugins (products, relations, import, export, search, white
labeling, new search...) will either have to know filthy little details
about each other (complex inter-plugin dependency) or some super heavy
shifting in the plugin interface will be necessary. And that super heavy
shifting will have to be pushed back to Trac (if it wants it) and only then
to these plugins or create new Bloodhound plugin API on top of Trac plugin
API and then request plugin authors to support it.

Am I missing something?

Peter

On Wed, Oct 10, 2012 at 5:22 PM, Olemis Lang <olemis@gmail.com> wrote:

> On 10/10/12, Ryan Ollos <ryan.ollos@wandisco.com> wrote:
> > On Wed, Oct 10, 2012 at 1:27 AM, Peter Ko=C5=BEelj <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 maintai=
n
> >> 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 a=
ll
> >> 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 i=
n
> > 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:
>

--e89a8f838a55b8830904cbb7c123--