[infinispan-dev] Infinispan 7.1 plan

Sanne Grinovero sanne at infinispan.org
Tue Oct 21 07:46:42 EDT 2014


Hi Sebastian,
I'm not against the idea at all, I would really love it and I agree
that this is the biggest pain and waste of time in trying to make
progress on Infinispan. I'm just trying to be realistic and warn you
that these great intentions didn't work in the past.
Now my hope is that maybe we now have more people agreeing on how
important this is, so maybe we're in a better position, and I'm always
willing to try this again.

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.. then we can talk about
building something on reliable foundations.

[BTW I can't answer inline as you're sending HTML formatted email and
gmail isn't properly separating your quote from Dan's previous words]

Why would you delete the tests and not simply ignore them? You can
revert the change as well.
Both strategies would have the same effect, but ignoring them you
don't need to take notes of what disappeared; best part, is that code
using APIs get refactored together with other changes, and you
minimize conflicts as you minimize the number of lines being changed.

Sanne

On 21 October 2014 12:35, Sebastian Łaskawiec <slaskawi at redhat.com> wrote:
> On 10/21/2014 12:47 PM, Dan Berindei wrote:
>
> In fact, I was volunteered to monitor the TeamCity test results and create a
> blocker issue for each failing test some time ago, but finding the proper
> owner for bugs proved to be quite time consuming so I haven't been sticking
> to it. This thread did motivate me to create a few new blocker issues,
> however :)
>
> I believe we need to change our strategy in this point. We don't want to
> create new issues - we want to motivate everybody to fix it (and fix it
> fast). As I said - when the failure gets into our repo - all successive Pull
> Requests will start to fail. Nobody will be able to integrate his changes
> and everybody (not everybody - some guys which are in hurry) will probably
> want to unblock themselves... The easiest way to do that is to fix the
> build...
>
> This is the main idea... To make failing test a serious problem and not just
> another "easy to ignore" issue...
>
> Of course, the question is how we are going to achieve that magical clean
> build status...
>
> I've got some idea - it's pretty controversial, but maybe you will like it
> :)
>
> Remove every failing test from our code base - just delete it (no ignoring,
> no adding to separate testsuite - just delete).
> Create separate branch and place all those tests there - simply revert
> commit which removed them from master.
> Organize failed-test-bounty with our Community - ask them to fix as many as
> possible during fixed amount of time (a month or two? maybe shorter?).
> Every contributor in failed-test-bounty will be listed in "Thanks" section
> of the release notes
> After the bounty is over, we'll just delete tests which were not fixed...
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev



More information about the infinispan-dev mailing list