4:47 p.m.
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
a plan which I believe will allow us to move at a much quicker pace:
For the next minor releases I would like to suggest the following strategy:
- use a 3 month timebox where we strive to maintain master in an "always
releasable" state
- complex feature work will need to happen onto dedicated feature branches, using the
usual GitHub pull-request workflow
- only when a feature is complete (code, tests, docs, reviewed, CI-checked) it will be
merged back into master
- if a feature is running late it will be postponed to the following minor release so as
not to hinder other development
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.
This is the plan for 7.1.0:
13 November 7.1.0.Alpha1
18 December 7.1.0.Beta1
15 January 7.1.0.CR1
30 January 7.1.0.Final
Tristan
6:21 p.m.
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 <ttarrant(a)redhat.com> wrote:
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
a plan which I believe will allow us to move at a much quicker pace:
For the next minor releases I would like to suggest the following strategy:
- use a 3 month timebox where we strive to maintain master in an "always
releasable" state
- complex feature work will need to happen onto dedicated feature branches, using the
usual GitHub pull-request workflow
- only when a feature is complete (code, tests, docs, reviewed, CI-checked) it will be
merged back into master
- if a feature is running late it will be postponed to the following minor release so as
not to hinder other development
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.
This is the plan for 7.1.0:
13 November 7.1.0.Alpha1
18 December 7.1.0.Beta1
15 January 7.1.0.CR1
30 January 7.1.0.Final
Tristan
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
6:28 p.m.
On Oct 20, 2014, at 17:21, Emmanuel Bernard <emmanuel(a)hibernate.org> 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)?
Using github's "merge" button is pretty convenient imo, even though the
history is not as nice as with a rebase (or cherry-pick, I miss the difference for now )
On 20 Oct 2014, at 16:47, Tristan Tarrant <ttarrant(a)redhat.com> wrote:
> 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
> a plan which I believe will allow us to move at a much quicker pace:
>
> For the next minor releases I would like to suggest the following strategy:
> - use a 3 month timebox where we strive to maintain master in an "always
releasable" state
> - complex feature work will need to happen onto dedicated feature branches, using the
usual GitHub pull-request workflow
> - only when a feature is complete (code, tests, docs, reviewed, CI-checked) it will
be merged back into master
> - if a feature is running late it will be postponed to the following minor release so
as not to hinder other development
>
> 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.
>
> This is the plan for 7.1.0:
>
> 13 November 7.1.0.Alpha1
> 18 December 7.1.0.Beta1
> 15 January 7.1.0.CR1
> 30 January 7.1.0.Final
>
>
> Tristan
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
6:37 p.m.
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, reviewing code almost always require to fetch the branch and
look at it in an IDE of sort for proper review. The documentation bit is actually even
requiring local run since Markdown / Asciidoc and all tend to silently fail a syntax
mistake.
On 20 Oct 2014, at 18:28, Mircea Markus <mmarkus(a)redhat.com> wrote:
On Oct 20, 2014, at 17:21, Emmanuel Bernard <emmanuel(a)hibernate.org> 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)?
Using github's "merge" button is pretty convenient imo, even though the
history is not as nice as with a rebase (or cherry-pick, I miss the difference for now )
>
>
> On 20 Oct 2014, at 16:47, Tristan Tarrant <ttarrant(a)redhat.com> wrote:
>
>> 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
>> a plan which I believe will allow us to move at a much quicker pace:
>>
>> For the next minor releases I would like to suggest the following strategy:
>> - use a 3 month timebox where we strive to maintain master in an "always
releasable" state
>> - complex feature work will need to happen onto dedicated feature branches, using
the usual GitHub pull-request workflow
>> - only when a feature is complete (code, tests, docs, reviewed, CI-checked) it
will be merged back into master
>> - if a feature is running late it will be postponed to the following minor
release so as not to hinder other development
>>
>> 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.
>>
>> This is the plan for 7.1.0:
>>
>> 13 November 7.1.0.Alpha1
>> 18 December 7.1.0.Beta1
>> 15 January 7.1.0.CR1
>> 30 January 7.1.0.Final
>>
>>
>> Tristan
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
6:40 p.m.
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 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, reviewing code almost
always require to fetch the branch and look at it in an IDE of sort
for proper review. The documentation bit is actually even requiring
local run since Markdown / Asciidoc and all tend to silently fail a
syntax mistake.
On 20 Oct 2014, at 18:28, Mircea Markus <mmarkus(a)redhat.com
<mailto:mmarkus@redhat.com>> wrote:
>
> On Oct 20, 2014, at 17:21, Emmanuel Bernard <emmanuel(a)hibernate.org
> <mailto:emmanuel@hibernate.org>> 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)?
>
> Using github's "merge" button is pretty convenient imo, even though
> the history is not as nice as with a rebase (or cherry-pick, I miss
> the difference for now )
>
>>
>>
>> On 20 Oct 2014, at 16:47, Tristan Tarrant <ttarrant(a)redhat.com
>> <mailto:ttarrant@redhat.com>> wrote:
>>
>>> 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
>>> a plan which I believe will allow us to move at a much quicker pace:
>>>
>>> For the next minor releases I would like to suggest the following
>>> strategy:
>>> - use a 3 month timebox where we strive to maintain master in an
>>> "always releasable" state
>>> - complex feature work will need to happen onto dedicated feature
>>> branches, using the usual GitHub pull-request workflow
>>> - only when a feature is complete (code, tests, docs, reviewed,
>>> CI-checked) it will be merged back into master
>>> - if a feature is running late it will be postponed to the
>>> following minor release so as not to hinder other development
>>>
>>> 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.
>>>
>>> This is the plan for 7.1.0:
>>>
>>> 13 November 7.1.0.Alpha1
>>> 18 December 7.1.0.Beta1
>>> 15 January 7.1.0.CR1
>>> 30 January 7.1.0.Final
>>>
>>>
>>> Tristan
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev(a)lists.jboss.org <mailto:infinispan-dev@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org <mailto:infinispan-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> Cheers,
> --
> Mircea Markus
> Infinispan lead (www.infinispan.org <http://www.infinispan.org/>)
>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org <mailto:infinispan-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
6:45 p.m.
On 20 October 2014 17:40, Tristan Tarrant <ttarrant(a)redhat.com> 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
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 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, reviewing code almost
> always require to fetch the branch and look at it in an IDE of sort
> for proper review. The documentation bit is actually even requiring
> local run since Markdown / Asciidoc and all tend to silently fail a
> syntax mistake.
>
> On 20 Oct 2014, at 18:28, Mircea Markus <mmarkus(a)redhat.com
> <mailto:mmarkus@redhat.com>> wrote:
>
>>
>> On Oct 20, 2014, at 17:21, Emmanuel Bernard <emmanuel(a)hibernate.org
>> <mailto:emmanuel@hibernate.org>> 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)?
>>
>> Using github's "merge" button is pretty convenient imo, even
though
>> the history is not as nice as with a rebase (or cherry-pick, I miss
>> the difference for now )
>>
>>>
>>>
>>> On 20 Oct 2014, at 16:47, Tristan Tarrant <ttarrant(a)redhat.com
>>> <mailto:ttarrant@redhat.com>> wrote:
>>>
>>>> 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
>>>> a plan which I believe will allow us to move at a much quicker pace:
>>>>
>>>> For the next minor releases I would like to suggest the following
>>>> strategy:
>>>> - use a 3 month timebox where we strive to maintain master in an
>>>> "always releasable" state
>>>> - complex feature work will need to happen onto dedicated feature
>>>> branches, using the usual GitHub pull-request workflow
>>>> - only when a feature is complete (code, tests, docs, reviewed,
>>>> CI-checked) it will be merged back into master
>>>> - if a feature is running late it will be postponed to the
>>>> following minor release so as not to hinder other development
>>>>
>>>> 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.
>>>>
>>>> This is the plan for 7.1.0:
>>>>
>>>> 13 November 7.1.0.Alpha1
>>>> 18 December 7.1.0.Beta1
>>>> 15 January 7.1.0.CR1
>>>> 30 January 7.1.0.Final
>>>>
>>>>
>>>> Tristan
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> infinispan-dev(a)lists.jboss.org
<mailto:infinispan-dev@lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev(a)lists.jboss.org <mailto:infinispan-dev@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> Cheers,
>> --
>> Mircea Markus
>> Infinispan lead (www.infinispan.org <http://www.infinispan.org/>)
>>
>>
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org <mailto:infinispan-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
6:51 p.m.
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 <ttarrant(a)redhat.com>
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
>
> 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 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, reviewing code almost
>> always require to fetch the branch and look at it in an IDE of sort
>> for proper review. The documentation bit is actually even requiring
>> local run since Markdown / Asciidoc and all tend to silently fail a
>> syntax mistake.
>>
>> On 20 Oct 2014, at 18:28, Mircea Markus <mmarkus(a)redhat.com
>> <mailto:mmarkus@redhat.com>> wrote:
>>
>>> On Oct 20, 2014, at 17:21, Emmanuel Bernard <emmanuel(a)hibernate.org
>>> <mailto:emmanuel@hibernate.org>> 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)?
>>> Using github's "merge" button is pretty convenient imo, even
though
>>> the history is not as nice as with a rebase (or cherry-pick, I miss
>>> the difference for now )
>>>
>>>>
>>>> On 20 Oct 2014, at 16:47, Tristan Tarrant <ttarrant(a)redhat.com
>>>> <mailto:ttarrant@redhat.com>> wrote:
>>>>
>>>>> 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
>>>>> a plan which I believe will allow us to move at a much quicker pace:
>>>>>
>>>>> For the next minor releases I would like to suggest the following
>>>>> strategy:
>>>>> - use a 3 month timebox where we strive to maintain master in an
>>>>> "always releasable" state
>>>>> - complex feature work will need to happen onto dedicated feature
>>>>> branches, using the usual GitHub pull-request workflow
>>>>> - only when a feature is complete (code, tests, docs, reviewed,
>>>>> CI-checked) it will be merged back into master
>>>>> - if a feature is running late it will be postponed to the
>>>>> following minor release so as not to hinder other development
>>>>>
>>>>> 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.
>>>>>
>>>>> This is the plan for 7.1.0:
>>>>>
>>>>> 13 November 7.1.0.Alpha1
>>>>> 18 December 7.1.0.Beta1
>>>>> 15 January 7.1.0.CR1
>>>>> 30 January 7.1.0.Final
>>>>>
>>>>>
>>>>> Tristan
>>>>>
>>>>> _______________________________________________
>>>>> infinispan-dev mailing list
>>>>> infinispan-dev(a)lists.jboss.org
<mailto:infinispan-dev@lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> infinispan-dev(a)lists.jboss.org
<mailto:infinispan-dev@lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> Cheers,
>>> --
>>> Mircea Markus
>>> Infinispan lead (www.infinispan.org <http://www.infinispan.org/>)
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev(a)lists.jboss.org <mailto:infinispan-dev@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
6:55 p.m.
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 Oct 2014, at 18:40, Tristan Tarrant <ttarrant(a)redhat.com> wrote:
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 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, reviewing code almost
> always require to fetch the branch and look at it in an IDE of sort
> for proper review. The documentation bit is actually even requiring
> local run since Markdown / Asciidoc and all tend to silently fail a
> syntax mistake.
>
> On 20 Oct 2014, at 18:28, Mircea Markus <mmarkus(a)redhat.com
> <mailto:mmarkus@redhat.com>> wrote:
>
>>
>> On Oct 20, 2014, at 17:21, Emmanuel Bernard <emmanuel(a)hibernate.org
>> <mailto:emmanuel@hibernate.org>> 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)?
>>
>> Using github's "merge" button is pretty convenient imo, even though
>> the history is not as nice as with a rebase (or cherry-pick, I miss
>> the difference for now )
>>
>>>
>>>
>>> On 20 Oct 2014, at 16:47, Tristan Tarrant <ttarrant(a)redhat.com
>>> <mailto:ttarrant@redhat.com>> wrote:
>>>
>>>> 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
>>>> a plan which I believe will allow us to move at a much quicker pace:
>>>>
>>>> For the next minor releases I would like to suggest the following
>>>> strategy:
>>>> - use a 3 month timebox where we strive to maintain master in an
>>>> "always releasable" state
>>>> - complex feature work will need to happen onto dedicated feature
>>>> branches, using the usual GitHub pull-request workflow
>>>> - only when a feature is complete (code, tests, docs, reviewed,
>>>> CI-checked) it will be merged back into master
>>>> - if a feature is running late it will be postponed to the
>>>> following minor release so as not to hinder other development
>>>>
>>>> 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.
>>>>
>>>> This is the plan for 7.1.0:
>>>>
>>>> 13 November 7.1.0.Alpha1
>>>> 18 December 7.1.0.Beta1
>>>> 15 January 7.1.0.CR1
>>>> 30 January 7.1.0.Final
>>>>
>>>>
>>>> Tristan
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> infinispan-dev(a)lists.jboss.org
<mailto:infinispan-dev@lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev(a)lists.jboss.org <mailto:infinispan-dev@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> Cheers,
>> --
>> Mircea Markus
>> Infinispan lead (www.infinispan.org <http://www.infinispan.org/>)
>>
>>
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org <mailto:infinispan-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
12:32 p.m.
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 everyone uses git I think its a good thing. There are some really nice benefits
to it:
1. The original history from the author is preserved
2. The author does not have to toss their branch to avoid a conflict introduced by a pull
after their PR is merged
3. Changes introduced by conflict resolution are kept separate from the authors. So you
know if the problem was caused by the merge or the change > itself
4. The person who merged the change is recorded in the git history, so you have an audit
record of who allowed the change in if you have multiple mergers
5. PRs sometimes include multiple commits, and a merge commit allows you to see which
commits encompass the overall change
6. Due to 5, bisecting is quicker
7. It’s easier to revert a merge commit
8. Github PRs automatically close when you perform a merge
9. You can use the big green button with automated CI
There are however some drawbacks:
1. If you revert a merge, you need to create a new merge to bring it back. This can be a
little confusing if you do it wrong
2. You have to know how to interact with merge commits in the tools (e.g. revert requires
-m 1)
3. git log, for whatever reason defaults to date ordering instead of topographical
ordering, which can look confusing since it doesn’t represent when > changes were
actually merged. Thats solvable using git log —topo-order
Merging merge commits is of course nasty, but you don’t have to allow
it. You can just require that authors rebase their history when they need it to > be
more current vs a git pull. Merging then follows a nice clear one level nesting.”
The key thing IMO is: Avoiding merge commits but making sure that everyone rebases their
changes :)
So, +1 to Tristan’s suggestion but making sure we avoid merge commits!
On 20 Oct 2014, at 18:55, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
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 Oct 2014, at 18:40, Tristan Tarrant <ttarrant(a)redhat.com> wrote:
> 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 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, reviewing code almost
>> always require to fetch the branch and look at it in an IDE of sort
>> for proper review. The documentation bit is actually even requiring
>> local run since Markdown / Asciidoc and all tend to silently fail a
>> syntax mistake.
>>
>> On 20 Oct 2014, at 18:28, Mircea Markus <mmarkus(a)redhat.com
>> <mailto:mmarkus@redhat.com>> wrote:
>>
>>>
>>> On Oct 20, 2014, at 17:21, Emmanuel Bernard <emmanuel(a)hibernate.org
>>> <mailto:emmanuel@hibernate.org>> 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)?
>>>
>>> Using github's "merge" button is pretty convenient imo, even
though
>>> the history is not as nice as with a rebase (or cherry-pick, I miss
>>> the difference for now )
>>>
>>>>
>>>>
>>>> On 20 Oct 2014, at 16:47, Tristan Tarrant <ttarrant(a)redhat.com
>>>> <mailto:ttarrant@redhat.com>> wrote:
>>>>
>>>>> 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
>>>>> a plan which I believe will allow us to move at a much quicker pace:
>>>>>
>>>>> For the next minor releases I would like to suggest the following
>>>>> strategy:
>>>>> - use a 3 month timebox where we strive to maintain master in an
>>>>> "always releasable" state
>>>>> - complex feature work will need to happen onto dedicated feature
>>>>> branches, using the usual GitHub pull-request workflow
>>>>> - only when a feature is complete (code, tests, docs, reviewed,
>>>>> CI-checked) it will be merged back into master
>>>>> - if a feature is running late it will be postponed to the
>>>>> following minor release so as not to hinder other development
>>>>>
>>>>> 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.
>>>>>
>>>>> This is the plan for 7.1.0:
>>>>>
>>>>> 13 November 7.1.0.Alpha1
>>>>> 18 December 7.1.0.Beta1
>>>>> 15 January 7.1.0.CR1
>>>>> 30 January 7.1.0.Final
>>>>>
>>>>>
>>>>> Tristan
>>>>>
>>>>> _______________________________________________
>>>>> infinispan-dev mailing list
>>>>> infinispan-dev(a)lists.jboss.org
<mailto:infinispan-dev@lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> infinispan-dev(a)lists.jboss.org
<mailto:infinispan-dev@lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>> Cheers,
>>> --
>>> Mircea Markus
>>> Infinispan lead (www.infinispan.org <http://www.infinispan.org/>)
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev(a)lists.jboss.org <mailto:infinispan-dev@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
1:29 p.m.
On Wed, Oct 22, 2014 at 1:32 PM, Galder Zamarreño <galder(a)redhat.com> 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. That was back when git wasn’t mainstream though.
>
> Now that everyone uses git I think its a good thing. There are some
really nice benefits to it:
>
> 1. The original history from the author is preserved
TBH most of the time I don't care about my history, I always have stupid
commit messages until I squash my commits and "prettify" the commit
messages.
> 2. The author does not have to toss their branch to avoid a
conflict
introduced by a pull after their PR is merged
I think this can only happen if the branch had conflicts and the committer
resolved them, but we require authors to rebase so I don't think this has
been a problem for us.
> 3. Changes introduced by conflict resolution are kept separate
from the
authors. So you know if the problem was caused by the merge or the change >
itself
4. The person who merged the change is recorded in the git history,
so
you have an audit record of who allowed the change in if you have multiple
mergers
Git records the committer as well. You just have to do a "git rebase -f
master" locally to make sure the committer field is updated before you push
into upstream.
> 5. PRs sometimes include multiple commits, and a merge commit
allows you
to see which commits encompass the overall change
> 6. Due to 5, bisecting is quicker
+1, bisecting is cool, even though I've never been able to use it on
Infinispan :)
> 7. It’s easier to revert a merge commit
> 8. Github PRs automatically close when you perform a merge
> 9. You can use the big green button with automated CI
>
> There are however some drawbacks:
>
> 1. If you revert a merge, you need to create a new merge to bring it
back. This can be a little confusing if you do it wrong
> 2. You have to know how to interact with merge commits in the tools
(e.g. revert requires -m 1)
3. git log, for whatever reason defaults to date ordering instead of
topographical ordering, which can look confusing since it doesn’t represent
when > changes were actually merged. Thats solvable using git log
—topo-order
> Merging merge commits is of course nasty, but you don’t have to allow
it. You can just require that authors rebase their history when they need
it to > be more current vs a git pull. Merging then follows a nice clear
one level nesting.”
The key thing IMO is: Avoiding merge commits but making sure that everyone
rebases their changes :)
So, +1 to Tristan’s suggestion but making sure we avoid merge commits!
Sorry, you've lost me here :) Doesn't every merge have a merge commit?
I have seen recommendations to use the GitHub Merge button but avoid force
the PR authors to rebase anyway elsewhere, but I'm not sure how we could
enforce that. I don't think there is any cue in the GitHub UI that the PR
could/should be rebased. Maybe we could add a git hook to do that check,
and force the integrator to rebase locally if the PR is not yet rebased?
On 20 Oct 2014, at 18:55, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
> 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 Oct 2014, at 18:40, Tristan Tarrant <ttarrant(a)redhat.com> wrote:
>
>> 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 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, reviewing code almost
>>> always require to fetch the branch and look at it in an IDE of sort
>>> for proper review. The documentation bit is actually even requiring
>>> local run since Markdown / Asciidoc and all tend to silently fail a
>>> syntax mistake.
>>>
>>> On 20 Oct 2014, at 18:28, Mircea Markus <mmarkus(a)redhat.com
>>> <mailto:mmarkus@redhat.com>> wrote:
>>>
>>>>
>>>> On Oct 20, 2014, at 17:21, Emmanuel Bernard <emmanuel(a)hibernate.org
>>>> <mailto:emmanuel@hibernate.org>> 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)?
>>>>
>>>> Using github's "merge" button is pretty convenient imo,
even though
>>>> the history is not as nice as with a rebase (or cherry-pick, I miss
>>>> the difference for now )
>>>>
>>>>>
>>>>>
>>>>> On 20 Oct 2014, at 16:47, Tristan Tarrant <ttarrant(a)redhat.com
>>>>> <mailto:ttarrant@redhat.com>> wrote:
>>>>>
>>>>>> 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
>>>>>> a plan which I believe will allow us to move at a much quicker
pace:
>>>>>>
>>>>>> For the next minor releases I would like to suggest the
following
>>>>>> strategy:
>>>>>> - use a 3 month timebox where we strive to maintain master in
an
>>>>>> "always releasable" state
>>>>>> - complex feature work will need to happen onto dedicated
feature
>>>>>> branches, using the usual GitHub pull-request workflow
>>>>>> - only when a feature is complete (code, tests, docs, reviewed,
>>>>>> CI-checked) it will be merged back into master
>>>>>> - if a feature is running late it will be postponed to the
>>>>>> following minor release so as not to hinder other development
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> This is the plan for 7.1.0:
>>>>>>
>>>>>> 13 November 7.1.0.Alpha1
>>>>>> 18 December 7.1.0.Beta1
>>>>>> 15 January 7.1.0.CR1
>>>>>> 30 January 7.1.0.Final
>>>>>>
>>>>>>
>>>>>> Tristan
>>>>>>
>>>>>> _______________________________________________
>>>>>> infinispan-dev mailing list
>>>>>> infinispan-dev(a)lists.jboss.org <mailto:
infinispan-dev(a)lists.jboss.org>
>>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> infinispan-dev mailing list
>>>>> infinispan-dev(a)lists.jboss.org <mailto:
infinispan-dev(a)lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>>> Cheers,
>>>> --
>>>> Mircea Markus
>>>> Infinispan lead (www.infinispan.org <http://www.infinispan.org/>)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> infinispan-dev(a)lists.jboss.org
<mailto:infinispan-dev@lists.jboss.org
>
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
11:51 a.m.
On 22/10/14 12:29, Dan Berindei wrote:
On Wed, Oct 22, 2014 at 1:32 PM, Galder Zamarreño
<galder(a)redhat.com
<mailto:galder@redhat.com>> wrote:
Guys, Jason from Wildfly provided some interesting information a
while back on the benefits of “merge” approach vs cherry-pick. To
paraphrase:
> 1. The original history from the author is preserved
TBH most of the time I don't care about my history, I always have
stupid commit messages until I squash my commits and "prettify" the
commit messages.
Indeed: I commit and squash all the time. I'm only interested
in seeing
multiple commits in the following case:
- they are actually subtasks of the main PR
- if the pull request is for a feature which was developed
collaboratively by multiple developers
> 2. The author does not have to toss their branch to avoid a
conflict introduced by a pull after their PR is merged
I think this can only happen if the branch had conflicts and the
committer resolved them, but we require authors to rebase so I don't
think this has been a problem for us.
So the best approach seems to actually be rebase/pull, which gets us
what we want.
Tristan
8:35 p.m.
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" <ttarrant(a)redhat.com> wrote:
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
a plan which I believe will allow us to move at a much quicker pace:
For the next minor releases I would like to suggest the following
strategy:
- use a 3 month timebox where we strive to maintain master in an "always
releasable" state
- complex feature work will need to happen onto dedicated feature
branches, using the usual GitHub pull-request workflow
- only when a feature is complete (code, tests, docs, reviewed,
CI-checked) it will be merged back into master
- if a feature is running late it will be postponed to the following
minor release so as not to hinder other development
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.
This is the plan for 7.1.0:
13 November 7.1.0.Alpha1
18 December 7.1.0.Beta1
15 January 7.1.0.CR1
30 January 7.1.0.Final
Tristan
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
9:41 a.m.
+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).
+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.
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.
10:27 a.m.
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
10:59 a.m.
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.
12:47 p.m.
On Tue, Oct 21, 2014 at 11:59 AM, Sebastian Łaskawiec <slaskawi(a)redhat.com>
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).
Like Sanne said, we did decide to go for a green test suite a great many
times on this list, so I don't think lack of awareness is an issue.
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 motivate me to create a few new blocker issues,
however :)
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.".
Of course, the question is how we are going to achieve that magical clean
build status...
At one point we moved the random failing tests to the unstable
group/category to remove them from the main build, but I've noticed that
we've never really brought back an unstable test, at least in the core, so
I've stopped doing it. I figured having the test failures in every email
from TeamCity would motivate people to look into those failures, but I'm
not sure anyone reads the build failure emails from TeamCity :)
And it's not enough to have one master build with 0 failures. We had that
before, and it didn't really help. We have to have at least a week with 0
failures on master (with JDK7, with JDK8, and with TRACE enabled, on the
slow EC2 agent, on the fast OpenStack agents etc.) before we can say the
build is really clean.
I'm not saying we can't do it, but I share Sanne's pessimism: this time is
not that different from the last time we committed to a clean build.
[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
1:35 p.m.
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 motivate me to create a
few new blocker issues, however :)
I believe we need to change our strategy in this
point. We don't want to
create new issues - we want to motivate everybody to fix it (and fix it
fast). As I said - when the failure gets into our repo - all successive
Pull Requests will start to fail. Nobody will be able to integrate his
changes and everybody (not everybody - some guys which are in hurry)
will probably want to unblock themselves... The easiest way to do that
is to fix the build...
This is the main idea... To make failing test a serious problem and not
just another "easy to ignore" issue...
Of course, the question is how we are going to achieve that magical
clean build status...
I've got some idea - it's pretty controversial, but
maybe you will like
it :)
* 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 them to fix as
many as possible during fixed amount of time (a month or two? maybe
shorter?).
* Every contributor in failed-test-bounty will be listed in "Thanks"
section of the release notes
* After the bounty is over, we'll just delete tests which were not
fixed...
1:46 p.m.
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 now have more people agreeing on how
important this is, so maybe we're in a better position, and I'm always
willing to try this again.
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 a resonsable time.. then we can talk about
building something on reliable foundations.
[BTW I can't answer inline as you're sending HTML formatted email and
gmail isn't properly separating your quote from Dan's previous words]
Why would you delete the tests and not simply ignore them? You can
revert the change as well.
Both strategies would have the same effect, but ignoring them you
don't need to take notes of what disappeared; best part, is that code
using APIs get refactored together with other changes, and you
minimize conflicts as you minimize the number of lines being changed.
Sanne
On 21 October 2014 12:35, Sebastian Łaskawiec <slaskawi(a)redhat.com> wrote:
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 motivate me to create a few new blocker issues,
however :)
I believe we need to change our strategy in this point. We don't want to
create new issues - we want to motivate everybody to fix it (and fix it
fast). As I said - when the failure gets into our repo - all successive Pull
Requests will start to fail. Nobody will be able to integrate his changes
and everybody (not everybody - some guys which are in hurry) will probably
want to unblock themselves... The easiest way to do that is to fix the
build...
This is the main idea... To make failing test a serious problem and not just
another "easy to ignore" issue...
Of course, the question is how we are going to achieve that magical clean
build status...
I've got some idea - it's pretty controversial, but maybe you will like it
:)
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 them to fix as many as
possible during fixed amount of time (a month or two? maybe shorter?).
Every contributor in failed-test-bounty will be listed in "Thanks" section
of the release notes
After the bounty is over, we'll just delete tests which were not fixed...
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
3:27 p.m.
On Tue, Oct 21, 2014 at 2:46 PM, Sanne Grinovero <sanne(a)infinispan.org>
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 great intentions didn't work in the past.
Now my hope is that maybe we now have more people agreeing on how
important this is, so maybe we're in a better position, and I'm always
willing to try this again.
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 a resonsable time.. then we can talk about
building something on reliable foundations.
+1
[BTW I can't answer inline as you're sending HTML formatted email and
gmail isn't properly separating your quote from Dan's previous words]
Why would you delete the tests and not simply ignore them? You can
revert the change as well.
Both strategies would have the same effect, but ignoring them you
don't need to take notes of what disappeared; best part, is that code
using APIs get refactored together with other changes, and you
minimize conflicts as you minimize the number of lines being changed.
Hey, if fixing compilation errors would have been enough, we wouldn't have
so many tests in the unstable group that *always* fail.
So Sebastian has a point, if we don't have a clear deadline for bringing
the failing tests back into the main build, we might as well delete them.
Except I don't want to delete tests, I want to make them work. And I didn't
see anything in his proposal about tests that fail only once a week, or
only on a certain agent, or only if TRACE logging is enabled...
Cheers
Dan
Sanne
On 21 October 2014 12:35, Sebastian Łaskawiec <slaskawi(a)redhat.com> wrote:
> 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 motivate me to create a few new blocker issues,
> however :)
>
> I believe we need to change our strategy in this point. We don't want to
> create new issues - we want to motivate everybody to fix it (and fix it
> fast). As I said - when the failure gets into our repo - all successive
Pull
> Requests will start to fail. Nobody will be able to integrate his changes
> and everybody (not everybody - some guys which are in hurry) will
probably
> want to unblock themselves... The easiest way to do that is to fix the
> build...
> This is the main idea... To make failing test a serious problem and not
just
> another "easy to ignore" issue...
> Of course, the question is how we are going to achieve that magical clean
> build status...
>
> I've got some idea - it's pretty controversial, but maybe you will like
it
> :)
>
> 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 them to fix as many
as
> possible during fixed amount of time (a month or two? maybe shorter?).
> Every contributor in failed-test-bounty will be listed in "Thanks"
section
> of the release notes
> After the bounty is over, we'll just delete tests which were not fixed...
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
9:43 a.m.
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 a resonsable time..
+1, green testsuite is a mandatory condition for any other action.
Let's start with smaller steps - I'd propose to make green Master JDK 7 first.
Currently [1] there fails these tests:
* ExampleConfigsIT.testXsiteConfig - should be fixed by PR #2973
* HotRodRemoteCacheIT.testPutAsync - I investigated it few days ago, it's IMHO a not a
random failure but a regular bug - ISPN-4813
* HotRodRemoteCacheIT.testCustom*, testEven* - I'll volunteer on investigating this
issue
* StateTransferSuppressIT.testRebalanceWith* - any volunteer for investigating this one?
Once the root causes are investigated, we can fix the issues and try to keep this build
green.
then we can talk about
building something on reliable foundations.
actually, if there's a failing test and it's clear which commit has caused it, we
can stop merging PRs from the developer
who has introduced the regression until he fix it. This should be clear message, that the
first thing he should
work on is to fix the test. IMHO we can start with it now and don't need green
testsuite for it
[1]
http://ci.infinispan.org/viewLog.html?buildId=13323&tab=buildResultsD...
10:39 a.m.
On Wed, Oct 22, 2014 at 10:43 AM, Vojtech Juranek <vjuranek(a)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 first work on a green testsuite, and then proof that
> we can keep it that way for a resonsable time..
+1, green testsuite is a mandatory condition for any other action.
Let's start with smaller steps - I'd propose to make green Master JDK 7
first.
+1
Currently [1] there fails these tests:
* ExampleConfigsIT.testXsiteConfig - should be fixed by PR #2973
Integrated
* HotRodRemoteCacheIT.testPutAsync - I investigated it few days ago,
it's
IMHO a not a random failure but a regular bug - ISPN-4813
Does anyone volunteer for ISPN-4813?
* HotRodRemoteCacheIT.testCustom*, testEven* - I'll volunteer on
investigating this issue
* StateTransferSuppressIT.testRebalanceWith* - any volunteer for
investigating this one?
I'll get this one, it might be related to the partition handling work.
There are a couple more failures in the last 5 days that we should probably
look at:
http://ci.infinispan.org/project.html?projectId=Infinispan&buildTypeI...
Once the root causes are investigated, we can fix the issues and try
to
keep this build green.
> then we can talk about
> building something on reliable foundations.
actually, if there's a failing test and it's clear which commit has caused
it, we can stop merging PRs from the developer
who has introduced the regression until he fix it. This should be clear
message, that the first thing he should
work on is to fix the test. IMHO we can start with it now and don't need
green testsuite for it
In theory that sounds good, but who do we stop merging for on account the
current failures? :)
[1]
http://ci.infinispan.org/viewLog.html?buildId=13323&tab=buildResultsD...
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
10:59 a.m.
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 which
commit has caused
> it, we can stop merging PRs from the developer
> who has introduced the regression until he fix it. This should be clear
> message, that the first thing he should
> work on is to fix the test. IMHO we can start with it now and don't need
> green testsuite for it
In theory that sounds good, but who do we stop merging for on account the
current failures? :)
probably nobody, we need to find volunteers in this case. I meant it only for
issues where it's clear who introduced the regression (e.g. me for recently
failing NodeAuth*IT tests). As above, not a complete solution, but rather a
small step to move to the state where we would like to be
1:04 p.m.
On Wed, Oct 22, 2014 at 11:59 AM, Vojtech Juranek <vjuranek(a)redhat.com>
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 size()" thread?
> > actually, if there's a failing test and it's clear which commit has
caused
> > it, we can stop merging PRs from the developer
> > who has introduced the regression until he fix it. This should be clear
> > message, that the first thing he should
> > work on is to fix the test. IMHO we can start with it now and don't
need
> > green testsuite for it
>
> In theory that sounds good, but who do we stop merging for on account the
> current failures? :)
probably nobody, we need to find volunteers in this case. I meant it only
for
issues where it's clear who introduced the regression (e.g. me for recently
failing NodeAuth*IT tests). As above, not a complete solution, but rather a
small step to move to the state where we would like to be
Yeah, that's what I meant, most of the time it's hard to track down who
caused a specific failure.
BTW, I forgot to mention something in the previous email: when you
investigate a test failure please mark the test as investigated in TeamCity
(preferably with a link to an issue in JIRA). And if it's an intermittent
failure, make sure it's not marked as fixed automatically (TC is a little
greedy here, it thinks the test is fixed the moment it doesn't fail in a
build).
Cheers
Dan
3:13 p.m.
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 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 motivate me to create a few new blocker
>issues, however :)
I believe we need to change our strategy in this point. We don't want to
create new issues - we want to motivate everybody to fix it (and fix it
fast). As I said - when the failure gets into our repo - all successive Pull
Requests will start to fail. Nobody will be able to integrate his changes
and everybody (not everybody - some guys which are in hurry) will probably
want to unblock themselves... The easiest way to do that is to fix the
build...
This is the main idea... To make failing test a serious problem and not just
another "easy to ignore" issue...
>Of course, the question is how we are going to achieve that magical clean
>build status...
I've got some idea - it's pretty controversial, but maybe you will like it
:)
* 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 them to fix as
many as possible during fixed amount of time (a month or two? maybe
shorter?).
* Every contributor in failed-test-bounty will be listed in "Thanks"
section of the release notes
* After the bounty is over, we'll just delete tests which were not
fixed...
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
4:08 p.m.
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 them to fix as many as
possible during fixed amount of time (a month or two? maybe shorter?).
Every contributor in failed-test-bounty will be listed in "Thanks" section
of the release notes
After the bounty is over, we'll just delete tests which were not fixed...
-1 to delete tests, unless it's clear they are rubbish. A failing
test, specially those who fail
some times on some specific machines when it rains, is potentially
exposing a race condition
in the code it is testing: I can't see other way to handle it rather
than understanding why it fails
and fix either the test or the feature.
Gustavo
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
12:53 p.m.
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
3494
days inactive
3497
days old
infinispan-dev@lists.jboss.org
25 comments
11 participants
participants (11)
-
Dan Berindei -
Emmanuel Bernard -
Erik Salter -
Galder Zamarreño -
Gustavo Fernandes -
Mircea Markus -
Radim Vansa -
Sanne Grinovero -
Sebastian Łaskawiec -
Tristan Tarrant -
Vojtech Juranek