On 21 October 2014 08:41, Sebastian Ćaskawiec <slaskawi(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev