Re: [Yade-dev] Migrating to GitLab

[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 1/18/19 7:53 PM, Janek Kozicki wrote:


"To run this script you need to have all 10 text files from
https://yade-dem.org/wiki/CapillaryTriaxialTest;

The funny thing is that this script runs and does not print an error,
so I am baffled. There are no text files here.


--
Janek Kozicki

___
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

Re: [Yade-dev] Migrating to GitLab

[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 that we better not
give up on wiki, because it is referenced in the examples!

in examples/capillaryLaplaceYoung/CapillaryPhys-example.py
there is written: 

"To run this script you need to have all 10 text files from
https://yade-dem.org/wiki/CapillaryTriaxialTest;

The funny thing is that this script runs and does not print an error,
so I am baffled. There are no text files here.


--
Janek Kozicki

___
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

Re: [Yade-dev] Migrating to GitLab

[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: 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

Re: [Yade-dev] Migrating to GitLab

[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 "unmaintained" as = to 
"open to modifications without any real assessment").


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).


Thus, I was wondering if the move towards merge requests would be 
accompanied by new human and cpu ressources (coming from UMS Gricad ??) 
? If yes, would these human and cpu ressources be additional to what we 
used to have until now (from 3SR), or "just" replace them ??



In summary (and with an inspiration from French idioms) : we will now 
face sticks (with the MR procedure), is there any carrot ? :-)



Jérôme

[*] https://www.mail-archive.com/yade-dev@lists.launchpad.net/msg13682.html

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

On 17/01/2019 18:12, Bruno Chareyre wrote:



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


___
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

Re: [Yade-dev] Migrating to GitLab

[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 exchange" ?  
> 
> Who is expecting something, from who, in exchange of what? You lost me, 
> sorry. :)

-- 
Janek Kozicki

___
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

Re: [Yade-dev] Migrating to GitLab

[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


___
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

Re: [Yade-dev] Migrating to GitLab

[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 possible changes on 
3SR side (see Rémi's departure) ? Or something more than we used to have ?



Looking forward to discuss the rules for approving the merge requests :-)


Jérôme

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

On 17/01/2019 17:40, Bruno Chareyre wrote:

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 just discovered a technical constraints which makes MR from personal 
repo awkward at the moment (although it could work with future gitlab 
versions maybe [1]).
The issue is that if a MR is generated from a forked repo to the 
parent yade-dev/trunk repo, then running the pipeline [3] requires 
that runners[2] be available in the forked repo. It is not possible to 
build the MR on the parent repo.
So unless you have the computational ressources and enough skills/IT 
support to configure runners locally, MR from personal repo will not 
be tested automatically. They can be handled (some MR could still make 
it that way) but it is not very convenient and it will take more time 
to be accepted.


It is pushing us toward a solution closer to what Janek suggested, 
which was based on multiple branches more than multiple repos. I.e. 
push (normal push) to different branches of yade-dev/trunk, then MR 
from that branch to master. Since both branches are under yade-dev the 
group runners will be used in this case.


Please check the doc and let me know if some information is missing.

I suggest to not conclude migration before Anton's freeze.
You can still work with github repo if you have local changes and you 
are affraid to mess up, I will merge gitub repo into gitlab if needed.

Else please consider pushing to gitlab any future revision.

There is an experimental repo at 
https://gitlab.com/yade-dev/trunk-exp. Feel free to break it.


Cheers

Bruno


[1] https://gitlab.com/gitlab-org/gitlab-ce/issues/23902
[2] hardware on which compilation and regression tests occur
[3] https://gitlab.com/yade-dev/trunk/pipelines (you can click on 
every step to visualize process like 
https://gitlab.com/yade-dev/trunk/-/jobs/147313249)


On 1/13/19 10:03 AM, Anton Gladky wrote:

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, 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 for runners to be assigned 
presently, then we can switch).


Master took the name "develop" in the course of this discussion 
because of the master-develop framework mentioned earlier (by Janek).
If we keep a single branch there is no reason to rename it. It will 
be master.


Experimental: my intention was to let people play with an 
experimental gitlab repo so they can learn a bit of gitlab CI 
without messing up yade history.
Of course they can play with git in their personal repo but the 
cycle will be incomplete if they are not assigned runners. Hence why 
I suggested a draft project, perhaps only in a transitory phase.
There is no added complexity, it's just a clone of the main repo 
with runners assigned (we will not assign runners to each other 
personal repo, I guess it goes without saying).
If kept in the long run then maybe experimental repo could help 
sharing experimental stuff through precompiled packages without 
interfering with main repo.
Say, someone finds out that pink-colored GUI is better and he wants 
others to try it. If it's in experimental others can simply apt-get 
install to inspect the achievement.


Anyway, I am not so active in the project, so feel free to make 
your own

decisions. Do not forget to keep simple things simple...


I would like to have you in the maintainers group if you agree. And 
thanks for comments, they are helpful.

Cheers

Bruno



Regards


Anton

Am Do., 10. Jan. 2019 um 20:16 Uhr schrieb 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 

Re: [Yade-dev] Migrating to GitLab

[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 just discovered a technical constraints which makes MR from personal 
repo awkward at the moment (although it could work with future gitlab 
versions maybe [1]).
The issue is that if a MR is generated from a forked repo to the parent 
yade-dev/trunk repo, then running the pipeline [3] requires that 
runners[2] be available in the forked repo. It is not possible to build 
the MR on the parent repo.
So unless you have the computational ressources and enough skills/IT 
support to configure runners locally, MR from personal repo will not be 
tested automatically. They can be handled (some MR could still make it 
that way) but it is not very convenient and it will take more time to be 
accepted.


It is pushing us toward a solution closer to what Janek suggested, which 
was based on multiple branches more than multiple repos. I.e. push 
(normal push) to different branches of yade-dev/trunk, then MR from that 
branch to master. Since both branches are under yade-dev the group 
runners will be used in this case.


Please check the doc and let me know if some information is missing.

I suggest to not conclude migration before Anton's freeze.
You can still work with github repo if you have local changes and you 
are affraid to mess up, I will merge gitub repo into gitlab if needed.

Else please consider pushing to gitlab any future revision.

There is an experimental repo at https://gitlab.com/yade-dev/trunk-exp. 
Feel free to break it.


Cheers

Bruno


[1] https://gitlab.com/gitlab-org/gitlab-ce/issues/23902
[2] hardware on which compilation and regression tests occur
[3] https://gitlab.com/yade-dev/trunk/pipelines (you can click on every 
step to visualize process like 
https://gitlab.com/yade-dev/trunk/-/jobs/147313249)


On 1/13/19 10:03 AM, Anton Gladky wrote:

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, 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 for runners to be assigned presently, then we can switch).

Master took the name "develop" in the course of this discussion because of the 
master-develop framework mentioned earlier (by Janek).
If we keep a single branch there is no reason to rename it. It will be master.

Experimental: my intention was to let people play with an experimental gitlab 
repo so they can learn a bit of gitlab CI without messing up yade history.
Of course they can play with git in their personal repo but the cycle will be 
incomplete if they are not assigned runners. Hence why I suggested a draft 
project, perhaps only in a transitory phase.
There is no added complexity, it's just a clone of the main repo with runners 
assigned (we will not assign runners to each other personal repo, I guess it 
goes without saying).
If kept in the long run then maybe experimental repo could help sharing 
experimental stuff through precompiled packages without interfering with main 
repo.
Say, someone finds out that pink-colored GUI is better and he wants others to 
try it. If it's in experimental others can simply apt-get install to inspect 
the achievement.


Anyway, I am not so active in the project, so feel free to make your own
decisions. Do not forget to keep simple things simple...


I would like to have you in the maintainers group if you agree. And thanks for 
comments, they are helpful.
Cheers

Bruno



Regards


Anton

Am Do., 10. Jan. 2019 um 20:16 Uhr schrieb 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 happy :)




Janek Kozicki said: (by the date of Wed, 9 Jan 2019 15:24:18 +0100)


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 reviewed by other developers
(with "approve"-technique).

very nice! I didn't know about this before.

I will have a look at that API which you mentioned.



I am fully support the feature-branch + merge request way of

Re: [Yade-dev] Migrating to GitLab

[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, 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 for runners to be assigned presently, then we can switch).
>
> Master took the name "develop" in the course of this discussion because of 
> the master-develop framework mentioned earlier (by Janek).
> If we keep a single branch there is no reason to rename it. It will be master.
>
> Experimental: my intention was to let people play with an experimental gitlab 
> repo so they can learn a bit of gitlab CI without messing up yade history.
> Of course they can play with git in their personal repo but the cycle will be 
> incomplete if they are not assigned runners. Hence why I suggested a draft 
> project, perhaps only in a transitory phase.
> There is no added complexity, it's just a clone of the main repo with runners 
> assigned (we will not assign runners to each other personal repo, I guess it 
> goes without saying).
> If kept in the long run then maybe experimental repo could help sharing 
> experimental stuff through precompiled packages without interfering with main 
> repo.
> Say, someone finds out that pink-colored GUI is better and he wants others to 
> try it. If it's in experimental others can simply apt-get install to inspect 
> the achievement.
>
>>
>> Anyway, I am not so active in the project, so feel free to make your own
>> decisions. Do not forget to keep simple things simple...
>
>
> I would like to have you in the maintainers group if you agree. And thanks 
> for comments, they are helpful.
> Cheers
>
> Bruno
>
>>
>>
>> Regards
>>
>>
>> Anton
>>
>> Am Do., 10. Jan. 2019 um 20:16 Uhr schrieb 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 happy :)
>> >
>> >
>> >
>> >
>> > Janek Kozicki said: (by the date of Wed, 9 Jan 2019 15:24:18 +0100)
>> >
>> > > 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 reviewed by other developers
>> > > > (with "approve"-technique).
>> > >
>> > > very nice! I didn't know about this before.
>> > >
>> > > I will have a look at that API which you mentioned.
>> > >
>> > >
>> > > > I am fully support the feature-branch + merge request way of
>> > > > working. It can really help to double check the code and implement
>> > > > some additional tests.
>> > >
>> > > So I am trying to wrap my head around this. We would have:
>> > >
>> > > --> other people's feature repos
>> > >  \
>> > > ->\ other people's feature repos
>> > > \MR\MR
>> > > --> experimental
>> > >   \   /   \   \   /  /
>> > > --> develop
>> > >\\
>> > > \\
>> > >  \Release 1   \Release 2
>> > >   \Release 1.1
>> > >
>> > > ?
>> > >
>> > > Bruno Chareyre said: (by the date of Tue, 8 Jan 2019 17:50:02 +0100)
>> > >
>> > > > I would propose develop+experimental for a start, with release 
>> > > > branches as
>> > > > in Anton's picture.
>> > >
>> > > So that would mean: rename master to develop, and create experimental?
>> > >
>> > > > Very liberal config for exp, and conservative for dev (even very
>> > > > conservative initially, we will see if it is too conservative).
>> > > > exp will *not* merge to develop, it will diverge progressively, most
>> > > > likely, but it is not an issue. It can be re-synced. No commits can be 
>> > > > lost
>> > > > since by definition a MR to exp is from somewhere.
>> > >
>> > > in other mail I only mentioned a nice method of solving conflicts.
>> > > Here let's focus on how you see that it should work. Especially I am
>> > > not sure what you mean by:
>> > >
>> > > "exp will *not* merge to develop, it will diverge progressively, most 
>> > > likely"
>> > >
>> > >
>> > > Jerome raises a very important question: where do you 

