Hi all, On Tue, 25 Oct 2022 at 08:32, Daniel Vetter <dan...@ffwll.ch> wrote: > On Fri, 9 Sept 2022 at 19:18, Daniel Stone <dan...@fooishbar.org> 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 <dani...@collabora.com> Cheers, Daniel
