yade-dev team mailing list archive

[Anton Gladky <gladky.anton@xxxxxxxxx>]

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
<bruno.chareyre@xxxxxxxxxxxxxxx>:
>
>
>
> On Thu, 10 Jan 2019 at 21:40, Anton Gladky <gladky.anton@xxxxxxxxx> 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_listy@xxxxx>:
>> >
>> > 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@xxxxxxxxxxxxxxxxxxx
>> > > 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@xxxxxxxxxxxxxxxxxxx
>> > Unsubscribe : https://launchpad.net/~yade-dev
>> > More help   : https://help.launchpad.net/ListHelp
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~yade-dev
>> Post to     : yade-dev@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~yade-dev
>> More help   : https://help.launchpad.net/ListHelp
>
> _______________________________________________
> Mailing list: https://launchpad.net/~yade-dev
> Post to     : yade-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~yade-dev
> More help   : https://help.launchpad.net/ListHelp