Re: [Yade-dev] Migrating to GitLab

[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
> > - 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 for runners to be assigned presently, then we can switch).
> 
> Master took the name "develop" in the course of this discussion because of
> the master-develop framework mentioned earlier (by Janek).
> If we keep a single branch there is no reason to rename it. It will be
> master.
> 
> Experimental: my intention was to let people play with an experimental
> gitlab repo so they can learn a bit of gitlab CI without messing up yade
> history.
> Of course they can play with git in their personal repo but the cycle will
> be incomplete if they are not assigned runners. Hence why I suggested a
> draft project, perhaps only in a transitory phase.
> There is no added complexity, it's just a clone of the main repo with
> runners assigned (we will not assign runners to each other personal repo, I
> guess it goes without saying).
> If kept in the long run then maybe experimental repo could help sharing
> experimental stuff through precompiled packages without interfering with
> main repo.
> Say, someone finds out that pink-colored GUI is better and he wants others
> to try it. If it's in experimental others can simply apt-get install to
> inspect the achievement.
> 
> 
> > Anyway, I am not so active in the project, so feel free to make your own
> > decisions. Do not forget to keep simple things simple...
> >  
> 
> I would like to have you in the maintainers group if you agree. And thanks
> for comments, they are helpful.
> Cheers
> 
> Bruno
> 
> 
> >
> > Regards
> >
> >
> > Anton
> >
> > Am Do., 10. Jan. 2019 um 20:16 Uhr schrieb Janek Kozicki <  
> > janek_li...@wp.pl>:
> > >
> > > 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 happy :)
> > >
> > >
> > >
> > >
> > > Janek Kozicki said: (by the date of Wed, 9 Jan 2019 15:24:18 +0100)
> > >  
> > > > 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 reviewed by other developers
> > > > > (with "approve"-technique).  
> > > >
> > > > very nice! I didn't know about this before.
> > > >
> > > > I will have a look at that API which you mentioned.
> > > >
> > > >  
> > > > > I am fully support the feature-branch + merge request way of
> > > > > working. It can really help to double check the code and implement
> > > > > some additional tests.  
> > > >
> > > > So I am trying to wrap my head around this. We would have:
> > > >  
> > > > --> other people's feature repos  
> > > >  \  
> > > > ->\ other people's feature repos  
> > > > \MR\MR  
> > > > --> experimental  
> > > >   \   /   \   \   /  /  
> > > > --> develop  
> > > >\\
> > > > \\
> > > >  \Release 1   \Release 2
> > > >   \Release 1.1
> > > >
> > > > ?
> > > >
> > > > Bruno Chareyre said: (by the date of Tue, 8 Jan 2019 17:50:02  
> > +0100)  
> > > >  
> > > > > I would propose develop+experimental for a start, with release  
> > branches as  
> > > > > in Anton's picture.  
> > > >
> > > > So that would mean: rename master to develop, and create experimental?
> > > >  
> > > > > Very liberal config for exp, and conservative for dev (even very
> > > > > conservative initially, we will see if it is too conservative).
> > > > > exp will *not* merge to develop, it will diverge progressively, most
> > > > > likely, but it is not an issue. It can be re-synced. No commits can  
> > be lost  
> > > > > since by definition a MR to exp is from somewhere.  
> > > >
> > > > in other mail I only mentioned a nice method of solving conflicts.
> > > > Here let's focus on how you see that it should work. Especially I am
> > > > not sure what you mean by:
> > > >
> > > > "exp will *not* merge to develop, it will diverge progressively, most  
> > likely"  
> > > >
> > > >
> > > > 

