yade-dev team mailing list archive

[Janek Kozicki <janek_listy@xxxxx>]

Bruno Chareyre said:     (by the date of Sun, 6 Jan 2019 23:04:13 +0100)

> Hi Janek, I think we are on the same line more or less. We only differ on
> practical details, mainly the notion of merge request in gitlab.

yes, I noticed the same thing too. It seems that my suggestion can be
applied in miniature to each repo. While repos act as "larger
branches", and the same strategy works between them, just on a larger
scale :)

> On Sat, 5 Jan 2019 at 00:15, Janek Kozicki <janek_listy@xxxxx> wrote:
> >
> > I just noticed that with my CGAL 4.13 attempt to fix I did a push to
> > master. Which felt uneasy.
> >  
> Why? Do you refer to github or gitlab repo here? (remember that gitlab repo
> is not known by any other dev yet)

I refer to github. I felt uneasy because I would prefer to push new
stuff to develop. Not master. Master, at least for me, feels like
"it's certified to work" :)
If you run into problems on develop branch, you always know, that you
can compare with master and get reproducible results. Maybe `master`
could be called `stable` to reflect how I feel this.

> > I suppose that using
> > https://nvie.com/posts/a-successful-git-branching-model/
> > would help a lot. (short summary on
> > https://nvie.com/files/Git-branching-model.pdf )
> 
> It sounds good.
> 
> > I propose that:
> > 1. we will use feature branches with a specific name to hot-develop
> > features. (e.g. fluid)
> > 2. when feature is "almost ready" we merge it into develop branch
> > 3. when develop branch is stable we merge it into master using a release
> > branch
> 
> I agree. Only the last part "using a release branch" is not completely
> clear to me.

The "release branch" is actually useful, at least for me. I have a
short cheat-sheet for that, here it goes:
(it is from https://nvie.com/posts/a-successful-git-branching-model/ )

===
RELEASE BRANCH:
Release branches are created from the develop branch:

$ git checkout -b release-1.2 develop
$ ./bump-version.sh 1.2   # or whatever edits are necessary to change version number
$ git commit -a -m "Bumped version number to 1.2"

Finishing a release branch: merge to master

$ git checkout master
$ git merge --no-ff release-1.2
$ git tag -a 1.2

Merge to develop

$ git checkout develop
$ git merge --no-ff release-1.2

Delete unused branch:
$ git branch -d release-1.2
===

It is a little fiddling between the two branches. The point is, that
whatever conflicts arise during the merge, they do not mess up with
develop branch, and not mess up with master branch. They get solved
inside release branch. Which is deleted after merge is a success.

Most of the time, it's just 'nothing', when stuff goes smoothly. But
in some cases when you get conflicts, you suddenly are glad that you
are not on develop or master branch :) For example if you have problems
with this line:
$ git merge --no-ff release-1.2
Then you abort the merge (git reset --merge ORIG_HEAD
https://medium.com/@porteneuve/mastering-git-reset-commit-alchemy-ba3a83bdfddc funny read btw ;)).
Everything is reset on master, and you go back to release-1.2 to fix there.


Actually I have more of this cheat-sheet, for hotfixes it goes like that:
===
HOTFIX BRANCH:
Creating the hotfix branch:

$ git checkout -b hotfix-1.2.1 master
$ ./bump-version.sh 1.2.1
$ git commit -a -m "Bumped version number to 1.2.1"

Fix stuff, then:
$ git commit -m "Fixed severe production problem"

Finishing a hotfix branch, update master and tag the release:
$ git checkout master
$ git merge --no-ff hotfix-1.2.1
$ git tag -a 1.2.1

Merge into develop:
$ git checkout develop
$ git merge --no-ff hotfix-1.2.1

Example if git history messes up:
$ git reset --merge ORIG_HEAD
Then for example only pick specific commits:
$ git cherry-pick 81f7007
$ git cherry-pick 5bf2e3a

Delete unused branch:
$ git branch -d hotfix-1.2.1
===


> > The main branches
> > * master
> > * develop
> 
> Definitely.
> 
> Other branches:
> > * Feature branches
> >    + branch from develop (with command: git checkout -b myfeature develop)
> >    + merge to develop (with command: git checkout develop ; git merge
> > --no-ff myfeature )
> >    + naming: anything except `master`, `develop`, `release-*`, or
> > `hotfix-*`
> >  
> 
> Yes.
> Until now feature branches (e.g. yade-mpi [1]) are not centralized. They
> remain under personal github accounts.
> Whether those branches are/not pushed into the upstream repo as stateful
> branches makes no real difference in practice (in my view at least).
> github.com/bchareyre/yade-mpi/master is exactly one of the feature branches
> as they appear in your model. It will be merged into
> github.com/yade/trunk/master <http://github.com/yade/trunk> when ready (or
> into a "develop" branch).
> Equivalently I could have pushed a new "mpi" branch to yade/trunk, then
> start working on it, and later merge to yade/master.
> It makes nearly no difference in the final result but the later has
> downsides:
> - more noise on yade-dev (notifications for each push)
> - less flexibility  (some developers of yade-mpi have no access to
> yade/trunk and will probably never have, not possible with a centralized
> repo).
> - more time spent in management of rights, branch creation, etc.
> For theses reasons I would keep the decentralized approach of the current
> feature branches.

Yes, I see this now. Thanks for explanation. It makes a lot of sense.

> Not sure "--no-ff" is the best thing. I am more inclined to the opposite at
> the moment (rebase the feature branch + --only-ff), to make history more
> readable in master. That's what we did on github until now. We can still
> discuss it and try variants.

Ok, good. I see now that --ff-only is the safer one, good to try it first :)
But sometimes --no-ff might just quickly solve some simple problems.
And you always can `git reset --merge ORIG_HEAD` when in doubt.

> > * Release branches
> >    + branch from develop
> >    + merge to develop AND master
> >    + naming: `release-*`
> 
> That's still a bit unclear to me unfortunatey. What is the purpose of those?

I hope that my explanation above cleared this up?

With the exception that the release branches sometimes are not
deleted afterwards. Because for example, like you said in other mail
the binary package for ubuntu 16.04 must stay in an updated branch.

> > * Hotfix branches
> >    + branch from master
> >    + merge to develop AND master
> >    + naming: `hotfix-*`
> 
> Agreed.

Great :)

> > I will try to go back to your original point:  
> > > I think we need to distinguish two aspects:
> > > 1- do we "push" or do we "request-merge"?  
> >
> > I have no idea. It appears that current model is incompatible with
> > the one which I propose.  
> 
> If "current" means everyone pushing to master, then yes, it is
> incompatible. I'm also for moving toward a model closer to what you propose.

Agreed.
 
>   git checkout develop
> >   git merge --no-ff myfeature
> 
> This is only changing the local repo, that's your business as a local
> branch manager. It doesn't say anything about push vs. MR.
> The question is what happens after that, and there are two options:
> 1- push the merge to yade/trunk, so in the end you are still "pushing"
> 2- push to whateverBranch (remote), then MR from whateverBranch to
> yade/trunk/someBranch

Yes, I see the distinction now.
 
> I propose to make direct push impossible to both master and dev branches
> (if not the entire repo) so that 2- will be the only option. It fits very
> well in the feature-branch model.

Yes, this makes sense. So everyone would have their own repo and do
what they please. I would have develop branch in my repo, and some
feature branches. Then I would merge them to my local develop. And
afterwards _MR_ of my local develop to yade/trunk/develop

From then we would examine yade/trunk/develop and decide when it is
time to make a release and merge into master.

This extra step yade/trunk/develop ↔ release ↔ yade/trunk/master is
to ensure stability of master. To be able to recover from any
mistakes that may happen during release.

Question:
does it also mean that you propose no CLI interaction with
gitlab:yade/trunk to be allowed. And all that happens is accepting or
rejecting _MR_ in www interface? In fact I never used much any kind
of git www interfrace ;)


> > If he has no access rights to do this, then he does request-merge instead.
> 
> It is not a question of rights, it is a question of method, and that was my
> original point 1.
> MR is part of standard work cycle in gitlab CI, even if you have rights to
> accept your own MR it is still different from a CLI push, because it goes
> through gitlab toolchain.
 
Does 'gitlab CI'=='gitlab www interface' ?
 
