Hi all, On Tue, 25 Oct 2022 at 08:32, Daniel Vetter <daniel@xxxxxxxx> wrote: > On Fri, 9 Sept 2022 at 19:18, Daniel Stone <daniel@xxxxxxxxxxxxx> wrote: > > But equally - and sorry for not jumping on the IRC (?) discussion as I was in the middle of other stuff when it came up - I'm don't think this is the right plan. > > > > Mesa having all its CI in-tree makes sense, because merges happen rapidly to a single canonical tree. If the scripts need to be changed for whatever reason, we can merge something in under an hour and everyone immediately gets it. DRM is quite different though, given the forest of trees we have and the long merge paths between them. I worry that merging the CI scripts in-tree - especially for our initial attempt at it, when we're likely to need to make quite a lot of changes before it settles down to become a stable system that works for everyone - is shooting ourselves in the foot by limiting our flexibility. > > So the entire "we have multiple trees" is why I want at least the > gitlab-ci.yaml in tree, to force people to collaborate more on one > thing instead of everyone rolling their own fun and hacking stuff up. > And there's still tons of stuff outside in the separate repo, like the > lab status so Linus doesn't get a silly history of lab flapping. > > Also wrt "developers don't get the update right away due to > backmerge/pull delays", that's why integration trees like drm-tip or > linux-next exist. So maybe initially we should make sure the ci > patches go in through drm-misc, to maximize how many people see it. > And even for mesa it's not fully automatic, you still have the rebase > your branch if you picked a bad one for development (but yeah marge > does that if the MR is ready). If you're doing kernel development on a > linear tree instead of an integration tree, you're doing it very > wrong. > > What I think everyone agrees on is that we probably get the split > wrong and need to shuffle some files back&forth, and that's something > we need to warn Linus about I guess. But somewhere we do need a split > between internal and external stuff, and personally I'd like if at > least the pure sw testing (build and virtual stuff) could be all in > upstream. > > > Given that it's currently very dependent on fd.o infrastructure (published ci-templates, the registry, the specific-tag runners for Collabora/CrOS DUTs, etc), there isn't much of a portability gain in bringing the scripts into the tree either. It's a good goal, but not where we are today. > > I don't think there's huge chances for any non-fdo gitlab anytime > soon. Once we get there we might need to figure out how to standardize > the hw lab interfacing, and if we have all the sw targets in upstream > that should help with shuffling stuff around for a hypothetical LF > gitlab CI (or whatever it is). Yep, having talked through things on IRC, I'm happy with where we are; let's give it a go and find out. Acked-by: Daniel Stone <daniels@xxxxxxxxxxxxx> Cheers, Daniel
