>From my perspective, we should take on other databases if:
a) The team agrees that the general popularity of the platform
warrants it. (ex. Oracle)
b) A team member "adopts" the database (ex. SQLite and PostgreSQL were
adopted by me).
Regarding the build times, I believe that this is something inevitable
that we should embrace. The more tests that occur automatically, the
more quickly we understand and correct problems with different
databases. Tests for one database might even illuminate bugs that
aren't apparent with other databases. Since it's very expensive to
have every developer set up every database and run all the tests on
all the databases, I believe the build server is the right place to do
this. There just needs to be the expectation that committers will
handle fallout from their commits within a reasonably short time
period, something that I don't believe will be a significant issue
going forward.
Since it sounds like the popular opinion, we should go ahead and make
the tests fail if new tests fail. I'll be presumptuous and hope that
Richard will change it since he's most familiar with the territory. :)
Patrick Earl
On Wed, Jul 27, 2011 at 9:45 AM, Julian Maughan
<[email protected]> wrote:
> I totally agree. The only problem I have is just how long it takes to run
> the tests on all instances. Not having an Oracle database may be costing us
> some credibility, but otherwise I would suggest not adding more.
>
> The other issue is how the CI databases are chosen. We are essentially
> giving these database vendors/projects a 'first class' status compared to
> others.
>
> On 22/07/2011 6:47 AM, "Patrick Earl" <[email protected]> wrote:
>
