[infinispan-dev] Infinispan 7.1 plan

[Radim Vansa]

We might also want to define reproducer test commits, and how should 
these be integrated.

Is the recommended workflow to have one commit with issue reproducer 
test (so that we can see that it was broken prior to the fix my checking 
out just this commit), and following commit fixing the issue? Should 
those two commits be squashed when pulling the PR (so that any master 
commit is always green), or cherry-picked one-by-one (having only the 
actual HEAD on master green any time)?

I miss the guideline.

Thanks

Radim

On 10/21/2014 10:59 AM, Sebastian Łaskawiec wrote:
> I think we can work on this one...
>
> First of all - contributors need to know about this rule, perhaps
> updating [1] might be a good idea. Official announcement on mailing list
> might be also helpful (this email thread is already pretty long, so it
> might be missed by many folks).
>
> Secondly - we need to stop integrating Pull Requests with new failures.
> It's a bit harder when we have some existing failures, because there is
> always an excuse (this failure is not related, it's just an unstable
> test etc). But once we have clean build - it's a "binary" decision.
> I think we might also add some descriptive comment to Pull Request when
> the build is unstable - something like "This Pull Request won't be
> integrated, because it's unstable. Fix it first.".
>
> [1] http://infinispan.org/docs/7.0.x/contributing/contributing.html
>
> On 10/21/2014 10:27 AM, Sanne Grinovero wrote:
>> 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.
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


-- 
Radim Vansa <rvansa at redhat.com>
JBoss DataGrid QA