On Wed, Oct 22, 2014 at 10:43 AM, Vojtech Juranek <vjuranek(a)redhat.com>
wrote:
On Tuesday 21 October 2014 12:46:42 Sanne Grinovero wrote:
> I'm sceptical though on embarking into a PR process which assumes that
> we're going to be able to keep the testsuite green just because we
> decide so; let's first work on a green testsuite, and then proof that
> we can keep it that way for a resonsable time..
+1, green testsuite is a mandatory condition for any other action.
Let's start with smaller steps - I'd propose to make green Master JDK 7
first.
+1
Currently [1] there fails these tests:
* ExampleConfigsIT.testXsiteConfig - should be fixed by PR #2973
Integrated
* HotRodRemoteCacheIT.testPutAsync - I investigated it few days ago,
it's
IMHO a not a random failure but a regular bug - ISPN-4813
Does anyone volunteer for ISPN-4813?
* HotRodRemoteCacheIT.testCustom*, testEven* - I'll volunteer on
investigating this issue
* StateTransferSuppressIT.testRebalanceWith* - any volunteer for
investigating this one?
I'll get this one, it might be related to the partition handling work.
There are a couple more failures in the last 5 days that we should probably
look at:
http://ci.infinispan.org/project.html?projectId=Infinispan&buildTypeI...
Once the root causes are investigated, we can fix the issues and try
to
keep this build green.
> then we can talk about
> building something on reliable foundations.
actually, if there's a failing test and it's clear which commit has caused
it, we can stop merging PRs from the developer
who has introduced the regression until he fix it. This should be clear
message, that the first thing he should
work on is to fix the test. IMHO we can start with it now and don't need
green testsuite for it
In theory that sounds good, but who do we stop merging for on account the
current failures? :)