Re: [Yade-dev] Migrating to GitLab

[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 for runners to be assigned presently, then we can switch).

Master took the name "develop" in the course of this discussion because of
the master-develop framework mentioned earlier (by Janek).
If we keep a single branch there is no reason to rename it. It will be
master.

Experimental: my intention was to let people play with an experimental
gitlab repo so they can learn a bit of gitlab CI without messing up yade
history.
Of course they can play with git in their personal repo but the cycle will
be incomplete if they are not assigned runners. Hence why I suggested a
draft project, perhaps only in a transitory phase.
There is no added complexity, it's just a clone of the main repo with
runners assigned (we will not assign runners to each other personal repo, I
guess it goes without saying).
If kept in the long run then maybe experimental repo could help sharing
experimental stuff through precompiled packages without interfering with
main repo.
Say, someone finds out that pink-colored GUI is better and he wants others
to try it. If it's in experimental others can simply apt-get install to
inspect the achievement.


> Anyway, I am not so active in the project, so feel free to make your own
> decisions. Do not forget to keep simple things simple...
>

I would like to have you in the maintainers group if you agree. And thanks
for comments, they are helpful.
Cheers

Bruno


>
> Regards
>
>
> Anton
>
> Am Do., 10. Jan. 2019 um 20:16 Uhr schrieb Janek Kozicki <
> janek_li...@wp.pl>:
> >
> > 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 happy :)
> >
> >
> >
> >
> > Janek Kozicki said: (by the date of Wed, 9 Jan 2019 15:24:18 +0100)
> >
> > > 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 reviewed by other developers
> > > > (with "approve"-technique).
> > >
> > > very nice! I didn't know about this before.
> > >
> > > I will have a look at that API which you mentioned.
> > >
> > >
> > > > I am fully support the feature-branch + merge request way of
> > > > working. It can really help to double check the code and implement
> > > > some additional tests.
> > >
> > > So I am trying to wrap my head around this. We would have:
> > >
> > > --> other people's feature repos
> > >  \
> > > ->\ other people's feature repos
> > > \MR\MR
> > > --> experimental
> > >   \   /   \   \   /  /
> > > --> develop
> > >\\
> > > \\
> > >  \Release 1   \Release 2
> > >   \Release 1.1
> > >
> > > ?
> > >
> > > Bruno Chareyre said: (by the date of Tue, 8 Jan 2019 17:50:02
> +0100)
> > >
> > > > I would propose develop+experimental for a start, with release
> branches as
> > > > in Anton's picture.
> > >
> > > So that would mean: rename master to develop, and create experimental?
> > >
> > > > Very liberal config for exp, and conservative for dev (even very
> > > > conservative initially, we will see if it is too conservative).
> > > > exp will *not* merge to develop, it will diverge progressively, most
> > > > likely, but it is not an issue. It can be re-synced. No commits can
> be lost
> > > > since by definition a MR to exp is from somewhere.
> > >
> > > in other mail I only mentioned a nice method of solving conflicts.
> > > Here let's focus on how you see that it should work. Especially I am
> > > not sure what you mean by:
> > >
> > > "exp will *not* merge to develop, it will diverge progressively, most
> likely"
> > >
> > >
> > > Jerome raises a very important question: where do you merge request to?
> > >
> > > Jerome wants to stay away from experimental and do merge requests to
> develop?
> > >
> > > It means that it eliminates the buffer (in my previous posts it
> > > was a buffer between develop ↔ master, according to Bruno's naming
> > > suggestion that would be a buffer between experimental ↔ develop)
> > > which I was proposing.
> > >
> > > Do we want this buffer?
> > >
> > >
> > > --
> > > 

Re: [Yade-dev] Migrating to GitLab

[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, all, what they want.

Anyway, I am not so active in the project, so feel free to make your own
decisions. Do not forget to keep simple things simple...

Regards


Anton

Am Do., 10. Jan. 2019 um 20:16 Uhr schrieb 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 happy :)
>
>
>
>
> Janek Kozicki said: (by the date of Wed, 9 Jan 2019 15:24:18 +0100)
>
> > 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 reviewed by other developers
> > > (with "approve"-technique).
> >
> > very nice! I didn't know about this before.
> >
> > I will have a look at that API which you mentioned.
> >
> >
> > > I am fully support the feature-branch + merge request way of
> > > working. It can really help to double check the code and implement
> > > some additional tests.
> >
> > So I am trying to wrap my head around this. We would have:
> >
> > --> other people's feature repos
> >  \
> > ->\ other people's feature repos
> > \MR\MR
> > --> experimental
> >   \   /   \   \   /  /
> > --> develop
> >\\
> > \\
> >  \Release 1   \Release 2
> >   \Release 1.1
> >
> > ?
> >
> > Bruno Chareyre said: (by the date of Tue, 8 Jan 2019 17:50:02 +0100)
> >
> > > I would propose develop+experimental for a start, with release branches as
> > > in Anton's picture.
> >
> > So that would mean: rename master to develop, and create experimental?
> >
> > > Very liberal config for exp, and conservative for dev (even very
> > > conservative initially, we will see if it is too conservative).
> > > exp will *not* merge to develop, it will diverge progressively, most
> > > likely, but it is not an issue. It can be re-synced. No commits can be 
> > > lost
> > > since by definition a MR to exp is from somewhere.
> >
> > in other mail I only mentioned a nice method of solving conflicts.
> > Here let's focus on how you see that it should work. Especially I am
> > not sure what you mean by:
> >
> > "exp will *not* merge to develop, it will diverge progressively, most 
> > likely"
> >
> >
> > Jerome raises a very important question: where do you merge request to?
> >
> > Jerome wants to stay away from experimental and do merge requests to 
> > develop?
> >
> > It means that it eliminates the buffer (in my previous posts it
> > was a buffer between develop ↔ master, according to Bruno's naming
> > suggestion that would be a buffer between experimental ↔ develop)
> > which I was proposing.
> >
> > Do we want this buffer?
> >
> >
> > --
> > Janek Kozicki
> >
> > ___
> > 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
>
>
> --
> Janek Kozicki   http://janek.kozicki.pl/  |
>
> ___
> 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

Re: [Yade-dev] Migrating to GitLab

[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 happy :)




Janek Kozicki said: (by the date of Wed, 9 Jan 2019 15:24:18 +0100)

> 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 reviewed by other developers
> > (with "approve"-technique).  
> 
> very nice! I didn't know about this before.
> 
> I will have a look at that API which you mentioned.
> 
> 
> > I am fully support the feature-branch + merge request way of
> > working. It can really help to double check the code and implement
> > some additional tests.  
> 
> So I am trying to wrap my head around this. We would have:
> 
> --> other people's feature repos  
>  \
> ->\ other people's feature repos  
> \MR\MR
> --> experimental  
>   \   /   \   \   /  /
> --> develop
>\\
> \\
>  \Release 1   \Release 2
>   \Release 1.1
> 
> ?
> 
> Bruno Chareyre said: (by the date of Tue, 8 Jan 2019 17:50:02 +0100)
> 
> > I would propose develop+experimental for a start, with release branches as
> > in Anton's picture.  
> 
> So that would mean: rename master to develop, and create experimental?
> 
> > Very liberal config for exp, and conservative for dev (even very
> > conservative initially, we will see if it is too conservative).
> > exp will *not* merge to develop, it will diverge progressively, most
> > likely, but it is not an issue. It can be re-synced. No commits can be lost
> > since by definition a MR to exp is from somewhere.  
> 
> in other mail I only mentioned a nice method of solving conflicts.
> Here let's focus on how you see that it should work. Especially I am
> not sure what you mean by:
> 
> "exp will *not* merge to develop, it will diverge progressively, most likely"
> 
> 
> Jerome raises a very important question: where do you merge request to?
> 
> Jerome wants to stay away from experimental and do merge requests to develop?
> 
> It means that it eliminates the buffer (in my previous posts it
> was a buffer between develop ↔ master, according to Bruno's naming
> suggestion that would be a buffer between experimental ↔ develop)
> which I was proposing.
> 
> Do we want this buffer?
> 
> 
> -- 
> Janek Kozicki
> 
> ___
> 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


