On Tuesday 21 October 2014 12:46:42 Sanne Grinovero wrote:
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
On Wed, Oct 22, 2014 at 10:43 AM, Vojtech Juranek vjura...@redhat.com
wrote:
On Tuesday 21 October 2014 12:46:42 Sanne Grinovero wrote:
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
Does anyone volunteer for ISPN-4813?
me not:-) as this one is IMHO little bit tricky - it's (at least partially)
related to the question which size is the correct size?. Was there any clear
conclusion in recent About size() thread?
actually, if there's a failing test and it's clear
+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
On 21 October 2014 08:41, Sebastian Łaskawiec slask...@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.
There is a difference between cherry picking and rebasing when it comes to
reapply a work on top of a branch. Do you dislike both equally compared to a
merge (aka railroad nexus git history approach)?
On 20 Oct 2014, at 16:47, Tristan Tarrant ttarr...@redhat.com wrote:
Hi guys,
with the
Sure, you still want to review it in your IDE, and maybe run local
tests, but ultimately merging via the GitHub UI.
Tristan
On 20/10/14 18:37, Emmanuel Bernard wrote:
rebase is a oneliner op per branch you want to reapply whereas cherry
picking requires to manually select the commits you
With this more agile release cycle, can users expect minor releases to be
compatible with the previous release? Or will we still need to use the
RollingUpgrade path?
Regards,
Erik
On 10/20/14, 10:47 AM, Tristan Tarrant ttarr...@redhat.com wrote:
Hi guys,
with the imminent release of
