yade-dev team mailing list archive

[Anton Gladky <gladky.anton@xxxxxxxxx>]

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

>  Did you ever hack the API to trigger them from CLI (that would mae Janek happy ;) )?

A year ago I had successfully migrated almost 1000 git-repos from one
service to Gtilab
(new salsa.debian.org) using GitLab-API and was very satisfied. I have
never used
it before, and it took just some hours to do it. API is good documented!

The only develop-master privilege, which I can imaging, is the
automatic build of
stable-yade packages. Master-branch should be synced into the Launchpad and
the stable packages will be built after each sync. But Yade releases
are not so often,
not sure it will make any sense.

[1] https://lists.debian.org/debian-science/2017/12/msg00029.html

Best regards

Anton

Am Di., 8. Jan. 2019 um 17:52 Uhr schrieb Bruno Chareyre
<bruno.chareyre@xxxxxxxxxxxxxxx>:
>
>
>
> On Tue, 8 Jan 2019 at 09:56, Jerome Duriez <jerome.duriez@xxxxxxxxx> wrote:
>>
>> let's maybe try to avoid switching from only one branch to more than
>> three ?...
>
>
> We have already 19 branches on github/yade/trunk, plus other branches under personal accounts.
> Limiting the number of branches is not a realistic objective, don't worry about that. It will become more clear with concrete usage, and you will not have to handle them all anyway.
> This being said, I'm also not sure we really need that develop-master duality.
>
> I would propose develop+experimental for a start, with release branches as in Anton's picture.
> 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.
>
> Anton, do you have comments on MR on Gitlab interface? Do you confirm that they are a must? Did you ever hack the API to trigger them from CLI (that would mae Janek happy ;) )?
> Thx
> Bruno
>
>>
>> On 07/01/2019 20:36, Anton Gladky wrote:
>> > --------------------------------------> develop
>> >    \                    \
>> >     \                     \
>> >      \Release 1     \Release 2
>> >       \Release 1.1
>> >
>> > I can remember only a couple of times, where the hot-fixes were
>> > needed to be integrated into the release-branch due to some serious
>> > stability or functionality issues.
>> >
>> > Last years I have an experience of work with master-develop
>> > approach. It is not bad. But you really need to know, why do
>> > you need it.
>> >
>> > 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.
>> >
>> > [1] https://github.com/yade/trunk/tree/0.60
>> >
>> > My 2cts....
>> >
>> > Regards
>> >
>> > Anton
>> >
>> > Am Mo., 7. Jan. 2019 um 17:39 Uhr schrieb Janek Kozicki <janek_listy@xxxxx>:
>> >> Bruno Chareyre said:     (by the date of Mon, 7 Jan 2019 16:59:53 +0100)
>> >>
>> >>> Daily builds would be based on the develop branch.
>> >> good, that answer my question from other mail.
>> >>
>> >>>> (by the way, with a tighter control on development, would we still
>> >>>> need a distinction between "yade" and "yadedaily" packages ?..)
>> >>> Yade is stable release, not updated very often, included in main
>> >>> debian/ubuntu repos.
>> >>> Yadedaily is updated  more than daily, after each change to the source
>> >>> code, not included in debian/ubuntu repos.
>> >>> They are very different things and I think we need both.
>> >> agreed.
>> >>
>> >>>> Also, with "develop" and "master", I guess any proposal for code
>> >>>> modification would have to be closely examined and validated twice :
>> >>>> - once to make it into "develop"
>> >>>> - and once, to make it from "develop" into "master"
>> >>>> ?...
>> >>> There is no reason to check the develop->master merge if everything in
>> >>> develop is already validated by regtests + human review.
>> >>> Our github/master corresponds to "develop" more or less.
>> >>> Merging develop into master in the new model would correspond to Anton
>> >>> calling for update and releasing 2018.b. More or less.
>> >> agred.
>> >>
>> >>> We probably need a liberal, truly unstable repo on the top of this, at
>> >>> least in a transitory phase, so that everyone can play with gitlab a bit
>> >>> and break everything with no limit. For instance to compare --no-ff,
>> >>> --only-ff, and other variants.
>> >> how about calling it experimental ? :-))
>> >>
>> >> And yes, we definitely need something like that.
>> >> Where git reset --hard is nothing to be afraid of.
>> >>
>> >> --
>> >> 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
>> > _______________________________________________
>> > 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
>
> _______________________________________________
> 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