-- 
Janek Kozicki   http://janek.kozicki.pl/  |

___
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

Re: [Yade-dev] Migrating to GitLab

[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 www-clicking ;) I was simply
unfamiliar with this.


I, to, would like to know if it can be done. There seem to be frequent 
questions about that and various tools to achieve it. But yes, a few 
clicks is not that bad. :)


Bruno



___
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

Re: [Yade-dev] Migrating to GitLab

[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 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

Re: [Yade-dev] Migrating to GitLab

[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 reviewed by other developers
> (with "approve"-technique).

very nice! I didn't know about this before.

I will have a look at that API which you mentioned.


> I am fully support the feature-branch + merge request way of
> working. It can really help to double check the code and implement
> some additional tests.

So I am trying to wrap my head around this. We would have:

--> other people's feature repos
 \
->\ other people's feature repos
\MR\MR
--> experimental
  \   /   \   \   /  /
--> develop  
   \\
\\
 \Release 1   \Release 2
  \Release 1.1

?

Bruno Chareyre said: (by the date of Tue, 8 Jan 2019 17:50:02 +0100)

> I would propose develop+experimental for a start, with release branches as
> in Anton's picture.

So that would mean: rename master to develop, and create experimental?

> Very liberal config for exp, and conservative for dev (even very
> conservative initially, we will see if it is too conservative).
> exp will *not* merge to develop, it will diverge progressively, most
> likely, but it is not an issue. It can be re-synced. No commits can be lost
> since by definition a MR to exp is from somewhere.

in other mail I only mentioned a nice method of solving conflicts.
Here let's focus on how you see that it should work. Especially I am
not sure what you mean by:

"exp will *not* merge to develop, it will diverge progressively, most likely"


Jerome raises a very important question: where do you merge request to?

Jerome wants to stay away from experimental and do merge requests to develop?

It means that it eliminates the buffer (in my previous posts it
was a buffer between develop ↔ master, according to Bruno's naming
suggestion that would be a buffer between experimental ↔ develop)
which I was proposing.

Do we want this buffer?


-- 
Janek Kozicki

___
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

Re: [Yade-dev] Migrating to GitLab

[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 experiments..)

Please have a look at that
https://hackernoon.com/fix-conflicts-only-once-with-git-rerere-7d116b2cec67
which I explained a bit in my other post :)

The other important question which you raised I will discuss in my other post.

-- 
Janek Kozicki

___
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

Re: [Yade-dev] Migrating to GitLab

[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 under
> personal accounts.
> Limiting the number of branches is not a realistic objective, don't worry
> about that. It will become more clear with concrete usage, and you will not
> have to handle them all anyway.
> This being said, I'm also not sure we really need that develop-master
> duality.

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 ;)
 
> Very liberal config for exp, and conservative for dev (even very
> conservative initially, we will see if it is too conservative).
> exp will *not* merge to develop, it will diverge progressively, most
> likely, but it is not an issue. It can be re-synced. No commits can be lost
> since by definition a MR to exp is from somewhere.

To re-sync the method of doing control merges can help a lot:
https://hackernoon.com/fix-conflicts-only-once-with-git-rerere-7d116b2cec67

It works in such a way, that when you feel like it, you try to merge
exp with dev branch. See the conflicts and resolve them. Then delete
this merge so that it is not polluting your history.

When the time comes to do the real merge git will remember all your
resolved conflicts that you periodically were doing, and will apply
them.

This is awesome, because you solve conflict once, and never go back
to it. The best part is that even when the conflict occurs again in
some other branch, git still remembers how you solved it.

I have just recently found that method and still need to employ it in
my workflow. But it is very promising.

 
> Anton, do you have comments on MR on Gitlab interface? Do you confirm that
> they are a must? Did you ever hack the API to trigger them from CLI (that
> would mae Janek happy ;) )?

oh, I never insisted that everything must be done from CLI :-)
I am not afraid of learning some www-clicking ;) I was simply
unfamiliar with this.


Janek

___
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

Re: [Yade-dev] Migrating to GitLab

[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 to trigger them from CLI (that would mae Janek 
> happy ;) )?

A year ago I had successfully migrated almost 1000 git-repos from one
service to Gtilab
(new salsa.debian.org) using GitLab-API and was very satisfied. I have
never used
it before, and it took just some hours to do it. API is good documented!

The only develop-master privilege, which I can imaging, is the
automatic build of
stable-yade packages. Master-branch should be synced into the Launchpad and
the stable packages will be built after each sync. But Yade releases
are not so often,
not sure it will make any sense.

[1] https://lists.debian.org/debian-science/2017/12/msg00029.html

Best regards

Anton

Am Di., 8. Jan. 2019 um 17:52 Uhr schrieb 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, don't worry 
> about that. It will become more clear with concrete usage, and you will not 
> have to handle them all anyway.
> This being said, I'm also not sure we really need that develop-master duality.
>
> I would propose develop+experimental for a start, with release branches as in 
> Anton's picture.
> Very liberal config for exp, and conservative for dev (even very conservative 
> initially, we will see if it is too conservative).
> exp will not merge to develop, it will diverge progressively, most likely, 
> but it is not an issue. It can be re-synced. No commits can be lost since by 
> definition a MR to exp is from somewhere.
>
> Anton, do you have comments on MR on Gitlab interface? Do you confirm that 
> they are a must? Did you ever hack the API to trigger them from CLI (that 
> would mae Janek happy ;) )?
> Thx
> Bruno
>
>>
>> On 07/01/2019 20:36, Anton Gladky wrote:
>> > --> develop
>> >\\
>> > \ \
>> >  \Release 1 \Release 2
>> >   \Release 1.1
>> >
>> > I can remember only a couple of times, where the hot-fixes were
>> > needed to be integrated into the release-branch due to some serious
>> > stability or functionality issues.
>> >
>> > Last years I have an experience of work with master-develop
>> > approach. It is not bad. But you really need to know, why do
>> > you need it.
>> >
>> > I am fully support the feature-branch + merge request way of working.
>> > It can really help to double check the code and implement some
>> > additional tests.
>> >
>> > [1] https://github.com/yade/trunk/tree/0.60
>> >
>> > My 2cts
>> >
>> > Regards
>> >
>> > Anton
>> >
>> > Am Mo., 7. Jan. 2019 um 17:39 Uhr schrieb 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 "yadedaily" packages ?..)
>> >>> Yade is stable release, not updated very often, included in main
>> >>> debian/ubuntu repos.
>> >>> Yadedaily is updated  more than daily, after each change to the source
>> >>> code, not included in debian/ubuntu repos.
>> >>> They are very different things and I think we need both.
>> >> agreed.
>> >>
>>  Also, with "develop" and "master", I guess any proposal for code
>>  modification would have to be closely examined and validated twice :
>>  - once to make it into "develop"
>>  - and once, to make it from "develop" into "master"
>>  ?...
>> >>> There is no reason to check the develop->master merge if everything in
>> >>> develop is already validated by regtests + human review.
>> >>> Our github/master corresponds to "develop" more or less.
>> >>> Merging develop into master in the new model would correspond to Anton
>> >>> calling for update and releasing 2018.b. More or less.
>> >> agred.
>> >>
>> >>> We probably need a liberal, truly unstable repo on the top of this, at
>> >>> least in a transitory phase, so that everyone can play with gitlab a bit
>> >>> and break everything with no limit. For instance to compare --no-ff,
>> >>> --only-ff, and other variants.
>> >> how about calling it experimental ? :-))
>> >>
>> >> And yes, we definitely need something like that.
>> >> Where git reset --hard is nothing to be afraid of.
>> >>
>> >> --
>> >> Janek Kozicki
>> >>
>> >> ___
>> >> Mailing list: https://launchpad.net/~yade-dev
>> >> 

