yade-dev team mailing list archive

[Bruno Chareyre <bruno.chareyre@xxxxxxxxxxxxxxx>]

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.

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 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 same thing but written in a different way:
>
> 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.

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.
[1] https://github.com/bchareyre/yade-mpi


> * 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?


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

Agreed.



> 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.

  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

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.

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.


> 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.

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.


> 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).


> 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.


> 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.


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

Indeed. Not a progress.

Bruno