[infinispan-dev] Infinispan 7.1 plan

[Sanne Grinovero]

On 21 October 2014 08:41, Sebastian Łaskawiec <slaskawi at redhat.com> wrote:
> +1000 I think that's a big step in good direction.
>
> As Tristan said - having 0 test failures is essential here. I would say
> even more - Pull Requests without green tick from CI shouldn't be
> considered as "ready for review".
>
> Having 0 test failures rule has one additional side effect - if for some
> reason test failure gets into the repo (e.g. merging 2 similar PRs which
> change test data - especially in text files) - all other Pull Requests
> will start to fail from that point. This will oblige us to fix the
> failure before merging further Pull Requests. This makes tracking down
> failure commits really easy (or at least much easier then it is now).

I totally agree here, but it never worked: people regularly ignore
failing tests, for various reasons.
We've had similar good intentions expressed many times, but I simply
have no reason to believe that this time it's going to work out.

> +1 for merging using Github UI - It simply saves us time. Searching
> through railroad history is a bit harder - but on the other hand "git
> log --merges --graph" shows you very nice history of merged features
> (not individual commits). It might be really useful in some cases.

I'm skeptical but we can try. I should admit that part of my
scepticism comes from having had bad experiences with merge, but
that's probably caused by the fact that I generally don't use them at
all in my workflows.
That said, I did face major horror stories caused by merge -
especially from occasional contributors who might get confused by it -
and I wouldn't try it on projects I care for. Good luck.

Sanne

>
> Thanks!
> Sebastian
>
>
> On 10/20/2014 04:47 PM, Tristan Tarrant wrote:
>> I am also going to suggest dropping the cherry-picking approach and going with git merge. In order to achieve this we need CI to be always in top form with 0 failures in master. This will allow merging a PR directly from GitHub's interface. We obviously need to trust our tools and our existing code base.
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev