Re: [Yade-dev] Migrating to GitLab

2019-01-21 Thread Bruno Chareyre
Hi Janek, That's the difference between an example script and a regression test. If not found the function computing capillary forces will return zero (and printout a warning IIRC). So there is no segfault, but the result is not as it should. To me it is fine, it is a working script. B On

Re: [Yade-dev] Migrating to GitLab

2019-01-18 Thread Janek Kozicki
Jerome Duriez said: (by the date of Fri, 18 Jan 2019 09:07:02 +0100) > At the same time, Rémi left 3SR and, as a first consequence, we kind of > lost control on our wiki (even though I would not deeply miss it ;-) as > far as I'm concerned). I am going through the examples now, and I see

Re: [Yade-dev] Migrating to GitLab

2019-01-18 Thread Bruno Chareyre
On 1/18/19 9:07 AM, Jerome Duriez wrote: Thus, I was wondering if the move towards merge requests would be accompanied by new human No. and cpu ressources (coming from UMS Gricad ??) ? Yes. Bruno ___ Mailing list:

Re: [Yade-dev] Migrating to GitLab

2019-01-18 Thread Jerome Duriez
I actually had in mind your sentence We (Grenoble folk) are not going to spend human and cpu time on website and gitlab framework, just to host an unmaintained project. from [*], which kind of convinced me as a reason to modify our workflow towards a tighter control (interpreting the above

Re: [Yade-dev] Migrating to GitLab

2019-01-17 Thread Janek Kozicki
I am so lost that I don't know what questions to ask :) Bruno Chareyre said: (by the date of Thu, 17 Jan 2019 18:12:08 +0100) > On 1/17/19 5:53 PM, Jerome Duriez wrote: > >  it's maybe time to ask what does YADE development (if not "we") may > > expect as investment from Grenoble "in

Re: [Yade-dev] Migrating to GitLab

2019-01-17 Thread Bruno Chareyre
On 1/17/19 5:53 PM, Jerome Duriez wrote:  it's maybe time to ask what does YADE development (if not "we") may expect as investment from Grenoble "in exchange" ? Who is expecting something, from who, in exchange of what? You lost me, sorry. :) Bruno

Re: [Yade-dev] Migrating to GitLab

2019-01-17 Thread Jerome Duriez
Hi Bruno, Thank you for everything. It was a reason for new ways of doing things (the merge requests, in particular), it's maybe time to ask what does YADE development (if not "we") may expect as investment from Grenoble "in exchange" ? Good hopes to maintain all that we have in spite of

Re: [Yade-dev] Migrating to GitLab

2019-01-17 Thread Bruno Chareyre
Hi there, The repository is functional at: https://gitlab.com/yade-dev/trunk For using gitlab you can read the updated doc page https://yade-dev.gitlab.io/trunk/github.html#yade-github-label As soon as you have a gitlab account let me know your login name so I can add you to the project. I

Re: [Yade-dev] Migrating to GitLab

2019-01-13 Thread Anton Gladky
Hello Bruno, thanks for the explanation. That is more-less clear. From my side - OK. > would like to have you in the maintainers group if you agree. Yes, I agree. Thanks. Best regards Anton Am Fr., 11. Jan. 2019 um 14:53 Uhr schrieb Bruno Chareyre : > > > > On Thu, 10 Jan 2019 at 21:40,

Re: [Yade-dev] Migrating to GitLab

2019-01-11 Thread Janek Kozicki
It is clear to me now, it is simple IMHO. I like it. Anton, what do you think? Bruno Chareyre said: (by the date of Fri, 11 Jan 2019 14:50:56 +0100) > On Thu, 10 Jan 2019 at 21:40, Anton Gladky wrote: > > > Sorry guys, I still cannot understand, what brings: > > - renaming master->develop

Re: [Yade-dev] Migrating to GitLab

2019-01-11 Thread Bruno Chareyre
On Thu, 10 Jan 2019 at 21:40, Anton Gladky wrote: > Sorry guys, I still cannot understand, what brings: > - renaming master->develop > - having potentially broken/not-mergable experimental branch. > Oh yes, it's confused. Things will become more clear with a functional repo (I'm only waiting

Re: [Yade-dev] Migrating to GitLab

2019-01-10 Thread Anton Gladky
Sorry guys, I still cannot understand, what brings: - renaming master->develop - having potentially broken/not-mergable experimental branch. If somebody can summarize me it in 2-3 words - would be fine. For some "wild" stuff it is enough to have the own feature branch and everybody can do there,

Re: [Yade-dev] Migrating to GitLab

2019-01-10 Thread Janek Kozicki
OK, I think I finally understood your intentions: merge requests go to develop (renamed from master), with several devs approving it with www interface. experimental branch is not used for that, but for whatever wild stuff comes into mind. This way Jerome needs not to worry, and everyone is

Re: [Yade-dev] Migrating to GitLab

2019-01-09 Thread Bruno Chareyre
On 1/9/19 3:23 PM, Janek Kozicki wrote: in fact since all works happens in personal repos I could use this model (which I like) myself like I used it before. And afterwards do a MR ;) True. oh, I never insisted that everything must be done from CLI :-) I am not afraid of learning some

