yade-dev team mailing list archive

[janek_listy@xxxxx]

Regarding git branching model, I like very much the one described here:

https://nvie.com/posts/a-successful-git-branching-model/

Regarding branch management model I am not sure how to approach this.

When I will start pushing fuild calculations stuff it will be lots of tiny
commits :) I suppose it will be easier for me to merge everything
locally, then push it. Do you then prefer to review a rather large merge?
If so, then do you prefer that I push a whole separate fuild branch?
I suppose that would make sense: would be easier to track fuild
development irrespective of other bugfixing happening in master,
or other branches.

In general I suppose that merge requests from other branches make
a bit more sense. But I am not sure how this will look in practice.

Regarding the server placement - as you said - thanks to decentralised
architecture of git, this does not make any problem. For instance I have
configured my laptop to push my ~/.dotfiles simulateneously to three
different places (localhost gitserver and two remote locations). This is
to be safe in case if any of remote servers are inaccessible for some reason.

best regards
Janek
On 27 Nov 2018, 19:54 +0100, Bruno Chareyre <bruno.chareyre@xxxxxxxxxxxxxxx>, wrote:
> Hi devs,
> This is an announcement (1) and call for opinions (2).
>
> (1)  We will be migrating the integration framework to GitLab.com soon.
> That is: the config of buildbot, doc generation, and packaging will be
> using gitlab and will be hosted on gitlab.com [1], while hardware
> ressources will be provided locally by 3SR and/or Gricad's Gitlab [2].
> It should increase flexibility and decrease maintainance issues.
> Rémi made most of the work already (thank you!). Curious about it? You
> can check [3].
> The switch could happen in a couple months.
>
> _______
> (2)
> GitLab.com could also host the master branch in replacement of
> GitHub.com. It is not required though, and there is no problem to keep
> it on GitHub (like we kept bug tracking on launchpad after moving master
> to github), or not. This is open question to me. Migrating a branch is
> easy to do and easy to revert, so there is no technical constraint on
> us. It just needs to decide if we want to keep github or adopt gitlab
> for the source code (or both...).
>
> If source code was migrated, same question for bug tracking and answers?
>
> Whatever is decided for the above, the migration is also a good
> opportunity to think about the branch management model. Are we happy
> with it?
> Currently we have a centralized usage of a distributed CVS. Most
> contributors push to master directly  with strictly no pre-assessement
> of the contributions. Another possible (and classical) model would be to
> only accept merge requests from other branches. Which can have
> advantages, namely: easier to review since the the requests will usually
> collect a larger number of commits (all from a single user typically,
> hence self consistent), and more secured since it favors pre-assessment.
>
> Opinions?
>
> Cheers
>
> Bruno
>
> [1] https://about.gitlab.com/product/
> [2] https://gricad-gitlab.univ-grenoble-alpes.fr/
> [3] https://gitlab.com/remche/trunk
>
> --
> _______________
> Bruno Chareyre
> Associate Professor
> ENSE³ - Grenoble INP
> Lab. 3SR
> BP 53
> 38041 Grenoble cedex 9
> Tél : +33 4 56 52 86 21
> Fax : +33 4 76 82 70 43
> ________________
>
> Email too brief?
> Here's why! http://emailcharter.org
>
>
>
> _______________________________________________
> 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