On Wed, Jun 16, 2021 at 4:33 PM James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > On Wed, 2021-06-16 at 15:11 -0600, Rob Herring wrote: > > > - subsystem maintainers can configure whatever CI pre-checks they > > > want before the series is sent to them for review (and we can work > > > on a library of Github actions, so nobody needs to reimplement > > > checkpatch.pl multiple times) > > > > What about all the patches that don't come from the GH PR? Those need > > CI pre-checks too. We're going to implement CI twice? The biggest > > issue I have on CI checks is applying patches. My algorithm is apply > > to my current base (last rc1 typically) or give up. I'm sure it could > > be a lot smarter trying several branches or looking at base-commit > > (not consistently used) or the git diff treeish hashes. What I'd > > really like is some bot or script that's applying series and > > publishing git branches with a messageid to git branch tool. 0-day is > > doing this now. Basically, the opposite direction as others have > > mentioned. > > I've got to say my experience with Github CIs has been pretty > unpleasant. Pretty much every project I've ever pushed to has had at > least one commit reject because of a bug in the CI rather than the > commit which they usually dump on the submitter to fix. As an endless > devops make work project, I'm sure they're fine, but what we have now > with 0-day is pretty much good enough for most kernel work, plus if it > goes wrong we can ignore it and somebody else fixes it ... It's the making a git branch somewhere that I'm interested in, not the Github part of it. If someone wants to tie GH CI to that and send out replies to patches, then fine. We can use them if useful or ignore if not. 0-day is a bit unpredictable in terms of response time. I often only get reports after things land in linux-next which is a bit late IMO. What is run and the priorities are all opaque. Rob
