On Wed, 21 Aug 2013 13:42:56 +0400 Sergey Popov <pinkb...@gentoo.org> wrote:
> So it is definitely NOT 7 weeks Let me clarify this again, our last stable kernel is from 7 weeks ago. > 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. We consider that as well, and for all the past releases it worked out. > Policy says that we should wait reasonable amount of time, no matter > which version it is. It does not state anything about versions in the policy, AFAIK; please refer me to it, and also note that on top of that we have the permission from the arch teams to auto stable minor releases when necessary. > 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. If you run ~, a breakage that you and some others experience less than once a year is to be expected; so, what you state here does not reflect our way of stabilization. In most of the cases, a later minor is better. > 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. No, what you propose is what we have been doing for a long while. > 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. Okay, then feel free to propose which versions we should pick for stabilization? At which times? As you will see, it doesn't work out... The kernel releases are not to be confused with that of another package; if I take a look at KDE's 4.1 announcement [1] I see that it is a "feature release", which is not what a minor kernel release does. [1]: http://www.kde.org/announcements/4.1/ > >> 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. So do I, but why should it block stabilization? Why do the stability and security of other users have to suffer by that? There are other ways to deal with this: - Keep nvidia-drivers unstable, though they likely don't want to. - Clearly state that they don't work together, users should read that; but well, do we really want to account for the users that don't read? - Dep block the packages, *ugh*, let's not do this if we don't need to. - ... > >> 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). You do draw assumptions, because you don't take a look; please do: https://bugs.gentoo.org/buglist.cgi?quicksearch=assignee%3Asecurity%40gentoo.org%20CC%3Akernel%40gentoo.org Sort by "Changed" such that the newest appear on top. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
