On Thu, May 07, 2015 at 02:53PM, Dmitriy Setrakyan wrote: > On Thu, May 7, 2015 at 2:10 PM, Konstantin Boudnik <[email protected]> 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 > >
