yade-dev team mailing list archive

[Robert Caulk <rob.caulk@xxxxxxxxx>]

Hello,

I agree with a migration to GitLab for all the points already mentioned. It
seems the impact on the Yade project can only be positive if I am reading
these emails correctly. I find Anton's review especially compelling - there
is nothing like a glowing recommendation from someone who has used the tool
for two years.

Since I have nothing more to contribute, I might as well point out that
GitHub is now owned by Microsoft, which means we will likely start seeing
some changes to GitHub that stem from shareholder appetite rather than the
open source ideology to which we have become accustomed. GitLab seems to be
the only alternative committed to open source. Does the Yade community want
to continue supporting open source projects or would it rather support
Microsoft's title as the most valuable company in the world?
<https://edition.cnn.com/2018/11/30/tech/microsoft-apple-most-valuable-company/index.html>

Cheers,

Robert

On Tue, Dec 4, 2018 at 10:02 AM Luc Sibille <luc.sibille@xxxxxxxxxxxxxxx>
wrote:

> Hello,
>
> I am rather a user of Yade than a developer. Hence, as a user, I would say
> that one of the possible weakness of Yade is that the release versions may
> not be always very stable, may include some features not always well
> validated (i.e. with some bugs), or may present strong discontinuities
> (from one version to another) in the way to use some features or in the
> computation itself (changing the numerical results).
> To be clear, I am not saying all that is going bad in Yade currently. It
> is a risk, it was not so good at the beginning of Yade but I think there
> have been great improvements with respect to these points since the
> beginning. So things are going in the right direction.
> Nevertheless, always as a user, when I know I am starting a work with Yade
> that will last several months or several years, I take care to keep on my
> computer, for this work, the same version of Yade with the same libraries
> during all the work (to avoid differences in the numerical results which
> could be induced by different versions and also to avoid the (too often)
> updates of the python scripts, but probably I am too lazy).
>
> In conclusion, I think it is important for the community of Yade Users
> (and too still enlarge this community and keep of even improve the
> confidence of users in Yade), to choose the way that will help to get the
> most stable and validated release versions of YADE (but I am not able to
> say which way it should be ;-) ).
>
> Probably, it is already obvious for you but I think important to stress
> this aspect.
>
> Best,
> Luc
>
>
> Le 03/12/2018 à 20:07, Bruno Chareyre a écrit :
>
> Thanks Jerôme, Janek, and Anton, for feedback.
> I'll try and address some questions.
>
> @Jérôme
> The objective of this thread is not to measure available human ressource
> but to use it more efficiently, instead. Recent git activity can provide us
> with example cases but it is not so relevant overall.
>
> *> 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 ?) *
>
> Yes, definitely most features of github have equivalent things in gitlab.
>
> *> 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
> ?*
>
> Exactly like github. Not an issue, we use free version in both cases.
>
> *> 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 ? *
>
> Everyone should work on a branch then merge, yes (public or not, it
> doesn't matter). It is good practice anyway and I think we need to move in
> this direction with or without gitlab. That's actually what many devs do
> already, see e.g. the yade-mpi branch (
> https://github.com/bchareyre/yade-mpi).
> When pushing to master there is no way to see the revision before
> accepting it. That is, it will be built and uploaded to public repos for
> everyone to download, without control. That would be fine if test coverage
> was approaching 100% but we are probably closer to 10%, it is not a safe
> situation.
> With merge requests revisions can be shown before entering the
> build/release loop.
>
>
> * > I think a more controlled / pre-assessed way of doing things is not be
> possible with our current HR. *
> The current post-assessment approach is not necessarily less time
> consuming and it does not seem to guarantee stability, hence why our HR are
> seeking improvement.
>
> * > **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).*
>
> A maintainer can't be happy with watching just a short selection of files.
> The whole project needs to be maintained consistently.
>
> *> I'm thus 100% happy with our current way of doing things*
>
> I am not.
> On the one hand, post-assessment implies reverts and there seem to be
> resistance against that.
> On the other hand, post-assessment without reverts would mean no
> assessment. We (Grenoble folk) are not going to spend human and cpu time on
> website and gitlab framework, just to host an unmaintained project.
> If someone wants to start an experimental branch where everyone can push
> with no control it is an interesting experiment (the main question being
> how long it will take to get broken) but the build framework will probably
> not checkout such branch.
> We need a stable codebase to protect users and to be able to develop
> further (various code couplings, MPI parallelization,...).
>
> >*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"... *
>
> That's why linux doesn't work on clusters. The "no warranty" clause
> explains it all. :)
> Finally, I realize that your response is pushing for more control. :)
>
>
> @Janek
>
> *> 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?*
>
> A lot of small commits is the essence of git. Obviously a big merge is
> easier to read as a whole than one commit every two days during a year or
> so. :)
>
> *> If so, then do you prefer that I push a whole separate fuild branch?*
>
> Absolutely. It is then possible to compare the two branches and to see all
> revisions from the accumulated commits.
>
> Cheers
>
> 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
>
>
> --
> Luc Sibille
> Université Grenoble Alpes / IUT1 de Grenoble
> Laboratoire 3SR: Sols, Solides, Structures, Risques
>
> Tel lab.: +33 (0)4 76 82 63 48
> Tel IUT: +33 (0)4 76 82 53 36
>
> _______________________________________________
> 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
>