yade-dev team mailing list archive

[Janek Kozicki <janek_listy@xxxxx>]

Bruno Chareyre said:     (by the date of Tue, 11 Dec 2018 16:00:29 +0100)

> On 12/5/18 7:21 AM, Klaus Thoeni wrote:
> > I terms of branching, I think this should be kept flexible. I think 
> > branches make sense if you work on major changes. However, I still 
> > think main devs should be able to push directly to the trunk, 
> > obviously with care ;-)  
> I think we need to distinguish two aspects:
> 1- do we "push" or do we "request-merge"?
> 2- who is allowed to accept the merge requests?
> 
> I don't see a real need to use direct push (point 1), one exception is 
> when fixing simple bugs maybe.
> What you say is more  (I guess) that some devs need enough rights to 
> accept their own MR (point 2). Right?

I just noticed that with my CGAL 4.13 attempt to fix I did a push to master. Which felt uneasy.

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 )

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

The same thing but written in a different way:

The main branches
* master
* develop

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-*`
* Release branches
   + branch from develop
   + merge to develop AND master
   + naming: `release-*`
* Hotfix branches
   + branch from master
   + merge to develop AND master
   + naming: `hotfix-*`


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. It feels to me like answering to a question:
"do we push myfeature into master or do we request-merge myfeature
into develop branch?".

If your question was phrased this way then my answer is: merge myfeature into develop.

This would mean that Feature branch is ready to merge into
develop branch. The main author of that feature branch would simply
decide that it's time to run command:

  git checkout develop
  git merge --no-ff myfeature

If he has no access rights to do this, then he does request-merge instead.

Please note that anyone could checkout that feature branch from gitlab, follow the
progress in this branch and contribute to it.

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?

It seems that it's those who have the access rights :)
Are you asking who those people should be? Well obviously us ;)

> I don't see a real need to use direct push (point 1), one exception is 
> when fixing simple bugs maybe.

In my proposition that would mean using a hotfix-* branch.


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.

And from now on master would accept only merges from
release-* branches and hotfix-* branches. And not direct commits.

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.



Regarding Robert's note about gitlab's issue tracking: I suppose that
this could replace launchpad's bug tracking interface, but since we
cannot move Q&A to gitlab then perhaps this would produce even more
fragmentation.


-- 
Janek Kozicki