ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Boudnik <...@apache.org>
Subject Re: Git practices [Was: Development process]
Date Thu, 07 May 2015 22:50:02 GMT
On Thu, May 07, 2015 at 02:53PM, Dmitriy Setrakyan wrote:
> On Thu, May 7, 2015 at 2:10 PM, Konstantin Boudnik <cos@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
> >

Mime
View raw message