ribalda: was the point I was trying to make, in FDO, we encourage forks, but for forks to work, you have to give them usable shared runners, I want to see what's your plan in this regard
all other projects uses shared runners, and we use tags, so that specialized runners are used for the right purpose
is there anything in media-ci that requires specialized runners ?
I didn't the "that far" but it must be using a tag, otherwise my fork CI would have just worked
ndufresne: We are not using any tag, It should run with any runner. I guess you do not have set any runner in your repo?
this is the yaml for the ci: https://gitlab.freedesktop.org/linux-media/media-ci/-/blob/main/.gitlab-ci.yml?ref_type=heads and this is the one for media-staging:  https://gitlab.freedesktop.org/linux-media/media-ci/-/blob/main/gitlab/gitlab-ci.yml?ref_type=heads
hverkuil: Can we cherry-pick a patch from linux-next into media-staging?
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/scripts/kernel-doc?id=bbf00be93e09081ffa06e6fd84ed8f4e469a99d0 ?
ribalda: Linus doesn't like such things. I considered filtering this out in my build scripts until this lands in our staging tree with the next rc1. I didn't think it was worth the effort, though.
I will just mark the build as allow_failure
so it will be yellow, and when it lands in rc1 I will remove it
ribalda: I'll have to check with FD admins, but it seems like the fork endup with "Enable instance runners for this project" disabled
might actually be intentional, but if so, we should document it I suppose
pinchartl: do you also use forks for libcamera, or only used the libcamera namespace so far ?
ndufresne: I created a fork for development, but now we use the gitlab.fd.o/camera/libcamera tree
forks work though, as long as your user have permissions to use the shared runners
I think that permission goes with having permission to work
In the case of media-ci, the fork ended up with "Enable instance runners for this project" knob being disabled
perhaps its disabled in the linux-media namespace, and then its just copied, ribalda I don't have permission to see what this setting is on your namespace, do you only use group runners ?
yes, group members only
I mean runners, do you use the shared runners (global to fdo) or limit you namespace to some runners you have setup yourself ?
sorry, that is what I mean. group runners only https://usercontent.irccloud-cdn.com/file/XrF0iFF4/image.png
ndufresne: ribalda: this may be a topic for #freedesktop
ribalda: ok, so just like many things in gitlab, the fork will inherit that setting, so if someone forks into its personal namespace (like I just did) they need to enable it by hand, perhaps we won't stick with group runners in the long run, so might not matter so much
pinchartl: I usually try to resolve as much as I can before pinging the admins on fdo, they are pretty busy
sure :-)
ribalda: so works now, what do you think of having a "known working" kernel to be tested in the media-ci pipeline ? to try and catch any script regressions before we merge them ?
ndufresne: not only that, we need make sure the containers are built properly.... I was waiting for the code to be more stable to add that. I did not want to wait 1 hour for every change to land. 
I think we will be close to that point soon
re: https://gitlab.freedesktop.org/linux-media/media-ci/-/blob/main/.gitlab-ci.yml?ref_type=heads#L30
ah so you already have an issues filed then, ok
ribalda: for the docker, any reason do it it this way ? FDO provides nice integration scripts that works across namspaced, fdo-template, Helene's is using these
with these scripts, the docker will be automatically created if it does not exist yet, with skopeo, it will try and get one from the original namespace and copy it into user namespace too
when you make a change that require docker update, you simply update the docker tag and the script will know what to do
old habits die hard? we have an issue to look into fdo scripts: https://gitlab.freedesktop.org/linux-media/media-ci/-/issues/7
great
this will certainly reduce your pipeline duration when you want to test a change that is not modifying the docker
99% of the times we need to rebuild the containers when there is a change in media-ci
in media-staging we do not build any contiainer
I'm not sure that model will scale long term, but best is for you to hit the issues  first
the in-kernel effort by Helene is closely related to the issue that raises with split repo
it was also our original setup in gst, we went pretty deep in doing changes there, as we use to have 10+ repos, and now have 1 (plus Rust)
ribalda: a feature you might not know about, you can trigger pipeline in other repo, and gitlab will merge both pipelines, one example, see the downstream state, https://gitlab.freedesktop.org/seungha.yang/gstreamer/-/pipelines/1116049
unfortunatly, with the open source gitlab, you have to track completion yourself
ribalda: is it you managing the linuxtv-ci ml ? its not very nicely configured, just used by corporate email accidently and it just trash messages, no moderation, I'll add my second email, but I think other ML have moderation instead
no, Mauro owns the list.
ack