Hi Bruno, thanks for taking the initiative here.
I have also used GitLab over the last year and I can only say positive things (especially not owned by Microsoft). If you asked me it is probably time to move everything (incl. code, Q&A, bug tracking etc.) to one single platform and to leave Launchpad and Github behind. Not sure if this is feasible. Yes, this would involve a bit of adaptation by some devs but I can only see benefits having everything on one platform. 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 ;-) Cheers Klaus On Wed, Nov 28, 2018 at 5:54 AM 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
