Re: [infinispan-dev] Infinispan 7.1 plan

On 22/10/14 12:29, Dan Berindei wrote: > On Wed, Oct 22, 2014 at 1:32 PM, Galder Zamarreño > wrote: > > Guys, Jason from Wildfly provided some interesting information a > while back on the benefits of “merge” approach vs cherry-pick. To > paraphrase: > > >

Re: [infinispan-dev] Infinispan 7.1 plan

On Wed, Oct 22, 2014 at 1:32 PM, Galder Zamarreño wrote: > Guys, Jason from Wildfly provided some interesting information a while > back on the benefits of “merge” approach vs cherry-pick. To paraphrase: > > > I used to be anti-merge because I thought it made things harder for > users to grok. Th

Re: [infinispan-dev] Infinispan 7.1 plan

On Wed, Oct 22, 2014 at 11:59 AM, Vojtech Juranek wrote: > > > 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 siz

Re: [infinispan-dev] Infinispan 7.1 plan

Guys, Jason from Wildfly provided some interesting information a while back on the benefits of “merge” approach vs cherry-pick. To paraphrase: > I used to be anti-merge because I thought it made things harder for users to > grok. That was back when git wasn’t mainstream though. > > Now that eve

Re: [infinispan-dev] Infinispan 7.1 plan

> 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 clea

Re: [infinispan-dev] Infinispan 7.1 plan

On Wed, Oct 22, 2014 at 10:43 AM, Vojtech Juranek 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 first work o

Re: [infinispan-dev] Infinispan 7.1 plan

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

Re: [infinispan-dev] Infinispan 7.1 plan

> > Remove every failing test from our code base - just delete it (no ignoring, > no adding to separate testsuite - just delete). > Create separate branch and place all those tests there - simply revert > commit which removed them from master. > Organize failed-test-bounty with our Community - ask

Re: [infinispan-dev] Infinispan 7.1 plan

On Tue, Oct 21, 2014 at 2:46 PM, Sanne Grinovero wrote: > Hi Sebastian, > I'm not against the idea at all, I would really love it and I agree > that this is the biggest pain and waste of time in trying to make > progress on Infinispan. I'm just trying to be realistic and warn you > that these gre

Re: [infinispan-dev] Infinispan 7.1 plan

No shower and no beer until the next fully green result (including tests left over as unstable). That should be motivating enough ;) On Tue 2014-10-21 13:35, Sebastian Łaskawiec wrote: > On 10/21/2014 12:47 PM, Dan Berindei wrote: > >In fact, I was volunteered to monitor the TeamCity test results

Re: [infinispan-dev] Infinispan 7.1 plan

Hi Sebastian, I'm not against the idea at all, I would really love it and I agree that this is the biggest pain and waste of time in trying to make progress on Infinispan. I'm just trying to be realistic and warn you that these great intentions didn't work in the past. Now my hope is that maybe we

Re: [infinispan-dev] Infinispan 7.1 plan

On 10/21/2014 12:47 PM, Dan Berindei wrote: In fact, I was volunteered to monitor the TeamCity test results and create a blocker issue for each failing test some time ago, but finding the proper owner for bugs proved to be quite time consuming so I haven't been sticking to it. This thread did m

Re: [infinispan-dev] Infinispan 7.1 plan

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? S

Re: [infinispan-dev] Infinispan 7.1 plan

On Tue, Oct 21, 2014 at 11: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

Re: [infinispan-dev] Infinispan 7.1 plan

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 nee

Re: [infinispan-dev] Infinispan 7.1 plan

On 21 October 2014 08:41, Sebastian Łaskawiec 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

Re: [infinispan-dev] Infinispan 7.1 plan

+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

Re: [infinispan-dev] Infinispan 7.1 plan

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" wrote: >Hi guys, > >with the imminent release of 7.0.0.CR2 we are reachi

Re: [infinispan-dev] Infinispan 7.1 plan

So you review locally and potentially run locally and then you switch from your terminal console or IDE to wherever the button is in your 350 opened tabs because it’s faster than git push upstream master. I am having a hard time to see the convenience unless you do browser only reviews. On 20

Re: [infinispan-dev] Infinispan 7.1 plan

My assumption is that the test is run by CI. Tristan On 20/10/14 18:45, Sanne Grinovero wrote: > On 20 October 2014 17:40, Tristan Tarrant wrote: >> Sure, you still want to review it in your IDE, and maybe run local >> tests, but ultimately merging via the GitHub UI. > If you do one thing locall

Re: [infinispan-dev] Infinispan 7.1 plan

On 20 October 2014 17:40, Tristan Tarrant wrote: > Sure, you still want to review it in your IDE, and maybe run local > tests, but ultimately merging via the GitHub UI. If you do one thing locally, and then "ultimately" press a button there you didn't test the same thing. Sanne > > Tristan > >

Re: [infinispan-dev] Infinispan 7.1 plan

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 wa

Re: [infinispan-dev] Infinispan 7.1 plan

rebase is a oneliner op per branch you want to reapply whereas cherry picking requires to manually select the commits you want. Underneath in git guts it probably does the same. I have to admit I barely had the occasion to want to click the GitHub UI button as except for simple documentation, r

Re: [infinispan-dev] Infinispan 7.1 plan

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 wrote: > Hi guys, > > with the imminent release o

Re: [infinispan-dev] Infinispan 7.1 plan

On Oct 20, 2014, at 17:21, Emmanuel Bernard wrote: > There is a difference between cherry picking and rebasing when it comes to > reapply a work on top of a branch. What is the difference? :-) > Do you dislike both equally compared to a merge (aka railroad nexus git > history approach)? Usi

[infinispan-dev] Infinispan 7.1 plan

Hi guys, with the imminent release of 7.0.0.CR2 we are reaching the end of this release cycle. There have been a ton of improvements (maybe too many) and a lot of time has passed since the previous version (maybe to much). Following up on my previous e-mail about future plans, here's a recap of