Re: [Yade-dev] Migrating to GitLab

2019-01-09 Thread Janek Kozicki
Janek Kozicki said: (by the date of Wed, 9 Jan 2019 15:23:09 +0100) > which I explained a bit in my other post :) > [...] will discuss in my other post. omg, sorry. That was very redundant. And this one is too ;) -- Janek Kozicki ___ Mailing

Re: [Yade-dev] Migrating to GitLab

2019-01-09 Thread Janek Kozicki
Anton Gladky said: (by the date of Tue, 8 Jan 2019 20:45:15 +0100) > Hi Bruno, > > > Anton, do you have comments on MR on Gitlab interface? Do you > > confirm that they are a must? > > Yes, definitely must have! As I told already each merge request can > be checked automatically by CI and

Re: [Yade-dev] Migrating to GitLab

2019-01-09 Thread Janek Kozicki
Jerome Duriez said: (by the date of Tue, 8 Jan 2019 18:51:26 +0100) > Yes, I actually meant the branches a single dev has to deal with, for > his modifications to finally be included into the code ;-) > (it's true however experimental would not be one of those if it's just > to make

Re: [Yade-dev] Migrating to GitLab

2019-01-09 Thread Janek Kozicki
Bruno Chareyre said: (by the date of Tue, 8 Jan 2019 17:50:02 +0100) > On Tue, 8 Jan 2019 at 09:56, Jerome Duriez wrote: > > > let's maybe try to avoid switching from only one branch to more than > > three ?... > > > > We have already 19 branches on github/yade/trunk, plus other branches

Re: [Yade-dev] Migrating to GitLab

2019-01-08 Thread Anton Gladky
Hi Bruno, > Anton, do you have comments on MR on Gitlab interface? Do you confirm that > they are a must? Yes, definitely must have! As I told already each merge request can be checked automatically by CI and reviewed by other developers (with "approve"-technique). > Did you ever hack the API

Re: [Yade-dev] Migrating to GitLab

2019-01-08 Thread Jerome Duriez
On 08/01/2019 17:50, Bruno Chareyre wrote: On Tue, 8 Jan 2019 at 09:56, Jerome Duriez > wrote: let's maybe try to avoid switching from only one branch to more than three ?... We have already 19 branches on github/yade/trunk, plus other branches

Re: [Yade-dev] Migrating to GitLab

2019-01-08 Thread Bruno Chareyre
On Tue, 8 Jan 2019 at 09:56, Jerome Duriez wrote: > let's maybe try to avoid switching from only one branch to more than > three ?... > We have already 19 branches on github/yade/trunk, plus other branches under personal accounts. Limiting the number of branches is not a realistic objective,

Re: [Yade-dev] Migrating to GitLab

2019-01-08 Thread Jerome Duriez
[..] with master-develop approach. [..] you really need to know, why do you need it. Thanks for feedback Anton, that's my point :-) Considering that a develop->master step still needs to be clarified, with different opinions at the moment between Bruno (below) and Janek (07/01/2019 à 17:31

Re: [Yade-dev] Migrating to GitLab

2019-01-07 Thread Anton Gladky
Hello all, last several years I did Yade releases and the process was the following. Before the release was done I created the corresponding release-branch (for example 0.60 [1]) and just tagged the new Yade version there. It worked relatively good. -->

Re: [Yade-dev] Migrating to GitLab

2019-01-07 Thread Janek Kozicki
Bruno Chareyre said: (by the date of Mon, 7 Jan 2019 16:59:53 +0100) > Daily builds would be based on the develop branch. good, that answer my question from other mail. > > (by the way, with a tighter control on development, would we still > > need a distinction between "yade" and

Re: [Yade-dev] Migrating to GitLab

2019-01-07 Thread Janek Kozicki
Bruno Chareyre said: (by the date of Sun, 6 Jan 2019 23:04:13 +0100) > Hi Janek, I think we are on the same line more or less. We only differ on > practical details, mainly the notion of merge request in gitlab. yes, I noticed the same thing too. It seems that my suggestion can be applied in

Re: [Yade-dev] Migrating to GitLab

2019-01-07 Thread Bruno Chareyre
On 1/7/19 1:12 PM, Jerome Duriez wrote: I could see just one point having an additional "develop": in the case where eg yadedaily packages would be built from master only, and not from develop. Is this a plan ? Daily builds would be based on the develop branch. (by the way, with a tighter

Re: [Yade-dev] Migrating to GitLab

2019-01-06 Thread Bruno Chareyre
Hi Janek, I think we are on the same line more or less. We only differ on practical details, mainly the notion of merge request in gitlab. On Sat, 5 Jan 2019 at 00:15, Janek Kozicki wrote: > > I just noticed that with my CGAL 4.13 attempt to fix I did a push to > master. Which felt uneasy. >

Re: [Yade-dev] Migrating to GitLab

2019-01-04 Thread Janek Kozicki
Bruno Chareyre said: (by the date of Tue, 11 Dec 2018 16:00:29 +0100) > On 12/5/18 7:21 AM, Klaus Thoeni wrote: > > 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

Re: [Yade-dev] Migrating to GitLab

2018-12-20 Thread janek_listy
Ok, so it seems that at the moment nothing can beat the launchpad interface, especially the questions & answers database with its history. So I agree the we keep launchpad for this. Regarding the sole git server choice - we know that decentralized nature of git turns this into a non issue.

Re: [Yade-dev] Migrating to GitLab

2018-12-14 Thread Robert Caulk
>> If you asked me it is probably time to move everything (incl. code, Q, bug tracking etc.) >> If source code was migrated, same question for bug tracking and answers? I looked into this. From what I can tell, GitLab only offers issue tracking, which is analgous to bug tracking on LP. Issue

Re: [Yade-dev] Migrating to GitLab

2018-12-11 Thread Klaus Thoeni
Hi Bruno, yes, that's right. Dev's should have the rights to do that. K On Wed, Dec 12, 2018 at 2:00 AM Bruno Chareyre < bruno.chare...@3sr-grenoble.fr> wrote: > > > On 12/5/18 7:21 AM, Klaus Thoeni wrote: > > I terms of branching, I think this should be kept flexible. I think > > branches

Re: [Yade-dev] Migrating to GitLab

2018-12-11 Thread Anton Gladky
Hello, I would vote for the option with merge requests. Yade has enough core developers to review, comment and accept those requests. And it is not a problem if the MR will take 2-3 days for the review process. In this case one can see in the GitLab-pipeline, whether the code compiles, tests

Re: [Yade-dev] Migrating to GitLab

2018-12-11 Thread Bruno Chareyre
On 12/5/18 7:21 AM, Klaus Thoeni wrote: 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 ;-) I think we need to distinguish

Re: [Yade-dev] Migrating to GitLab

2018-12-04 Thread Klaus Thoeni
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, bug tracking etc.) to one single platform and to leave

Re: [Yade-dev] Migrating to GitLab

2018-12-04 Thread Luc Scholtes
Hi all, Thank you all, specially Bruno, for your commitment to the project. I don't have any point to make against the migration as long as documentation follows accordingly for people like me not intensively involved in development and not exactly familiar with all this software versioning

Re: [Yade-dev] Migrating to GitLab

2018-12-04 Thread Robert Caulk
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

Re: [Yade-dev] Migrating to GitLab

2018-12-04 Thread Luc Sibille
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

Re: [Yade-dev] Migrating to GitLab

2018-12-03 Thread Bruno Chareyre
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.

Re: [Yade-dev] Migrating to GitLab

2018-12-02 Thread Anton Gladky
Hi, I think it is a very good idea to migrate the code to GirLab. After >2 years of using this project I can only say the positive about it. Simple setup of CI/CD, automatic check of merge requests and approve-technique can really improve the code quality and stability. Regards Anton Am Di.,

Re: [Yade-dev] Migrating to GitLab

2018-11-30 Thread janek_listy
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

Re: [Yade-dev] Migrating to GitLab

2018-11-30 Thread Jerome Duriez
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