On Sat, Jun 22, 2013 at 02:02:59AM +0200, Tom Wijsman wrote: > On Fri, 21 Jun 2013 07:58:01 -0700 > Greg KH <[email protected]> wrote: > > > I bumped the vanilla-kernel sources yesterday, and deleted some > > obsolete, and known-insecure versions at the same time (i.e. the 3.7 > > and 3.8 ebuilds.) > > Thank you for keeping an eye on them; I got into a habit of only > bumping gentoo-sources, so I don't always remind the to do vanilla, > I'll do my best to add it to the habbit in the future. > > > They were added back because they were the last releases marked > > "stable" for some arches. > > Yes, this is actively being checked to avoid that there is no stable > kernel present; if you don't want that to happen then you should make > an individual arrangement with the arch teams, such that they are aware > that the stabilization of this package is individually arranged. > > Since ago does stabilizations for multiple arches, is involved in > security bugs and did the restore on this particular package; I have > added him to CC so he is aware of this discussion going on. > > http://thread.gmane.org/gmane.linux.gentoo.kernel/697 > > > In thinking about this, that's totally wrong. Either all of these > > ebuilds are marked stable, or none are. And we should really NEVER > > have known buggy ebuilds marked stable for the vanilla kernels, as > > that's just dangerous on many different levels. > > > > So, should I just mark these always stable, or never stable? I don't > > think we should mix the two, as the previous versions are always known > > buggy, and have problems, and shouldn't be used. > > I think it may be a nice idea to have vanilla-sources reflect upstream; > that is, always stable and drop versions which are not.
Great! But as only the latest version released is "stable", that's all that should stick around, right? > If possible we could script it to keep the package unstable the first X > days it is in Portage to keep the stabilization effect in place; that > way Gentoo users are unaffected if something goes wrong the day after > you push a patch, I assume not, but you never know. If something goes "wrong" the day after I push a update, I push a new one fixing the problem, so this shouldn't be an issue, right? And as these are coming out about 1-2 a week, the timeout before the arch teams could get around to marking things stable seems like a lot of work, for something that isn't really needed at all. thanks, greg k-h
