 Why I brought this up is the fact that where I work at Creative, our database guys were complaining not about the Debian kernel per se, but the Weezy kernel, which is 3.2. And it's kind of considered not super great for enterprise database workloads. So, yes? Mike? What is Weezy and a half? Because we had this edge and a half. But it's on, right? What is Weezy and a half? Because we had edge and a half, but then we didn't have back ports. So, if you're now saying that the Weezy kernel is too old, why are you not using the back ports? Well, that's a good question. So, in general, I think for some people it might be, so there's two things to this, right? First would be Weezy and a half would entail new installation media. So we don't do that with back ports officially, at least, as far as I know. The other thing is giving it a bit more official status. So, back ports is official right now, but I think there are vendors or companies or people who don't really want to run back ports on their machines. You could say, and this is part of the conversation, that as soon as Jesse freezes back porting the Jesse kernel, it's probably good enough because it will be rather stable. So, do we really need it? This is actually a good question. So, is there any more input on that? Yeah. So there's two differences that I can identify between back ports and a Weezy and a half. One of them is, as you say, perception. If we tell somebody we're running Debian, actually in Google Compute Engine, we offer Debian Weezy images. We offer Debian Weezy back ports images because the new kernel primarily and other performance benefits. People don't know what back ports mean. It's not obvious. We have to say, well, the other thing, there was security support. So, right now we have to say, if you care about performance, use the back ports image with back ports kernel. If you care about security, with security support from the security team, run stable and have bad performance. Also, if we had the kernel, the new kernel in Weezy, it could get both security support and not confuse people. Right. So, while as soon as Jesse is released, it would have security support and if we back port it fast enough, maybe, yeah, please. I was, I think, trying to formulate a response to that. And I think that the question is, what does the security team actually support? Is the security team going to continue supporting the original Weezy kernels at that point? Or does it only support the Weezy and a half kernel? And is there a plan to deprecate the older one? Because from the security team's point of view, speaking as a former member of it, the manpower there is very limited. As it is, the team relies largely on the kernel team to actually do security work for the kernels. So, how do we make that easier, I guess, is the question that spins up for me. Right. So, I don't think anybody of the active security team is here. Yeah, I think, what? Sorry? All the kernel team. All the kernel team, right. I'll make all the decisions on their behalf right now. No, no, no, no. If we do use the Jesse kernel as the basis for this, that'll make the security support a lot easier, but there will be fewer, you know, fewer base-harvel, base-source trees to work from, and only any differences in the backporting would make that any harder. It's also, I would, if the upgrade from standard Weezy kernel to the upgraded kernel is harmless enough to users, which is not a guarantee, I would care less about deprecating the old one, if we start with the Jesse kernel, it's not as much of a burden as otherwise. Okay. Any more? You want to pull up on that? No. Right, yeah, that's a good question. I think my just would be that the security team shouldn't get a lot of more put on top of it, so we probably need somebody to maintain the Weezy and off kernel, whereas the Weezy kernel should certainly still be supported security-wise. I think just deprecating it would not be a great idea, so I'm not sure how everybody else is feeling, but so we would need to have additional people to do that. I or some of my colleagues might be interested in stepping up to that. We are just looking at how is the general interest. I mean, if everybody says, you know, backport is fine enough, we don't know. So this was kind of one of the reasons I wanted to have this conversation, right? So would it make sense? Yeah. I think we could also just marketing or name a release based with Weezy backports as Weezy and a half, because then we there's a security support, backports gets us from new upstream versions. But just for the kernel, you mean? Just for the kernel, yeah. What else do you want? A half release. You will always increase the load on the security team, because you will always need to support both versions. Right. So, well, if the Weezy, I mean, you already have to support Weezy and Jesse, at least for the Weezy timeline, right, for the support. There's already two. And then it would be more or less like a backport into Weezy and a half. So the hope is that the security team doesn't have a lot of extra effort. And somebody else would take the Jesse security supported kernel and upload that to Weezy and a half. If you take, if you really release at a half and get them 316, you will need to support 316 for two years. If you just take the kernel, say the backport kernel and then later use upgrades to 318, you don't have to support 316 so long. But Jesse will be 316. No, I was in the Weezy and a half case. Yeah, but we would take the Weezy kernel. We would take the Jesse kernel, right? Okay, so that's, of course, one of the, like, should we use the Red Hat Enterprise kernel? Should we use the upstream kernel? Should we use the unstable kernel? For me personally, I think sensible would be to take the Jesse kernel, which would be frozen anyway, and just get security support and put those back into Weezy, right? So that would be not so much effort, I think. So you want to say something? Taking, you know, if, you know, what I think Holger was suggesting, would I think, Shuaifin Furman, you were suggesting that we sort of, for Weezy and a half week, on ongoing basis track the backports kernel, or just call that the backports kernel Weezy and a half, the big problem there is security. So for example, right now in backports, if there's a security bug in the stable kernel, it's fixed pretty quickly. If there's a security bug in backports kernel, it can linger for days to weeks, depending on, I mean, they do try to, you know, update it pretty quickly in the case of a security issue, but it's a best effort matter, whereas with a security team, they are very good at being fast. So with, if we want to ensure that Weezy and a half is at least close to that fast, maybe with a bit more lag time, having something that's much closer to Jesse's kernel from the same source tree even is going to be less disruptive to that effort than a moving target that doesn't have any security team focus on it, even in Jesse. And I guess, but okay, also no backports antenna here, but I think the general gist would be that Weezy backports would not get anything beyond the Jesse kernel, I guess. I mean, because then testing's frozen, right? So it stays there. And as soon as Jesse's released, there would be Jesse backports, but Weezy backports would still pull from Jesse. So I think at least Weezy backports will not get anything beyond 3.16. That's my understanding. Does anybody have other information? But I think that's so. In general, it would basically be the same thing, I would say. And then the point about security is, of course, that right now, maybe the security is not so great, but as soon as Jesse's frozen and or almost released, the security will support it. So there might actually be the question of timing, of course. So as a Weezy and half, what does that mean? We are maybe one-third into the lifetime of Weezy now, I think, or almost one-half, so we would have to do it towards the end of the year, I would say. So after the freeze is useful, so we have the kernel, but there might be a window. I'm not sure where the security team is not yet on supporting the Jesse kernel. And maybe it's useful to wait with the possible Weezy and half until it's actually security supported. Or we could say, well, we will put in the extra effort for a while and then just pull from the security team. I'm not sure. I mean, that's two possibilities. Or does anybody have any input on the specific timing? I mean, I think. So Weezy was released in early May 2013. The Jesse freeze will be in early November. So if we think about a Jesse release, well, I don't know. In the late first or second quarter of 2015, that would mean that Weezy will be supported until the late first or second quarter of 2016. Am I getting this right? Right. So that would mean late 2014, I guess, as a half-time of Weezy. Which kind of comes together with the Jesse freeze rate. So anybody have any input on that kind of specific timing as that they should do it after the Jesse release or earlier? Or not really? OK. So the other thing is, of course, what should be included in Weezy and half? I mean, we talked about the kernel now. Is there any interest in also, well, I think if you backport the kernel, you also have to possibly backport a couple of kernel-related things which have kernel modules and maybe their interface changes like the RBD. We came up with a couple of things. I'm not sure what happened right now. I mean, the RBD was the one that we came up with, which is quite high-profile. There might be a couple of others, pacemaker, I'm not sure. The other question is, is anybody interested? So OK. So if, say, we are interested in working on that side and there is interest in Debian in general, so some, or maybe does the stable release manager want to say something first? You're not going to comment? OK. So if we say, OK, we will put the effort in, but we will consider ourselves only really interested in kernel. Is anybody interested in the graphics stack? So having a newer graphics stack, because we had that in an etch-in half, also had a new graphics stack, I believe. I don't see that. So maybe that works well enough for everybody. Or maybe they could just upgrade to Jessie, yeah. It's true. So it might be more of a Petla server kind of thing. We start getting reports in tales about graphics drivers that are not working so well on Weezy and would be solved with the graphics stack in Jessie. I'd be interested in seeing Xorg backpourses in Weezy in an half, but that's... You don't have the main part. Yeah, quite some work. OK. You? Yeah. I'm not sure I understood. Do you say that Tales already does that? Has the Xorg backport? OK. No, there are back reports which would have been fixed by an Xorg backport. But... And how fast would Tales go to Jessie, I think, after? So also not really... I mean, it would be useful to at least some draft distributions, apparently, right? OK. So any other... Yeah. There's also a few other minor packages that are related to allowing the new kernel to perform fully or fixing performance-related bugs at that hardware-related layer, such as, for example, Weezy's IRQ balance. So the new kernel supports multi-Q networking and VerdeoNet, which is relevant for our environment. And, however, IRQ balance in Weezy cannot effectively set IRQ affinity, so we've been having to do it manually in a start-up logic that we've added. The Weezy backpours in Jessie version is totally fine. There was a bug in the old version, so a few random packages like that may be worth considering as well, even though it's not a strict kernel dependency. Any other input comments? OK, so maybe as a quick poll, would anybody be interested in actually investing some work into making it happen? Not really, OK. Well, maybe backpours is good enough, right? So, yeah, I wanted to... Was that a... OK. The idea of also providing installation media sounded good, but then with the release date of basically a few months before Jessie, it's pointless, basically, I think. It was really different with etch-on-the-half, when there was no backpours as well. It's true, yeah. OK, I'll write that down. Well, then, I guess that was a small session, because, I mean, or is there any further input? I'm not aware of anything. So it seems, apparently, that generally it would be interesting, but backpours is kind of OK. Maybe somebody will watch the stream and say, hey, I'm super interested, sign me up, and then we will think about it. I mean, if there are some compatibility issues in Stable with newer kernels, those packages could conceivably be fixed in Stable as well. Right, but if... Well, there's also the thing that if it's so incompatible that it doesn't work with the wheezy kernel anymore, the old wheezy kernel, what do you do then? But you don't think so? In case I mentioned it would work. But it would fit the new version, so we'd have to see if there's a minimal commit or not. OK, then if there's some further input, I think that's it then. I'm sorry.