 I am going to sit down and I'm going to take some notes but if you can also write help with taking notes in gobby would be good. So what is that right? I'm dating selected drivers. Is anyone interested in working on that because in the past when we've done driver updates in the kernel that's mostly been me taking time to attempt to backport the drivers and then trying to get other people to test them and not always getting a lot of feedback. Sometimes I've had sometimes we've had contributions from either the hardware vendor or another interested party who's done the backport tested it on hardware available to them but it doesn't happen very often. Is there anyone who would be interested in working to do driver backports? Indeed contracting developers to work on that. So this doesn't look like it's a very viable option at least for now. Possibly that one works. So you know there were backported drivers available on zero one org for a while we're doing for Intel and what came out of that was that yeah as you said in your in your buff notes that it is prone to regressions and quite often it's quite painful especially in fast-moving areas like graphics or do a backport because the kernel infrastructure threshes insurance so fast that you end up you basically end up writing a new driver. So in a slow-moving area you could maybe do that. I mean I would say like especially if a hardware vendor comes to you and says like we actually have the hardware we'd like it and you get some support from them it's viable but other than that I mean even you know even with Intel's backing some of occasionally older GPUs would simply stop working on a backported driver because nobody you know nobody except a random end user somewhere on the other side of the world have the hardware and we wouldn't find out until it hit them and that was with someone the size of Intel backing the work and doing testing so I kind of agree with what you said in the notes it's not a hugely viable approach. So we have new kernel versions going into the stable backports suite usually very soon after the corresponding version goes into testing. What we don't currently have is a way to use that in the install officially although I was told just before I came here that that's probably going to be possible in the very near future. How is that working out? Are people using kernel from backports? Are there compatibility issues with using it with the stable user land? What are people doing to get to install systems with that kernel version at the moment? I've been using backports kernels on a few different systems not a huge sample size but I've had no real problems haven't used them with the installer I've just installed you know upgraded from backports but haven't encountered any problems with it so far so it seems like it's at least good. So in that case the so why did you want to upgrade to the version in backports? I can't remember the exact details I needed some new feature that was only available in the newer kernel I had to try it so for that reason but I didn't encounter any problems with it it seemed to work fairly smoothly so just to give you a small data point. Okay how about let's have a show of hands who's using kernels from backports on some systems okay would some of you like to speak about how that's working only if you've run into if you've run into any compatibility issues with that's working out fine if you had difficulty installing or it's all everything's good so the last option I wrote about there was adding an alternate kernel version to the stable suite which is something that has been tried before in the edge-and-a-half release and I've just done that again for Jesse but only because the because Jesse backports is not going to accept new uploads. Does anyone have an opinion on whether this is sensible, supportable, something we should do for something we should do for stretch or for buster or is it fine to have this to do this through backports? I'll answer that with another question how much capacity do you have and how many more people do you require to make it viable because like obviously a lot of people are using backports so there's a requirement there or at least a desire for newer kernels how much extra effort is it to make it a sort of first-class will actually update the kernel in the stable release so long as the version is essentially the same so long as the version is the backboarded version is essentially the same as the version in the next the next suite next next release then there's very little ongoing maintenance effort needed there's of course there's some to backport and remove dependencies or conflicts that might exist in the oldest or in the older release but that's you do it once and then merge changes after that and that's that's in my experience that's gone pretty smoothly okay you know in that case that would seem like a sensible approach to me it's my opinion that probably time for a show of hands vote if no one has anything to say given then official backwards are not so official for example bug reports we cannot do it in the backwards I would love to see the kernel in the stable newer kernels in the stable well in practice people do file bugs on the moment in backports and I certainly treat them like any other bug report in part because the the kernel isn't isn't really dependent on any of the libraries and the user space libraries that might be over in stable so the chances of a bug being specific to the backports environment or introducing the backporting are generally very low so I think on the I think bug reporting I don't know maybe it's possible that people are discouraged from filing bugs in the in black box kernel because of this general policy as long as we have newer kernels for the stable it doesn't matter if I get it from backwards or it's there as long as it works I'm fine but it will be good to see it officially in the stable or so the the backports kernel I have a different kind of security support once you get to the backports kernel you're forced to more often upgrade so yes it's a stable yes yeah so that might be interesting if we have something like go with the newer kernel which provides sonnable support for example I think it's available only with a more modern version than what's in stretch so it might be interesting to have something available which is backported from the upcoming release not sure if this is feasible for security support in LTS then this might be something to consider but if that's an option would be great I think I'm not not entirely sure I understood that about the security support I mean once we have it in in the stable release it will be covered by LTS I assume yes yes that would be great because the alternative is to just always update what's available in stretch backports currently the conversion you know the situation where which I had with the Lenovo driver for hardware support only option would be to just jump on a newer kernel version from from stretch backports and then we are forced to always update the color yes you would you would have to keep updating until you get to until Buster is out at which point you're then getting backports from Buster which would be the same upstream base version of course I don't think we would I think that adding support for an intermediate version between stable between the default stable kernel and testing and maintaining that long term that I don't think that's viable that's what I was afraid of yeah sorry of course I just want to ask about the three options that we have here it seems to me that they do not conflict I mean we can do all of them as long as we have the resources right and we are actually setting the priority which one is to be done first and which one is the next so my opinion is maybe we can have even more recent kernel versions in backports which we do not provide the same level of security support so that people can still enjoy using newer kernel versions but for the stable release we because we have to provide security so we and because we do not have I guess we do not have so many resources to to to provide enough security updates so we stick to the same version as the as the next release just not to say okay yeah right just another one have anything to add any any opinions on on any of the options would like to work on either driver updates or alternate kernel versions in stable the backports I mean that that's that's what we have at the moment so probably no extra effort needed that the kernel version the backport suite I could be interested in helping with updating drivers but I'd like to talk to you about that after okay thank you I might stop here then okay