You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Konstantin Boudnik <co...@apache.org> on 2015/04/30 00:48:22 UTC
Git practices [Was: Development process]
Guys,
I don't want to hijack the original thread, so I am forking it ;)
I've been watching the git tree for the sprint branches and I have one general
comment, which I always pushing for when it gets to correct use of git. Here
it is:
- during the development on a branch one has to re-sync with the main
integration branch (ie ignite-sprint-X)
- git has two options of doing this: merge and rebase
- merge preserves the history of the, well, branch merges - potentially
producing a complex intervened picture of branches like
│ │ ● │ minor
│ │ ●━┑ Merge remote-tracking branch 'origin/ignite-sprint-4' into ignite-sprint-4
│ │ │ ●━┑ merge from ignite-790 to ignite-sprint-4
│ │ │ │ ● ignite-790: improvements after the review
│ │ │ │ ● review
│ │ │ │ ●━┑ Merge branches 'ignite-790' and 'ignite-sprint-4' of https://git-wip-us.apache.org/repo~
│ │ │ │ ● │ ignite-790: several times performance improvements
│ │ │ │ ● │ ignite-790: added example configs for clouds
│ │ │ │ ● │ ignite-790: default configs
│ │ │ │ ● │ ignite-790: fixes, improvements, tests
│ │ │ │ ● │ ignite-709: read private key for GCE from the file
│ │ │ │ ● │ temporal commit, forgot to switch to the branch
│ │ │ ●━┑ │ Merge branch 'ignite-734' into ignite-sprint-4
│ │ │ │ ● │ review
│ │ │ │ ●━┪ Merge branches 'ignite-734' and 'ignite-sprint-4' of https://git-wip-us.apache.org/repo~
│ │ │ │ ● │ ignite-734: finished implementation, provided tests
│ │ │ │ ● │ ignite-734: google cloud storage ipfinder is fully implemented
│ │ │ │ ● │ ignite-734: implemented ip finder
│ │ │ │ ● │ ignite-734: start implementing google ip finder
│ │ ● │ │ │ fixed NPE
│ ● │ │ │ │ javadoc fix
●━┑ │ │ │ │ Merge branches 'ignite-839' and 'ignite-sprint-4' of https://git-wip-us.apache.org/repo~
- rebase rewrites the new commits on top of a specified HEAD, hence producing
a flat line of development
- merge makes sense for feature branches integration, automatic branch
management by CI, etc.
- rebase makes sense when you're working on your feature for some time and
don't want to show the whole world how many times you were synching with
the integration branch. Keep in mind, that rebase rewrites the commits
hence changing their sha1 hashes. Be considerate about this and never
rebase something that has been already pushed to the remote repo
- In the example above perhaps no one would either care for the fact that
there was 5 consequent commits for ignite-790. This particular situation
could be fixes with 'squash' (a form of interactive rebase), but I will
leave this exercise for the readers.
These simple rules allow to produce a much cleaner git history, which is
easier to work with, bisect if needed, and in general do any sorts of tracing.
Please let me know if you have any questions.
Cos
On Wed, Apr 29, 2015 at 12:03PM, Yakov Zhdanov wrote:
> Igniters,
>
> We have got pretty cool changes in current ignite-sprint-4 branch (already
> merged or are ready to be merged):
> * Added Google Compute Engine TCP discovery IP finder.
> * Added generic cloud TCP discovery IP finder (based on jcoulds).
> * Added SortedEvictionPolicy.
> * Added chaining for IgniteConfiguration and CacheConfiguration setters.
> * Improved expiry policy handling.
> * Fixed job continuations.
> * Fixed compilation and runtime with OpenJDK 7 & 8
> * Many stability and fault-tolerance fixes.
>
> Let's try releasing it as apache-ignite-1.1!
>
> Please continue new functionality development in ignite-sprint-5 (whoever
> has anything to commit to will create this branch).
>
> Make sure that no new functionality ignite-sprint-4.
>
> Release instructions can be found in DEVNOTES.txt - Ignite Release
> Instructions section. in git -
> https://git-wip-us.apache.org/repos/asf?p=incubator-ignite.git;a=blob_plain;f=DEVNOTES.txt;hb=refs/heads/ignite-sprint-4
>
> --Yakov
Re: Git practices [Was: Development process]
Posted by Konstantin Boudnik <co...@apache.org>.
On Thu, Apr 30, 2015 at 08:05AM, Branko Čibej wrote:
> On 30.04.2015 00:48, Konstantin Boudnik wrote:
> > These simple rules allow to produce a much cleaner git history, which is
> > easier to work with, bisect if needed, and in general do any sorts of tracing.
>
> I have to point out that the goal of version control is not to have a
> "clean git history" but to have an audit trail of what went into the
> code, when and by whom. Rebase destroys that information. While I can
> marginally understand people wanting to look nice in public and rebasing
> stuff in their local repository clones, rebasing anything that's already
> been pushed upstream is a recipe for disaster (and repository corruption).
Never at any point I have advocated that. More over, I have explicitly warned
not to do it. The only case for rebases when you
- don't need to expose that you did 26 merges with the master branch while
working on your fix - this info is irrelevant to anyone
- need to squash a bunch of small commits into a set of larger logically
separated commits (e.g. per JIRA tickets or something)
Any tool can be abused. I am only suggesting that polluting the history with
useless merges doesn't help anyone with anything.
Cos
> We quite recently had a case where we could not trace the history of
> jdk8 backports and therefore could not decide whether they were public
> domain or GPL. Really, that's a horrible way to do version control.
>
> Maybe instead of trying to fudge the history to make it "cleaner", you
> could consider a different workflow that doesn't involve creating a
> branch fore every line of code you write. That's a bit like sayin, Oh, I
> have a hammer, let's go find as many nails as I can, instead of just
> hammering in those nails you actually need. And use a wrench for the
> nuts, please, a hammer just ruins them.
>
> -- Brane
>
> P.S.: Before someone accuses me of an anti-git bias, let me just mention
> that I've been studying version control workflows for 20 years and
> writing a version control system for 15 ... this isn't about git, it's
> about rational development process.
Re: Git practices [Was: Development process]
Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Thu, Apr 30, 2015 at 1:05 AM, Branko Čibej <br...@apache.org> wrote:
> On 30.04.2015 00:48, Konstantin Boudnik wrote:
> > These simple rules allow to produce a much cleaner git history, which is
> > easier to work with, bisect if needed, and in general do any sorts of
> tracing.
>
> I have to point out that the goal of version control is not to have a
> "clean git history" but to have an audit trail of what went into the
> code, when and by whom. Rebase destroys that information. While I can
> marginally understand people wanting to look nice in public and rebasing
> stuff in their local repository clones, rebasing anything that's already
> been pushed upstream is a recipe for disaster (and repository corruption).
>
> We quite recently had a case where we could not trace the history of
> jdk8 backports and therefore could not decide whether they were public
> domain or GPL. Really, that's a horrible way to do version control.
>
> Maybe instead of trying to fudge the history to make it "cleaner", you
> could consider a different workflow that doesn't involve creating a
> branch fore every line of code you write. That's a bit like sayin, Oh, I
> have a hammer, let's go find as many nails as I can, instead of just
> hammering in those nails you actually need. And use a wrench for the
> nuts, please, a hammer just ruins them.
>
Brane, the only reason a branch is created for every ticket is CI. We need
to make sure that all tests pass before in developer's branch on CI before
the final merge. In current scheme, CI build runs every time there is a
push to any branch. Such scheme allows us to make sure that sprint branches
are always green and all the tests pass.
Do you have another scheme in mind? Happy to discuss.
>
> -- Brane
>
> P.S.: Before someone accuses me of an anti-git bias, let me just mention
> that I've been studying version control workflows for 20 years and
> writing a version control system for 15 ... this isn't about git, it's
> about rational development process.
>
Re: Git practices [Was: Development process]
Posted by Branko Čibej <br...@apache.org>.
On 30.04.2015 00:48, Konstantin Boudnik wrote:
> These simple rules allow to produce a much cleaner git history, which is
> easier to work with, bisect if needed, and in general do any sorts of tracing.
I have to point out that the goal of version control is not to have a
"clean git history" but to have an audit trail of what went into the
code, when and by whom. Rebase destroys that information. While I can
marginally understand people wanting to look nice in public and rebasing
stuff in their local repository clones, rebasing anything that's already
been pushed upstream is a recipe for disaster (and repository corruption).
We quite recently had a case where we could not trace the history of
jdk8 backports and therefore could not decide whether they were public
domain or GPL. Really, that's a horrible way to do version control.
Maybe instead of trying to fudge the history to make it "cleaner", you
could consider a different workflow that doesn't involve creating a
branch fore every line of code you write. That's a bit like sayin, Oh, I
have a hammer, let's go find as many nails as I can, instead of just
hammering in those nails you actually need. And use a wrench for the
nuts, please, a hammer just ruins them.
-- Brane
P.S.: Before someone accuses me of an anti-git bias, let me just mention
that I've been studying version control workflows for 20 years and
writing a version control system for 15 ... this isn't about git, it's
about rational development process.
Re: Git practices [Was: Development process]
Posted by Konstantin Boudnik <co...@apache.org>.
On Thu, May 07, 2015 at 02:53PM, Dmitriy Setrakyan wrote:
> On Thu, May 7, 2015 at 2:10 PM, Konstantin Boudnik <co...@apache.org> wrote:
>
> > Another bit that confuses me a lot is the fact that there's no "master"
> > branch
> > in this project. It is very hard for a layman to find where to start and
> > what
> > to use. Anyone with even a rudimentary git experience is normally to start
> > looking at the master branch: try to build it, run tests on it, etc.
> >
> > I got a private chat from a new user, who's looking to start contributing
> > to
> > the project but couldn't even get past running tests on master. And indeed,
> > the master is two month behind.
> >
> > Another problem this model possesses is that there's no common point to
> > branch-off release branches when the time comes. Hence, making maintenance
> > releases would be quite a bit of hassle. It might be less problematic now
> > as
> > we go in the straight line, but later it could be a necessity to supplant
> > fixes for older release.
> >
> > Once again, I'd like to propose to consider this git branching model
> > http://nvie.com/posts/a-successful-git-branching-model/
> > which proved to be very clean and development friendly in multiple projects
> > I've used it at. I am happy to have a video call with anyone who wants to
> > discuss it p2p any further.
> >
>
> I am looking at the model you are suggesting and it is pretty close to what
> we do right now. The master should be as old as 1.0, which is normal since
> that was our last release. When we release 1.1.0, we will merge it back
> again. I think this is consistent with the diagram you are suggesting, no?
Yup, it is. I just was curious about the state of the master as the tests were
hanging on it. I will check back with the fella to make sure it wasn't a
particular computer environment issue.
> We could have another policy, and merge back to master with every sprint. I
> think it sounds like you would prefer that better, right?
Doesn't really matter what I prefer as far as it is consistent and documented.
Either way has its own merits: the dev@ community needs to be comfortable with
it and new-comers have to have a way to learn it easily.
Thanks for the clarification!
Cos
> > Thoughts?
> > Cos
> >
> > On Wed, Apr 29, 2015 at 03:48PM, Konstantin Boudnik wrote:
> > > Guys,
> > >
> > > I don't want to hijack the original thread, so I am forking it ;)
> > >
> > > I've been watching the git tree for the sprint branches and I have one
> > general
> > > comment, which I always pushing for when it gets to correct use of git.
> > Here
> > > it is:
> > > - during the development on a branch one has to re-sync with the main
> > > integration branch (ie ignite-sprint-X)
> > > - git has two options of doing this: merge and rebase
> > > - merge preserves the history of the, well, branch merges - potentially
> > > producing a complex intervened picture of branches like
> > >
> > > │ │ ● │ minor
> > > │ │ ●━┑ Merge remote-tracking branch 'origin/ignite-sprint-4' into
> > ignite-sprint-4
> > > │ │ │ ●━┑ merge from ignite-790 to ignite-sprint-4
> > > │ │ │ │ ● ignite-790: improvements after the review
> > > │ │ │ │ ● review
> > > │ │ │ │ ●━┑ Merge branches 'ignite-790' and 'ignite-sprint-4' of
> > https://git-wip-us.apache.org/repo~
> > > │ │ │ │ ● │ ignite-790: several times performance improvements
> > > │ │ │ │ ● │ ignite-790: added example configs for clouds
> > > │ │ │ │ ● │ ignite-790: default configs
> > > │ │ │ │ ● │ ignite-790: fixes, improvements, tests
> > > │ │ │ │ ● │ ignite-709: read private key for GCE from the file
> > > │ │ │ │ ● │ temporal commit, forgot to switch to the branch
> > > │ │ │ ●━┑ │ Merge branch 'ignite-734' into ignite-sprint-4
> > > │ │ │ │ ● │ review
> > > │ │ │ │ ●━┪ Merge branches 'ignite-734' and 'ignite-sprint-4' of
> > https://git-wip-us.apache.org/repo~
> > > │ │ │ │ ● │ ignite-734: finished implementation, provided tests
> > > │ │ │ │ ● │ ignite-734: google cloud storage ipfinder is fully
> > implemented
> > > │ │ │ │ ● │ ignite-734: implemented ip finder
> > > │ │ │ │ ● │ ignite-734: start implementing google ip finder
> > > │ │ ● │ │ │ fixed NPE
> > > │ ● │ │ │ │ javadoc fix
> > > ●━┑ │ │ │ │ Merge branches 'ignite-839' and 'ignite-sprint-4' of
> > https://git-wip-us.apache.org/repo~
> > >
> > > - rebase rewrites the new commits on top of a specified HEAD, hence
> > producing
> > > a flat line of development
> > > - merge makes sense for feature branches integration, automatic branch
> > > management by CI, etc.
> > > - rebase makes sense when you're working on your feature for some time
> > and
> > > don't want to show the whole world how many times you were synching
> > with
> > > the integration branch. Keep in mind, that rebase rewrites the commits
> > > hence changing their sha1 hashes. Be considerate about this and never
> > > rebase something that has been already pushed to the remote repo
> > > - In the example above perhaps no one would either care for the fact
> > that
> > > there was 5 consequent commits for ignite-790. This particular
> > situation
> > > could be fixes with 'squash' (a form of interactive rebase), but I
> > will
> > > leave this exercise for the readers.
> > >
> > > These simple rules allow to produce a much cleaner git history, which is
> > > easier to work with, bisect if needed, and in general do any sorts of
> > tracing.
> > >
> > > Please let me know if you have any questions.
> > > Cos
> > >
> > > On Wed, Apr 29, 2015 at 12:03PM, Yakov Zhdanov wrote:
> > > > Igniters,
> > > >
> > > > We have got pretty cool changes in current ignite-sprint-4 branch
> > (already
> > > > merged or are ready to be merged):
> > > > * Added Google Compute Engine TCP discovery IP finder.
> > > > * Added generic cloud TCP discovery IP finder (based on jcoulds).
> > > > * Added SortedEvictionPolicy.
> > > > * Added chaining for IgniteConfiguration and CacheConfiguration
> > setters.
> > > > * Improved expiry policy handling.
> > > > * Fixed job continuations.
> > > > * Fixed compilation and runtime with OpenJDK 7 & 8
> > > > * Many stability and fault-tolerance fixes.
> > > >
> > > > Let's try releasing it as apache-ignite-1.1!
> > > >
> > > > Please continue new functionality development in ignite-sprint-5
> > (whoever
> > > > has anything to commit to will create this branch).
> > > >
> > > > Make sure that no new functionality ignite-sprint-4.
> > > >
> > > > Release instructions can be found in DEVNOTES.txt - Ignite Release
> > > > Instructions section. in git -
> > > >
> > https://git-wip-us.apache.org/repos/asf?p=incubator-ignite.git;a=blob_plain;f=DEVNOTES.txt;hb=refs/heads/ignite-sprint-4
> > > >
> > > > --Yakov
> >
Re: Git practices [Was: Development process]
Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Thu, May 7, 2015 at 2:10 PM, Konstantin Boudnik <co...@apache.org> wrote:
> Another bit that confuses me a lot is the fact that there's no "master"
> branch
> in this project. It is very hard for a layman to find where to start and
> what
> to use. Anyone with even a rudimentary git experience is normally to start
> looking at the master branch: try to build it, run tests on it, etc.
>
> I got a private chat from a new user, who's looking to start contributing
> to
> the project but couldn't even get past running tests on master. And indeed,
> the master is two month behind.
>
> Another problem this model possesses is that there's no common point to
> branch-off release branches when the time comes. Hence, making maintenance
> releases would be quite a bit of hassle. It might be less problematic now
> as
> we go in the straight line, but later it could be a necessity to supplant
> fixes for older release.
>
> Once again, I'd like to propose to consider this git branching model
> http://nvie.com/posts/a-successful-git-branching-model/
> which proved to be very clean and development friendly in multiple projects
> I've used it at. I am happy to have a video call with anyone who wants to
> discuss it p2p any further.
>
I am looking at the model you are suggesting and it is pretty close to what
we do right now. The master should be as old as 1.0, which is normal since
that was our last release. When we release 1.1.0, we will merge it back
again. I think this is consistent with the diagram you are suggesting, no?
We could have another policy, and merge back to master with every sprint. I
think it sounds like you would prefer that better, right?
>
> Thoughts?
> Cos
>
> On Wed, Apr 29, 2015 at 03:48PM, Konstantin Boudnik wrote:
> > Guys,
> >
> > I don't want to hijack the original thread, so I am forking it ;)
> >
> > I've been watching the git tree for the sprint branches and I have one
> general
> > comment, which I always pushing for when it gets to correct use of git.
> Here
> > it is:
> > - during the development on a branch one has to re-sync with the main
> > integration branch (ie ignite-sprint-X)
> > - git has two options of doing this: merge and rebase
> > - merge preserves the history of the, well, branch merges - potentially
> > producing a complex intervened picture of branches like
> >
> > │ │ ● │ minor
> > │ │ ●━┑ Merge remote-tracking branch 'origin/ignite-sprint-4' into
> ignite-sprint-4
> > │ │ │ ●━┑ merge from ignite-790 to ignite-sprint-4
> > │ │ │ │ ● ignite-790: improvements after the review
> > │ │ │ │ ● review
> > │ │ │ │ ●━┑ Merge branches 'ignite-790' and 'ignite-sprint-4' of
> https://git-wip-us.apache.org/repo~
> > │ │ │ │ ● │ ignite-790: several times performance improvements
> > │ │ │ │ ● │ ignite-790: added example configs for clouds
> > │ │ │ │ ● │ ignite-790: default configs
> > │ │ │ │ ● │ ignite-790: fixes, improvements, tests
> > │ │ │ │ ● │ ignite-709: read private key for GCE from the file
> > │ │ │ │ ● │ temporal commit, forgot to switch to the branch
> > │ │ │ ●━┑ │ Merge branch 'ignite-734' into ignite-sprint-4
> > │ │ │ │ ● │ review
> > │ │ │ │ ●━┪ Merge branches 'ignite-734' and 'ignite-sprint-4' of
> https://git-wip-us.apache.org/repo~
> > │ │ │ │ ● │ ignite-734: finished implementation, provided tests
> > │ │ │ │ ● │ ignite-734: google cloud storage ipfinder is fully
> implemented
> > │ │ │ │ ● │ ignite-734: implemented ip finder
> > │ │ │ │ ● │ ignite-734: start implementing google ip finder
> > │ │ ● │ │ │ fixed NPE
> > │ ● │ │ │ │ javadoc fix
> > ●━┑ │ │ │ │ Merge branches 'ignite-839' and 'ignite-sprint-4' of
> https://git-wip-us.apache.org/repo~
> >
> > - rebase rewrites the new commits on top of a specified HEAD, hence
> producing
> > a flat line of development
> > - merge makes sense for feature branches integration, automatic branch
> > management by CI, etc.
> > - rebase makes sense when you're working on your feature for some time
> and
> > don't want to show the whole world how many times you were synching
> with
> > the integration branch. Keep in mind, that rebase rewrites the commits
> > hence changing their sha1 hashes. Be considerate about this and never
> > rebase something that has been already pushed to the remote repo
> > - In the example above perhaps no one would either care for the fact
> that
> > there was 5 consequent commits for ignite-790. This particular
> situation
> > could be fixes with 'squash' (a form of interactive rebase), but I
> will
> > leave this exercise for the readers.
> >
> > These simple rules allow to produce a much cleaner git history, which is
> > easier to work with, bisect if needed, and in general do any sorts of
> tracing.
> >
> > Please let me know if you have any questions.
> > Cos
> >
> > On Wed, Apr 29, 2015 at 12:03PM, Yakov Zhdanov wrote:
> > > Igniters,
> > >
> > > We have got pretty cool changes in current ignite-sprint-4 branch
> (already
> > > merged or are ready to be merged):
> > > * Added Google Compute Engine TCP discovery IP finder.
> > > * Added generic cloud TCP discovery IP finder (based on jcoulds).
> > > * Added SortedEvictionPolicy.
> > > * Added chaining for IgniteConfiguration and CacheConfiguration
> setters.
> > > * Improved expiry policy handling.
> > > * Fixed job continuations.
> > > * Fixed compilation and runtime with OpenJDK 7 & 8
> > > * Many stability and fault-tolerance fixes.
> > >
> > > Let's try releasing it as apache-ignite-1.1!
> > >
> > > Please continue new functionality development in ignite-sprint-5
> (whoever
> > > has anything to commit to will create this branch).
> > >
> > > Make sure that no new functionality ignite-sprint-4.
> > >
> > > Release instructions can be found in DEVNOTES.txt - Ignite Release
> > > Instructions section. in git -
> > >
> https://git-wip-us.apache.org/repos/asf?p=incubator-ignite.git;a=blob_plain;f=DEVNOTES.txt;hb=refs/heads/ignite-sprint-4
> > >
> > > --Yakov
>
Re: Git practices [Was: Development process]
Posted by Konstantin Boudnik <co...@apache.org>.
Another bit that confuses me a lot is the fact that there's no "master" branch
in this project. It is very hard for a layman to find where to start and what
to use. Anyone with even a rudimentary git experience is normally to start
looking at the master branch: try to build it, run tests on it, etc.
I got a private chat from a new user, who's looking to start contributing to
the project but couldn't even get past running tests on master. And indeed,
the master is two month behind.
Another problem this model possesses is that there's no common point to
branch-off release branches when the time comes. Hence, making maintenance
releases would be quite a bit of hassle. It might be less problematic now as
we go in the straight line, but later it could be a necessity to supplant
fixes for older release.
Once again, I'd like to propose to consider this git branching model
http://nvie.com/posts/a-successful-git-branching-model/
which proved to be very clean and development friendly in multiple projects
I've used it at. I am happy to have a video call with anyone who wants to
discuss it p2p any further.
Thoughts?
Cos
On Wed, Apr 29, 2015 at 03:48PM, Konstantin Boudnik wrote:
> Guys,
>
> I don't want to hijack the original thread, so I am forking it ;)
>
> I've been watching the git tree for the sprint branches and I have one general
> comment, which I always pushing for when it gets to correct use of git. Here
> it is:
> - during the development on a branch one has to re-sync with the main
> integration branch (ie ignite-sprint-X)
> - git has two options of doing this: merge and rebase
> - merge preserves the history of the, well, branch merges - potentially
> producing a complex intervened picture of branches like
>
> │ │ ● │ minor
> │ │ ●━┑ Merge remote-tracking branch 'origin/ignite-sprint-4' into ignite-sprint-4
> │ │ │ ●━┑ merge from ignite-790 to ignite-sprint-4
> │ │ │ │ ● ignite-790: improvements after the review
> │ │ │ │ ● review
> │ │ │ │ ●━┑ Merge branches 'ignite-790' and 'ignite-sprint-4' of https://git-wip-us.apache.org/repo~
> │ │ │ │ ● │ ignite-790: several times performance improvements
> │ │ │ │ ● │ ignite-790: added example configs for clouds
> │ │ │ │ ● │ ignite-790: default configs
> │ │ │ │ ● │ ignite-790: fixes, improvements, tests
> │ │ │ │ ● │ ignite-709: read private key for GCE from the file
> │ │ │ │ ● │ temporal commit, forgot to switch to the branch
> │ │ │ ●━┑ │ Merge branch 'ignite-734' into ignite-sprint-4
> │ │ │ │ ● │ review
> │ │ │ │ ●━┪ Merge branches 'ignite-734' and 'ignite-sprint-4' of https://git-wip-us.apache.org/repo~
> │ │ │ │ ● │ ignite-734: finished implementation, provided tests
> │ │ │ │ ● │ ignite-734: google cloud storage ipfinder is fully implemented
> │ │ │ │ ● │ ignite-734: implemented ip finder
> │ │ │ │ ● │ ignite-734: start implementing google ip finder
> │ │ ● │ │ │ fixed NPE
> │ ● │ │ │ │ javadoc fix
> ●━┑ │ │ │ │ Merge branches 'ignite-839' and 'ignite-sprint-4' of https://git-wip-us.apache.org/repo~
>
> - rebase rewrites the new commits on top of a specified HEAD, hence producing
> a flat line of development
> - merge makes sense for feature branches integration, automatic branch
> management by CI, etc.
> - rebase makes sense when you're working on your feature for some time and
> don't want to show the whole world how many times you were synching with
> the integration branch. Keep in mind, that rebase rewrites the commits
> hence changing their sha1 hashes. Be considerate about this and never
> rebase something that has been already pushed to the remote repo
> - In the example above perhaps no one would either care for the fact that
> there was 5 consequent commits for ignite-790. This particular situation
> could be fixes with 'squash' (a form of interactive rebase), but I will
> leave this exercise for the readers.
>
> These simple rules allow to produce a much cleaner git history, which is
> easier to work with, bisect if needed, and in general do any sorts of tracing.
>
> Please let me know if you have any questions.
> Cos
>
> On Wed, Apr 29, 2015 at 12:03PM, Yakov Zhdanov wrote:
> > Igniters,
> >
> > We have got pretty cool changes in current ignite-sprint-4 branch (already
> > merged or are ready to be merged):
> > * Added Google Compute Engine TCP discovery IP finder.
> > * Added generic cloud TCP discovery IP finder (based on jcoulds).
> > * Added SortedEvictionPolicy.
> > * Added chaining for IgniteConfiguration and CacheConfiguration setters.
> > * Improved expiry policy handling.
> > * Fixed job continuations.
> > * Fixed compilation and runtime with OpenJDK 7 & 8
> > * Many stability and fault-tolerance fixes.
> >
> > Let's try releasing it as apache-ignite-1.1!
> >
> > Please continue new functionality development in ignite-sprint-5 (whoever
> > has anything to commit to will create this branch).
> >
> > Make sure that no new functionality ignite-sprint-4.
> >
> > Release instructions can be found in DEVNOTES.txt - Ignite Release
> > Instructions section. in git -
> > https://git-wip-us.apache.org/repos/asf?p=incubator-ignite.git;a=blob_plain;f=DEVNOTES.txt;hb=refs/heads/ignite-sprint-4
> >
> > --Yakov