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 <[email protected]> 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 < > > [email protected]>: > > > > > > 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 : [email protected] > > > > 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 : [email protected] > > > Unsubscribe : https://launchpad.net/~yade-dev > > > More help : https://help.launchpad.net/ListHelp > > > > _______________________________________________ > > Mailing list: https://launchpad.net/~yade-dev > > Post to : [email protected] > > 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 : [email protected] Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
