yade-dev team mailing list archive

[Janek Kozicki <janek_listy@xxxxx>]

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


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