Re: [Yade-dev] Migrating to GitLab

[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 
under personal accounts.
Limiting the number of branches is not a realistic objective, don't 
worry about that. It will become more clear with concrete usage, and 
you will not have to handle them all anyway.


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 experiments..)


___
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

Re: [Yade-dev] Migrating to GitLab

[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, don't worry
about that. It will become more clear with concrete usage, and you will not
have to handle them all anyway.
This being said, I'm also not sure we really need that develop-master
duality.

I would propose develop+experimental for a start, with release branches as
in Anton's picture.
Very liberal config for exp, and conservative for dev (even very
conservative initially, we will see if it is too conservative).
exp will *not* merge to develop, it will diverge progressively, most
likely, but it is not an issue. It can be re-synced. No commits can be lost
since by definition a MR to exp is from somewhere.

Anton, do you have comments on MR on Gitlab interface? Do you confirm that
they are a must? Did you ever hack the API to trigger them from CLI (that
would mae Janek happy ;) )?
Thx
Bruno


> On 07/01/2019 20:36, Anton Gladky wrote:
> > --> develop
> >\\
> > \ \
> >  \Release 1 \Release 2
> >   \Release 1.1
> >
> > I can remember only a couple of times, where the hot-fixes were
> > needed to be integrated into the release-branch due to some serious
> > stability or functionality issues.
> >
> > Last years I have an experience of work with master-develop
> > approach. It is not bad. But you really need to know, why do
> > you need it.
> >
> > I am fully support the feature-branch + merge request way of working.
> > It can really help to double check the code and implement some
> > additional tests.
> >
> > [1] https://github.com/yade/trunk/tree/0.60
> >
> > My 2cts
> >
> > Regards
> >
> > Anton
> >
> > Am Mo., 7. Jan. 2019 um 17:39 Uhr schrieb Janek Kozicki <
> janek_li...@wp.pl>:
> >> 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 "yadedaily" packages ?..)
> >>> Yade is stable release, not updated very often, included in main
> >>> debian/ubuntu repos.
> >>> Yadedaily is updated  more than daily, after each change to the source
> >>> code, not included in debian/ubuntu repos.
> >>> They are very different things and I think we need both.
> >> agreed.
> >>
>  Also, with "develop" and "master", I guess any proposal for code
>  modification would have to be closely examined and validated twice :
>  - once to make it into "develop"
>  - and once, to make it from "develop" into "master"
>  ?...
> >>> There is no reason to check the develop->master merge if everything in
> >>> develop is already validated by regtests + human review.
> >>> Our github/master corresponds to "develop" more or less.
> >>> Merging develop into master in the new model would correspond to Anton
> >>> calling for update and releasing 2018.b. More or less.
> >> agred.
> >>
> >>> We probably need a liberal, truly unstable repo on the top of this, at
> >>> least in a transitory phase, so that everyone can play with gitlab a
> bit
> >>> and break everything with no limit. For instance to compare --no-ff,
> >>> --only-ff, and other variants.
> >> how about calling it experimental ? :-))
> >>
> >> And yes, we definitely need something like that.
> >> Where git reset --hard is nothing to be afraid of.
> >>
> >> --
> >> Janek Kozicki
> >>
> >> ___
> >> 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
>
>
> ___
> 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

Re: [Yade-dev] Migrating to GitLab

[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 email) --- which is normal in a discussion phase ---

, considering a third experimental branch appears in the discussion
, plus the branchs for each dev,

let's maybe try to avoid switching from only one branch to more than 
three ?...



Thanks for your motivation !

Jérôme

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

On 07/01/2019 20:36, Anton Gladky wrote:

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.

--> develop
   \\
\ \
 \Release 1 \Release 2
  \Release 1.1

I can remember only a couple of times, where the hot-fixes were
needed to be integrated into the release-branch due to some serious
stability or functionality issues.

Last years I have an experience of work with master-develop
approach. It is not bad. But you really need to know, why do
you need it.

I am fully support the feature-branch + merge request way of working.
It can really help to double check the code and implement some
additional tests.

[1] https://github.com/yade/trunk/tree/0.60

My 2cts

Regards

Anton

Am Mo., 7. Jan. 2019 um 17:39 Uhr schrieb 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 "yadedaily" packages ?..)

Yade is stable release, not updated very often, included in main
debian/ubuntu repos.
Yadedaily is updated  more than daily, after each change to the source
code, not included in debian/ubuntu repos.
They are very different things and I think we need both.

agreed.


Also, with "develop" and "master", I guess any proposal for code
modification would have to be closely examined and validated twice :
- once to make it into "develop"
- and once, to make it from "develop" into "master"
?...

There is no reason to check the develop->master merge if everything in
develop is already validated by regtests + human review.
Our github/master corresponds to "develop" more or less.
Merging develop into master in the new model would correspond to Anton
calling for update and releasing 2018.b. More or less.

agred.


We probably need a liberal, truly unstable repo on the top of this, at
least in a transitory phase, so that everyone can play with gitlab a bit
and break everything with no limit. For instance to compare --no-ff,
--only-ff, and other variants.

how about calling it experimental ? :-))

And yes, we definitely need something like that.
Where git reset --hard is nothing to be afraid of.

--
Janek Kozicki

___
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



___
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

Re: [Yade-dev] Migrating to GitLab

[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.

--> develop
  \\
   \ \
\Release 1 \Release 2
 \Release 1.1

I can remember only a couple of times, where the hot-fixes were
needed to be integrated into the release-branch due to some serious
stability or functionality issues.

Last years I have an experience of work with master-develop
approach. It is not bad. But you really need to know, why do
you need it.

I am fully support the feature-branch + merge request way of working.
It can really help to double check the code and implement some
additional tests.

[1] https://github.com/yade/trunk/tree/0.60

My 2cts

Regards

Anton

Am Mo., 7. Jan. 2019 um 17:39 Uhr schrieb 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 "yadedaily" packages ?..)
> >
> > Yade is stable release, not updated very often, included in main
> > debian/ubuntu repos.
> > Yadedaily is updated  more than daily, after each change to the source
> > code, not included in debian/ubuntu repos.
> > They are very different things and I think we need both.
>
> agreed.
>
> > > Also, with "develop" and "master", I guess any proposal for code
> > > modification would have to be closely examined and validated twice :
> > > - once to make it into "develop"
> > > - and once, to make it from "develop" into "master"
> > > ?...
> > There is no reason to check the develop->master merge if everything in
> > develop is already validated by regtests + human review.
> > Our github/master corresponds to "develop" more or less.
> > Merging develop into master in the new model would correspond to Anton
> > calling for update and releasing 2018.b. More or less.
>
> agred.
>
> > We probably need a liberal, truly unstable repo on the top of this, at
> > least in a transitory phase, so that everyone can play with gitlab a bit
> > and break everything with no limit. For instance to compare --no-ff,
> > --only-ff, and other variants.
>
> how about calling it experimental ? :-))
>
> And yes, we definitely need something like that.
> Where git reset --hard is nothing to be afraid of.
>
> --
> Janek Kozicki
>
> ___
> 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

