| Thread Previous • Date Previous • Date Next • Thread Next |
Hi there, The repository is functional at: https://gitlab.com/yade-dev/trunk For using gitlab you can read the updated doc page https://yade-dev.gitlab.io/trunk/github.html#yade-github-labelAs soon as you have a gitlab account let me know your login name so I can add you to the project.
I just discovered a technical constraints which makes MR from personal repo awkward at the moment (although it could work with future gitlab versions maybe [1]). The issue is that if a MR is generated from a forked repo to the parent yade-dev/trunk repo, then running the pipeline [3] requires that runners[2] be available in the forked repo. It is not possible to build the MR on the parent repo. So unless you have the computational ressources and enough skills/IT support to configure runners locally, MR from personal repo will not be tested automatically. They can be handled (some MR could still make it that way) but it is not very convenient and it will take more time to be accepted.
It is pushing us toward a solution closer to what Janek suggested, which was based on multiple branches more than multiple repos. I.e. push (normal push) to different branches of yade-dev/trunk, then MR from that branch to master. Since both branches are under yade-dev the group runners will be used in this case.
Please check the doc and let me know if some information is missing. I suggest to not conclude migration before Anton's freeze.You can still work with github repo if you have local changes and you are affraid to mess up, I will merge gitub repo into gitlab if needed.
Else please consider pushing to gitlab any future revision.There is an experimental repo at https://gitlab.com/yade-dev/trunk-exp. Feel free to break it.
Cheers Bruno [1] https://gitlab.com/gitlab-org/gitlab-ce/issues/23902 [2] hardware on which compilation and regression tests occur[3] https://gitlab.com/yade-dev/trunk/pipelines (you can click on every step to visualize process like https://gitlab.com/yade-dev/trunk/-/jobs/147313249)
On 1/13/19 10:03 AM, Anton Gladky wrote:
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.chareyre@xxxxxxxxxxxxxxx>: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 BrunoRegards 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_______________________________________________ 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
| Thread Previous • Date Previous • Date Next • Thread Next |
