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.chare...@3sr-grenoble.fr>: > > > > On Thu, 10 Jan 2019 at 21:40, Anton Gladky <gladky.an...@gmail.com> 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? >> > > >> > > >> > > -- >> > > 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 > > _______________________________________________ > 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