Re: [Yade-dev] Migrating to GitLab

[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 "yadedaily" packages ?..)  
> 
> Yade is stable release, not updated very often, included in main 
> debian/ubuntu repos.
> Yadedaily is updated  more than daily, after each change to the source 
> code, not included in debian/ubuntu repos.
> They are very different things and I think we need both.

agreed.
 
> > Also, with "develop" and "master", I guess any proposal for code 
> > modification would have to be closely examined and validated twice :
> > - once to make it into "develop"
> > - and once, to make it from "develop" into "master"
> > ?...  
> There is no reason to check the develop->master merge if everything in 
> develop is already validated by regtests + human review.
> Our github/master corresponds to "develop" more or less.
> Merging develop into master in the new model would correspond to Anton 
> calling for update and releasing 2018.b. More or less.

agred.

> We probably need a liberal, truly unstable repo on the top of this, at 
> least in a transitory phase, so that everyone can play with gitlab a bit 
> and break everything with no limit. For instance to compare --no-ff, 
> --only-ff, and other variants.

how about calling it experimental ? :-))

And yes, we definitely need something like that.
Where git reset --hard is nothing to be afraid of.

-- 
Janek Kozicki

___
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

Re: [Yade-dev] Migrating to GitLab

[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 miniature to each repo. While repos act as "larger
branches", and the same strategy works between them, just on a larger
scale :)

> 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.
> >  
> Why? Do you refer to github or gitlab repo here? (remember that gitlab repo
> is not known by any other dev yet)

I refer to github. I felt uneasy because I would prefer to push new
stuff to develop. Not master. Master, at least for me, feels like
"it's certified to work" :)
If you run into problems on develop branch, you always know, that you
can compare with master and get reproducible results. Maybe `master`
could be called `stable` to reflect how I feel this.

> > I suppose that using
> > https://nvie.com/posts/a-successful-git-branching-model/
> > would help a lot. (short summary on
> > https://nvie.com/files/Git-branching-model.pdf )
> 
> It sounds good.
> 
> > I propose that:
> > 1. we will use feature branches with a specific name to hot-develop
> > features. (e.g. fluid)
> > 2. when feature is "almost ready" we merge it into develop branch
> > 3. when develop branch is stable we merge it into master using a release
> > branch
> 
> I agree. Only the last part "using a release branch" is not completely
> clear to me.

The "release branch" is actually useful, at least for me. I have a
short cheat-sheet for that, here it goes:
(it is from https://nvie.com/posts/a-successful-git-branching-model/ )

===
RELEASE BRANCH:
Release branches are created from the develop branch:

$ git checkout -b release-1.2 develop
$ ./bump-version.sh 1.2   # or whatever edits are necessary to change version 
number
$ git commit -a -m "Bumped version number to 1.2"

Finishing a release branch: merge to master

$ git checkout master
$ git merge --no-ff release-1.2
$ git tag -a 1.2

Merge to develop

$ git checkout develop
$ git merge --no-ff release-1.2

Delete unused branch:
$ git branch -d release-1.2
===

It is a little fiddling between the two branches. The point is, that
whatever conflicts arise during the merge, they do not mess up with
develop branch, and not mess up with master branch. They get solved
inside release branch. Which is deleted after merge is a success.

Most of the time, it's just 'nothing', when stuff goes smoothly. But
in some cases when you get conflicts, you suddenly are glad that you
are not on develop or master branch :) For example if you have problems
with this line:
$ git merge --no-ff release-1.2
Then you abort the merge (git reset --merge ORIG_HEAD
https://medium.com/@porteneuve/mastering-git-reset-commit-alchemy-ba3a83bdfddc 
funny read btw ;)).
Everything is reset on master, and you go back to release-1.2 to fix there.


Actually I have more of this cheat-sheet, for hotfixes it goes like that:
===
HOTFIX BRANCH:
Creating the hotfix branch:

$ git checkout -b hotfix-1.2.1 master
$ ./bump-version.sh 1.2.1
$ git commit -a -m "Bumped version number to 1.2.1"

Fix stuff, then:
$ git commit -m "Fixed severe production problem"

Finishing a hotfix branch, update master and tag the release:
$ git checkout master
$ git merge --no-ff hotfix-1.2.1
$ git tag -a 1.2.1

Merge into develop:
$ git checkout develop
$ git merge --no-ff hotfix-1.2.1

Example if git history messes up:
$ git reset --merge ORIG_HEAD
Then for example only pick specific commits:
$ git cherry-pick 81f7007
$ git cherry-pick 5bf2e3a

Delete unused branch:
$ git branch -d hotfix-1.2.1
===


> > The main branches
> > * master
> > * develop
> 
> Definitely.
> 
> Other branches:
> > * Feature branches
> >+ branch from develop (with command: git checkout -b myfeature develop)
> >+ merge to develop (with command: git checkout develop ; git merge
> > --no-ff myfeature )
> >+ naming: anything except `master`, `develop`, `release-*`, or
> > `hotfix-*`
> >  
> 
> Yes.
> Until now feature branches (e.g. yade-mpi [1]) are not centralized. They
> remain under personal github accounts.
> Whether those branches are/not pushed into the upstream repo as stateful
> branches makes no real difference in practice (in my view at least).
> github.com/bchareyre/yade-mpi/master is exactly one of the feature branches
> as they appear in your model. It will be merged into
> github.com/yade/trunk/master  when ready (or
> into a "develop" branch).
> Equivalently I could have pushed a new "mpi" branch to yade/trunk, then
> start working on it, and later merge to yade/master.
> It makes nearly no difference in the final result but the later has
> downsides:
> - more noise on yade-dev (notifications for each push)
> - less flexibility  

Re: [Yade-dev] Migrating to GitLab

[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 control on development, would we still 
need a distinction between "yade" and "yadedaily" packages ?..)


Yade is stable release, not updated very often, included in main 
debian/ubuntu repos.
Yadedaily is updated  more than daily, after each change to the source 
code, not included in debian/ubuntu repos.

They are very different things and I think we need both.

Also, with "develop" and "master", I guess any proposal for code 
modification would have to be closely examined and validated twice :

- once to make it into "develop"
- and once, to make it from "develop" into "master"
?...
There is no reason to check the develop->master merge if everything in 
develop is already validated by regtests + human review.

Our github/master corresponds to "develop" more or less.
Merging develop into master in the new model would correspond to Anton 
calling for update and releasing 2018.b. More or less.


We probably need a liberal, truly unstable repo on the top of this, at 
least in a transitory phase, so that everyone can play with gitlab a bit 
and break everything with no limit. For instance to compare --no-ff, 
--only-ff, and other variants.


Bruno



___
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

Re: [Yade-dev] Migrating to GitLab