> > And then the question reduces to: "do we request-merge to develop or do we
> > merge to it?". I think this is the same as the second question:
> >  
> > > 2- who is allowed to accept the merge requests?  
> >  
> 
> Nope. :)
> The question is still: do we push or do we MR to yade/trunk/branch
> (whatever the branch)?
> "who is allowed" is orthogonal.

ok, I get this now :)
 
> It seems that it's those who have the access rights :)
> > Are you asking who those people should be? Well obviously us ;)
> >  
> 
> There are many options. For instance it is possible to configure gitlab so
> that N devs need to agree for a MR to be accepted (you screw that with CLI
> merge/push).
> N can include the author of the merge request, or not.

oh, I didn't know that.

> > If you agree on that then the first thing to do is to
> > $ git co master
> > $ git branch develop
> > $ git co develop
> > and put this branch on github/gitlab.
> >  
> 
> Will be done. For feature branches nothing to do since everyone can create
> them already (even non-member of yade-dev).

OK.

> > And from now on master would accept only merges from
> > release-* branches and hotfix-* branches. And not direct commits.
> >  
> 
> Only _MR_ ;)
> It appears you are focusing on branches, while I speak of repos mainly.
> That's where the difference between push and MR appears.

OK. So repos are branches on a larger scale ;)

> > I am worried though that others might be afraid of this switch?
> > I think though that this would clean things up, and allow for more
> > active development without worrying about breaking something in the
> > master branch.
> >  
> 
> The impact on daily git usage can be very limited:
> 1. instead of yade/trunk the remote will be myprofile/trunk, "me" will
> checkout and push from/to that remote clone. No difference in git commands.
> 2. an additional step that does not exist atm will be to go to gitlab
> interface to create a merge request when ready to merge to yade/trunk
> There will be no need for casual devs to create new branches. Proof: there
> is no "mpi" branch in yade-mpi, neverless yade-mpi/master and yade/master
> are two distinct branches, there is no confusion between them, and one can
> be merged into the other one.

OK. the repo name can act like a branch name. This can work, if you are
happy to work with just one branch ;)

> > Regarding Robert's note about gitlab's issue tracking: [...] perhaps this
> > would produce even more
> > fragmentation.
> >  
> 
> Indeed. Not a progress.
> 
> Bruno


Jerome Duriez said:     (by the date of Mon, 7 Jan 2019 13:12:42 +0100)

> Hi,
> 
> Trying to (somewhat, at least) follow the discussion, I'd come back to
> 
> >     The main branches
> >     * master
> >     * develop
> >
> > Definitely.  
> 
> in connection with the above-mentioned web post [1].
> 
> 
> Thus, a question: What would be the purpose splitting / the definition 
> of "master" and "develop" ?
> To me, "master" in the sense of [1] would just correspond to our 
> releases. If yes, why would we need two git branches "master" and 
> "develop", vs using just our current "master" ?

develop is where stuff happens before it is released, may be unstable.

master is a cumulation of stable code and consecutive releases, guaranteed stability.

That's how I look at this.
 
> I could see just one point having an additional "develop": in the case 
> where eg yadedaily packages would be built from master only, and not 
> from develop. Is this a plan ?

Good question. Perhaps we would need yadedaily for master and yadehourly for develop? :)
That's a bit of a joke, actually. In fact I don't know.

> (by the way, with a tighter control on development, would we still need 
> a distinction between "yade" and "yadedaily" packages ?..)

yade is a package released through official linux-distro-specific channels.
yadedaily is released independently.

This type of distinction cannot disappear. Even if their names would change.

> Also, with "develop" and "master", I guess any proposal for code 
> modification would have to be closely examined and validated twice :
> - once to make it into "develop"
> - and once, to make it from "develop" into "master"
> ?...

yes, that's the main goal. Also to allow more flexibility. If you
commit to master you have to be super careful. If you commit to
develop you can experiment a little. Sometimes you will have to
experiment, because code merged from various different repos will
interact in unexpected ways. Not just merge conflicts. That's also
why we need more tests so badly.
 
> Would this make sense ? (not for me at the moment :-) )

Is it better now? :)

-- 
Janek Kozicki