ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: Git practices [Was: Development process]
Date Thu, 07 May 2015 21:53:03 GMT
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?

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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message