21.08.2013 13:28, Tom Wijsman пишет: > That is 3.10.7, not 3.10; please look into how kernel releases work, > minor releases are merely a small number of "backported" "known" fixes. > > What you propose, waiting 30 days for a minor; simply doesn't work > when there are one to two minors a week, it puts us even more behind... >
We considered stabilizing package relying on it's version. Policy says that we should wait reasonable amount of time, no matter which version it is. And yes, minor release MAY bring breakages, do not tell me that they are not, i hit such breakages at least 4 times for kernel(no matter gentoo or vanilla, so problem is NOT genpatches) for past 5 years. And do you really want to stabilize EVERY minor release of some upstream stable branch? Maybe you want to bring some stable well tested version for some period and let unstable users choose another if they want to? And then - jump to next stable branch. >>> Why should an external proprietary module that does not fix what is >>> broken for 7 weeks now block stabilization; it has never blocked >>> stabilization before, and I do not see a reason it should now... >>> >>>> And that fact, that you can successfully build and run kernel for a >>>> couple of hours, does not make it "good, well tested stable >>>> candidate" >>> >>> Having people run it for 7 weeks is not a couple of hours. >>> >> >> First of all, as i said early - it is NOT 7 weeks(thus - not a couple >> of hours either). > > It is 7 weeks. As i said early - it is not. Kernel team may have different policies on stabilization, that's OK IMO, but do not bend facts. This is release, and it should be considered as release, no matter minor or major. And stabilizations counts from it, not from 3.10.0. Following your logic i can say that KDE 4 is major release, and 4.1, 4.2 etc are "minor". They are not. >> If some open-source modules with active upstreams, included in >> portage, do not support yet 3.10.* which will lead to unbootable >> system for some stable users - what you should say? "Oops, sorry, >> guys?" That's not how stable should work. > > That's how it has always worked, we do not see a need to change this. No it is not. We considered such things as serious flaws. At least - i consider. >> And as for security stabilization, if you >> say that version bump BRINGS security fixes, you KNOW what they are, >> and you do NOT file a security bug about old stable(and now - >> vulnerable!) kernel on Gentoo bugzilla, then current stabilization >> bug has no relation to security(as Gentoo Security team does not know >> about security problems), period. > > Actually, those are constantly filed by ago; please look at the picture > first before you describe it, because you are drawing assumptions here. > I do not see any dependant bugs in your current stable request, but you keep telling me about security, so i do not drawing any assumptions - it is not security stabilization in terms of Gentoo(probably it becomes so if you can find apropriate security flaws). -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead
signature.asc
Description: OpenPGP digital signature
