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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa <rvansa(a)redhat.com>
JBoss DataGrid QA