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.chare...@3sr-grenoble.fr>, 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@lists.launchpad.net > Unsubscribe : https://launchpad.net/~yade-dev > More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp