yade-dev team mailing list archive

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