[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.
>

Why? Do you refer to github or gitlab repo here? (remember that gitlab repo
is not known by any other dev yet)


> I suppose that using
> https://nvie.com/posts/a-successful-git-branching-model/
> would help a lot. (short summary on
> https://nvie.com/files/Git-branching-model.pdf )
>

It sounds good.


> I propose that:
> 1. we will use feature branches with a specific name to hot-develop
> features. (e.g. fluid)
> 2. when feature is "almost ready" we merge it into develop branch
> 3. when develop branch is stable we merge it into master using a release
> branch
>

I agree. Only the last part "using a release branch" is not completely
clear to me.


> The same thing but written in a different way:
>
> The main branches
> * master
> * develop
>

Definitely.

Other branches:
> * Feature branches
>+ branch from develop (with command: git checkout -b myfeature develop)
>+ merge to develop (with command: git checkout develop ; git merge
> --no-ff myfeature )
>+ naming: anything except `master`, `develop`, `release-*`, or
> `hotfix-*`
>

Yes.
Until now feature branches (e.g. yade-mpi [1]) are not centralized. They
remain under personal github accounts.
Whether those branches are/not pushed into the upstream repo as stateful
branches makes no real difference in practice (in my view at least).
github.com/bchareyre/yade-mpi/master is exactly one of the feature branches
as they appear in your model. It will be merged into
github.com/yade/trunk/master  when ready (or
into a "develop" branch).
Equivalently I could have pushed a new "mpi" branch to yade/trunk, then
start working on it, and later merge to yade/master.
It makes nearly no difference in the final result but the later has
downsides:
- more noise on yade-dev (notifications for each push)
- less flexibility  (some developers of yade-mpi have no access to
yade/trunk and will probably never have, not possible with a centralized
repo).
- more time spent in management of rights, branch creation, etc.
For theses reasons I would keep the decentralized approach of the current
feature branches.

Not sure "--no-ff" is the best thing. I am more inclined to the opposite at
the moment (rebase the feature branch + --only-ff), to make history more
readable in master. That's what we did on github until now. We can still
discuss it and try variants.
[1] https://github.com/bchareyre/yade-mpi


> * Release branches
>+ branch from develop
>+ merge to develop AND master
>+ naming: `release-*`
>

That's still a bit unclear to me unfortunatey. What is the purpose of those?


> * Hotfix branches
>+ branch from master
>+ merge to develop AND master
>+ naming: `hotfix-*`
>

Agreed.



> I will try to go back to your original point:
> > I think we need to distinguish two aspects:
> > 1- do we "push" or do we "request-merge"?
>
> I have no idea. It appears that current model is incompatible with
> the one which I propose.


If "current" means everyone pushing to master, then yes, it is
incompatible. I'm also for moving toward a model closer to what you propose.

  git checkout develop
>   git merge --no-ff myfeature
>

This is only changing the local repo, that's your business as a local
branch manager. It doesn't say anything about push vs. MR.
The question is what happens after that, and there are two options:
1- push the merge to yade/trunk, so in the end you are still "pushing"
2- push to whateverBranch (remote), then MR from whateverBranch to
yade/trunk/someBranch

I propose to make direct push impossible to both master and dev branches
(if not the entire repo) so that 2- will be the only option. It fits very
well in the feature-branch model.

If he has no access rights to do this, then he does request-merge instead.
>

It is not a question of rights, it is a question of method, and that was my
original point 1.
MR is part of standard work cycle in gitlab CI, even if you have rights to
accept your own MR it is still different from a CLI push, because it goes
through gitlab toolchain.


> And then the question reduces to: "do we request-merge to develop or do we
> merge to it?". I think this is the same as the second question:
>
> > 2- who is allowed to accept the merge requests?
>

Nope. :)
The question is still: do we push or do we MR to yade/trunk/branch
(whatever the branch)?
"who is allowed" is orthogonal.

It seems that it's those who have the access rights :)
> Are you asking who those people should be? Well obviously us ;)
>

There are many options. For instance it is possible to configure gitlab so
that N devs need to agree for a MR to be accepted (you screw that with CLI
merge/push).
N can include the author of 

Re: [Yade-dev] Migrating to GitLab

[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 to push directly to the trunk, 
> > obviously with care ;-)  
> I think we need to distinguish two aspects:
> 1- do we "push" or do we "request-merge"?
> 2- who is allowed to accept the merge requests?
> 
> I don't see a real need to use direct push (point 1), one exception is 
> when fixing simple bugs maybe.
> What you say is more  (I guess) that some devs need enough rights to 
> accept their own MR (point 2). Right?

I just noticed that with my CGAL 4.13 attempt to fix I did a push to master. 
Which felt uneasy.

I suppose that using https://nvie.com/posts/a-successful-git-branching-model/
would help a lot. (short summary on 
https://nvie.com/files/Git-branching-model.pdf )

I propose that:
1. we will use feature branches with a specific name to hot-develop features. 
(e.g. fluid)
2. when feature is "almost ready" we merge it into develop branch
3. when develop branch is stable we merge it into master using a release branch

The same thing but written in a different way:

The main branches
* master
* develop

Other branches:
* Feature branches  
   + branch from develop (with command: git checkout -b myfeature develop)
   + merge to develop (with command: git checkout develop ; git merge --no-ff 
myfeature )
   + naming: anything except `master`, `develop`, `release-*`, or `hotfix-*`
* Release branches
   + branch from develop
   + merge to develop AND master
   + naming: `release-*`
* Hotfix branches
   + branch from master
   + merge to develop AND master
   + naming: `hotfix-*`


I will try to go back to your original point:
> I think we need to distinguish two aspects:
> 1- do we "push" or do we "request-merge"?

I have no idea. It appears that current model is incompatible with
the one which I propose. It feels to me like answering to a question:
"do we push myfeature into master or do we request-merge myfeature
into develop branch?".

If your question was phrased this way then my answer is: merge myfeature into 
develop.

This would mean that Feature branch is ready to merge into
develop branch. The main author of that feature branch would simply
decide that it's time to run command:

  git checkout develop
  git merge --no-ff myfeature

If he has no access rights to do this, then he does request-merge instead.

Please note that anyone could checkout that feature branch from gitlab, follow 
the
progress in this branch and contribute to it.

And then the question reduces to: "do we request-merge to develop or do we
merge to it?". I think this is the same as the second question:

> 2- who is allowed to accept the merge requests?

It seems that it's those who have the access rights :)
Are you asking who those people should be? Well obviously us ;)

> I don't see a real need to use direct push (point 1), one exception is 
> when fixing simple bugs maybe.

In my proposition that would mean using a hotfix-* branch.


If you agree on that then the first thing to do is to 
$ git co master
$ git branch develop
$ git co develop
and put this branch on github/gitlab.

And from now on master would accept only merges from
release-* branches and hotfix-* branches. And not direct commits.

I am worried though that others might be afraid of this switch?
I think though that this would clean things up, and allow for more
active development without worrying about breaking something in the
master branch.



Regarding Robert's note about gitlab's issue tracking: I suppose that
this could replace launchpad's bug tracking interface, but since we
cannot move Q to gitlab then perhaps this would produce even more
fragmentation.


-- 
Janek Kozicki

___
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

Re: [Yade-dev] Migrating to GitLab

