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-label
As 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
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
_______________________________________________
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
