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
<mailto: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
<http://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
_______________________________________________
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
