yade-dev team mailing list archive

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