On Tue, Nov 21, 2017 at 08:58:51AM +0100, Greg KH wrote: > On Mon, Nov 20, 2017 at 01:39:31PM +0100, Daniel Vetter wrote: > > Of course our CI is open, so if someone is supremely bored and wants to > > backport more stuff for drm/i915, they could do that. But atm it doesn't > > happen, and then having to deal with the fallout is not really great (like > > I said, we don't really have anyone dedicated, and I much prefer we > > fix/improve upstream). > > Any reason you can't add the stable -rc tree to your CI system? The problem is looking at results and making sure nothing breaks and sending mails out that patches shouldn't be applied and all that. Keeping the machines busy is the easy part. For Linus' -rc/-fixes we do that (including human review of all the stuff the scripts suggests we need to cherry-pick as fixes), but that's because we have someone. Maybe we can/should look into doing the same for the current stable (to support fedora and other community distros a bit better). But I think there's no way we can support all the LTS kernels out there and more than just minimal backports. > > For the actual products we're shipping we have dedicated teams doing the > > backports. The upstream stable releases essentially have no value for us > > from a customer support pov (for drivers, I guess core stuff is an > > entirely different matter), there's not a single serious customer or > > bigger user using that. It only costs, by spamming us with mails and bug > > reports for stuff we didn't even nominate :-) > > Any reason why you aren't sending those backported patches to the stable > trees so that users of them can benefit from the work you are already > doing for a limited number of "customers"? They fail your backporting criteria. Big time, like veeeeeeery big time. Think backporting 1k patches to get some feature. Which then means it's a frankenkernel without any relation to any shipping stable drm/i915 release, so the backports of the bugfixes are again meaningless and untested for anything else. Tbh the easies for us to support is what rhel does for their updates, which is just copy all of drivers/gpu/ into their old lts kernel and then fix things up at the seams. > And if your customers are not using stable kernel releases, what are > they using for their kernels? LTS, but with a frankenstein drm/i915. To clarify, all I'm discussing here is just drm and drm/i915 patches, I think for core code the stable process works reasonably well (afaiui at least). > It sounds like you don't want to deal with the "automated" patches for > the i915 drivers, so that's fine, we will blacklist them and ignore > them and only deal with the patches you explicitly ask to be backported. > As it seems like those are hard enough for you all to deal with, given > the recent regression :) Yeah that would at least not make it worse. On the entire problem (that we share with amd folks, see Alex' reply) of how to ship gpu kernel driver updates to people who care, but don't want to track latest upstream releases, I'd love to have a solution. I just don't see one (except tons of manual backport work). Fundamentally the problem is that the product freeze cycle for core kernel code (measured in years often) is just plain unsuitable for gfx drivers (where in userspace we often end up shipping well-tested points from master because the quarterly releases are too slow). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
