yade-dev team mailing list archive

[Jerome Duriez <jerome.duriez@xxxxxxxxx>]

Hello everyone,

In terms of Gitlab vs Github
********************************

Lazyness would tend to make me think to stay on github to avoid the need 
for adaptation (at least registering a new account on gitlab I guess ?), 
but this is not a real opinion. Hence some questions.

Would we have new features using gitlab ? I got more and more used to 
github and like it for its commit comments / pull requests / issues. We 
actually barely / do not use those... ;-) but maybe this could change in 
the future. Would we have the same on gitlab ? (Yes ?)

I also see there are gtilab versions that require a fee ([1] in your 
email). Are we going to use (for the integration framework) a free 
version ? Or do we start to have funds available for Yade development 
(which would be good news ;-) ). Do we use the actual gitlab, or a 
Grenoble-dedicated gitlab ([2] in your email) ?


Branch management model
*********************************

This a major discussion for me, that would deserve a thread on its own 
(and more than two participants hopefully), I think.


1. Regarding the possibility to update trunk from other branchs only: 
this would mean every dev should make a public branch before pushing to 
trunk/master ?


2. Regarding the more global question of pre-assessing changes:

I think a more controlled / pre-assessed way of doing things is not be 
possible with our current HR.

Typically, people can not do otherwise than looking closely at things 
when they are directly concerned (which is not always obvious to realize 
by the way). Everyone (both of us at least) have in mind our recent 
emails about https://bugs.launchpad.net/yade/+bug/1804621, the initial 
commit [*], and the ensuing email on Yade-dev [**]. In this case, the 
commit was announced beforehand on the mailing list, its exact 
consequences (in terms of modifying tuples to lists) stated [***]. And 
still an unforeseen problem did arise and many emails exchanged.

I'm taking this example to just support my point we don't have the HR 
with enough time and a fully comprehensive knowledge of Yade (if this is 
still possible) for meaningful pre-assessment reviews to happen.
I could take other examples (my past proposal for InsertionSortCollider 
-- link provided upon request, not an issue anymore --, a current pull 
request at [****]) to show things the other way: when changes have been 
refrained until a close review which never happened.


I'm thus 100% happy with our current way of doing things, as far as I'm 
concerned, and would not be in favor of changing things towards a 
tighter control. I think this could only freeze (collective, at least) 
development.

I understand this current way of doing things is stressful for computing 
cluster users, but I see this stress being inherent to an evolving free, 
open-source code that comes "with no warranty"...


Jérôme


[*] 
https://github.com/yade/trunk/commit/1db13fb1183b9e294dc9761da76cfa4fc2791cc1
[**] https://www.mail-archive.com/yade-dev@xxxxxxxxxxxxxxxxxxx/msg13652.html
[***] 
https://www.mail-archive.com/yade-dev@xxxxxxxxxxxxxxxxxxx/msg13339.html
[****] https://github.com/yade/trunk/pull/55

------
Chargé de Recherche / Research Associate
Irstea, RECOVER
3275 route de Cezanne – CS 40061 13182 Aix-en-Provence Cedex 5 FRANCE
+33 (0)4 42 66 99 21

On 27/11/2018 19:54, Bruno Chareyre 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