[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.

However there may by still some ways to unify or simplify current process with 
gitlab. So let's use what they have in their offer.

Janek
On 20 Dec 2018, 10:39 +0100, Duriez Jerome , wrote:
> Hi,
>
> I'm also proposing we keep our Launchpad interface. This lack of a convenient 
> Questions interface on Gitlab seems a problem to me.
>
> Frontpage such as https://launchpad.net/yade look also to me less "geek" than 
> e.g. https://gitlab.com/axiom-micro/hardware (which should just compare to 
> https://github.com/yade)
>
> As for the bugs, I like the possibility we currently have to link Launchpad 
> bugs with Launchpad questions (which leans me towards keeping Launchpad bug 
> management), even though this is a less major thing to me.
>
>
> Jérôme
>
> De: "bruno chareyre" 
> À: "Yade developers" 
> Cc: "remi cailletaud" 
> Envoyé: Vendredi 14 Décembre 2018 15:59:14
> Objet: [Yade-dev] (no subject)
>
> Thanks for investigations Robert. That's convincing.
> Mixing bugs and questions does not seem to be a good idea.
> A mixed option could be to move bugs to gitlab and keep Q on LP, hence 
> separating them even more.
> Not sure there is any real advantage in doing that, though.
>
> Bruno
>
>
>
> On 12/14/18 11:15 AM, Robert Caulk wrote:
> >  >> 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 tracking was not 
> > meant to be a Q forum, however, some projects use issue tracking (aka bug 
> > tracking on LP) as a place for community support [1], despite the awkward 
> > interface. GitLab does provide a nice labeling system, so questions or 
> > "support requests" can be filtered as such. But it is likely that Yade 
> > users will become confused since it is not a traditional forum format, they 
> > will simply search through all bugs and questions at once, they will post 
> > without considering the labels, or worse, they will use the wrong labels. 
> > I'm scared of a disorganized mess. What do you guys think? Was it useful to 
> > keep bugs and community questions separate?
> >
> > If we decide it is preferable to combine bugs (issues) with community 
> > questions, then I vote for an effort to migrate the launchpad Q archives 
> > over to GitLab issues. I looked around and found some apathetic conclusions 
> > regarding Launchpad->GitLab bug migrations [2]. Ultimately, some tools 
> > exist but they will likely need to be retooled. This could be a significant 
> > project, tough to tell...
> >
> > Given all this information, I lean toward leaving the Q on launchpad. 
> > What is your opinion?
> >
> > [1]https://gitlab.com/gitlab-org/gitlab-ce/issues/20851
> > [2]https://gitlab.com/gitlab-org/gitlab-ce/issues/47399
> >
> > rc
> >
> > > Le mer. 12 déc. 2018 à 07:52, Klaus Thoeni  a 
> > > écrit :
> > > > 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 
> > > > >  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 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 two aspects:
> > > > > > 1- do we "push" or do we "request-merge"?
> > > > > > 2- who is allowed to accept the merge requests?
> > > > > >
> > > > > > I don't see a real need to use direct push (point 1), one exception 
> > > > > > is
> > > > > > when fixing simple bugs maybe.
> > > > > > What you say is more  (I guess) that some devs need enough rights to
> > > > > > accept their own MR (point 2). Right?
> > > > > >
> > > > > > Bruno
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > ___
> > > > 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
>
> --
> ___
> 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: 

Re: [Yade-dev] Migrating to GitLab

[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 tracking was not
meant to be a Q forum, however, some projects use issue tracking (aka bug
tracking on LP) as a place for community support [1], despite the awkward
interface. GitLab does provide a nice labeling system, so questions or
"support requests" can be filtered as such. But it is likely that Yade
users will become confused since it is not a traditional forum format, they
will simply search through all bugs and questions at once, they will post
without considering the labels, or worse, they will use the wrong labels.
I'm scared of a disorganized mess. What do you guys think? Was it useful to
keep bugs and community questions separate?

If we decide it is preferable to combine bugs (issues) with community
questions, then I vote for an effort to migrate the launchpad Q archives
over to GitLab issues. I looked around and found some apathetic conclusions
regarding Launchpad->GitLab bug migrations [2]. Ultimately, some tools
exist but they will likely need to be retooled. This could be a significant
project, tough to tell...

Given all this information, I lean toward leaving the Q on launchpad.
What is your opinion?

[1]https://gitlab.com/gitlab-org/gitlab-ce/issues/20851
[2]https://gitlab.com/gitlab-org/gitlab-ce/issues/47399

rc

Le mer. 12 déc. 2018 à 07:52, Klaus Thoeni  a
écrit :

> 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 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 two aspects:
>> 1- do we "push" or do we "request-merge"?
>> 2- who is allowed to accept the merge requests?
>>
>> I don't see a real need to use direct push (point 1), one exception is
>> when fixing simple bugs maybe.
>> What you say is more  (I guess) that some devs need enough rights to
>> accept their own MR (point 2). Right?
>>
>> Bruno
>>
>>
>>
>>
>> ___
> 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

Re: [Yade-dev] Migrating to GitLab

[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 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 two aspects:
> 1- do we "push" or do we "request-merge"?
> 2- who is allowed to accept the merge requests?
>
> I don't see a real need to use direct push (point 1), one exception is
> when fixing simple bugs maybe.
> What you say is more  (I guess) that some devs need enough rights to
> accept their own MR (point 2). Right?
>
> Bruno
>
>
>
>
>
___
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

Re: [Yade-dev] Migrating to GitLab

[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 passed, documentation is not broken and many
additional checks, which can improve the code quality.

My 2 cts

Anton

Am Di., 11. Dez. 2018 um 17:04 Uhr schrieb 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 two aspects:
> 1- do we "push" or do we "request-merge"?
> 2- who is allowed to accept the merge requests?
>
> I don't see a real need to use direct push (point 1), one exception is
> when fixing simple bugs maybe.
> What you say is more  (I guess) that some devs need enough rights to
> accept their own MR (point 2). Right?
>
> Bruno
>
>
>
>
>
> ___
> 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

Re: [Yade-dev] Migrating to GitLab

[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 two aspects:
1- do we "push" or do we "request-merge"?
2- who is allowed to accept the merge requests?

I don't see a real need to use direct push (point 1), one exception is 
when fixing simple bugs maybe.
What you say is more  (I guess) that some devs need enough rights to 
accept their own MR (point 2). Right?


Bruno





___
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

Re: [Yade-dev] Migrating to GitLab

[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 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

Re: [Yade-dev] Migrating to GitLab

[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
stuff. If the main developers think it is better for the future of YADE, I
can only agree with the migration. Actually, Robert's last point regarding
MS would make me even more positive about it :)

Cheers

Luc

Le mar. 4 déc. 2018 à 10:26, Robert Caulk  a écrit :

> 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?
> 
>
> Cheers,
>
> Robert
>
> On Tue, Dec 4, 2018 at 10:02 AM Luc Sibille 
> 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
>> 

Re: [Yade-dev] Migrating to GitLab

[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 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?


Cheers,

Robert

On Tue, Dec 4, 2018 at 10:02 AM Luc Sibille 
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 

Re: [Yade-dev] Migrating to GitLab

[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 
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 

Re: [Yade-dev] Migrating to GitLab

[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.


/> 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@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help   : https://help.launchpad.net/ListHelp

Re: [Yade-dev] Migrating to GitLab

[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., 27. Nov. 2018 um 19:54 Uhr schrieb Bruno Chareyre <
bruno.chare...@3sr-grenoble.fr>:

> 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

Re: [Yade-dev] Migrating to GitLab

[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 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 , 
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

Re: [Yade-dev] Migrating to GitLab

[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 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@lists.launchpad.net/msg13652.html
[***] 
https://www.mail-archive.com/yade-dev@lists.launchpad.net/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