On jeu., 2016-03-17 at 14:22 +0100, László Böszörményi (GCS) wrote: > > Well, uploading new Linux major version to stable looks indeed not > trivial, > > (thus my filing of #810506), but ultimately it's the RT's call. > I mean can you remain in sync with kernel updates (security updates > only) in stable?
No, I can't guarantee that, considering the current grsecurity release model. That's why I'm asking the RT about new Linux major versions in stable. > > >> The patch itself can be updated more easily > >> with point releases and users may compile and test their updated > >> kernels before using it. For me this gives more trust in the package, > >> even if it needs more attention from time to time. > > > > Well, I'm not sure how much sense that make. Do you intend to ship in > stable a > > patch completely unrelated to the current kernel and just follow the test > > kernel and ship it pristine? > It's better to write in detail about my point of view. With the patch > only I would target more experienced users that can and do compile > their kernels. The plan is to have two kind of patches shipped in the > package. One tracking the stable release kernel as close as possible > (security updates only). I honestly don't know how you'll be able to do that. The test patch only follows the latest stable version, not previous ones or LTS, and stable/stable2 patches are restricted. > The second is to add the latest test patch > say, every six months. And here I don't see the point to have 6 months delay. While it might not be useful to track *each and every patch*, beeing 6 months late doesn't make any sense to me. > This can give users a time to follow upstream > kernel development while have the up-to-date testing patch on top of > it. OK, they will need to compile and use their own kernels - but this > also gives more flexibility to them as they can choose which feature > of grsecurity to enable + use. > With a packaged binary kernel you don't have the freedom to choose the > options and harder to get it included in a stable release. Especially > if it's maintained and tested by multiple maintainers to support > several architectures and not just i386 and amd64. Sure, but I have to admit I prefer getting the patch directly from grsecurity.net then. > > >> > I can certainly let you request the removal, or will handle it myself > at > >> > one point, unless you really want to keep it and have it updated. > >> Sure, I've failed big to keep it up-to-date. But I would like to keep > >> this fresh in the archive. Hope upstream will release testing kernels > >> every now and then. > > > > I'm not sure what you mean here. > I would like to keep Sid updated and provide updated patches for > stable kernel packages. For this I need upstream to release testing > patches in a timely manner. Which is already the case. > But as mentioned above, I think six months > updates may be enough for advanced users. You get new features while > not compile a new kernel every second day. This seems to be a good > balance. I sure hope people update kernel more often than every six months. > > Hope this is more clear now. Not really, but at least for the initial intent of this bug, yes: you want to keep the package in the archive :) Regards, -- Yves-Alexis
signature.asc
Description: This is a digitally signed message part
