| 1 |
21.08.2013 12:25, Tom Wijsman пишет: |
| 2 |
> |
| 3 |
> 3.10 is not a shiny new version, it has been in the Portage tree for 7 |
| 4 |
> weeks now (upstream release at 2013-06-30 22:13:42 (GMT)); so, that's |
| 5 |
> almost double the time you are suggesting. |
| 6 |
> |
| 7 |
|
| 8 |
Current stabilization target(3.10.7) was added to tree: |
| 9 |
|
| 10 |
*gentoo-sources-3.10.7 (15 Aug 2013) |
| 11 |
|
| 12 |
15 Aug 2013; Tom Wijsman <TomWij@g.o> |
| 13 |
+gentoo-sources-3.0.91.ebuild, |
| 14 |
+gentoo-sources-3.10.7.ebuild, +gentoo-sources-3.4.58.ebuild, |
| 15 |
-gentoo-sources-3.0.87.ebuild, -gentoo-sources-3.10.4.ebuild, |
| 16 |
-gentoo-sources-3.10.5-r1.ebuild, -gentoo-sources-3.10.6.ebuild, |
| 17 |
-gentoo-sources-3.4.54.ebuild: |
| 18 |
Version bumps 3.0.91, 3.4.58 and 3.10.7. Removed old. (skip) |
| 19 |
|
| 20 |
|
| 21 |
So it is definitely NOT 7 weeks(30 days period counting from time when |
| 22 |
ordinary user can install it through portage, thus - after hitting |
| 23 |
portage tree). You know, that we can lighten stabilization requirements |
| 24 |
of 30 days sometimes, but let's be honest. |
| 25 |
|
| 26 |
> Why should an external proprietary module that does not fix what is |
| 27 |
> broken for 7 weeks now block stabilization; it has never blocked |
| 28 |
> stabilization before, and I do not see a reason it should now... |
| 29 |
> |
| 30 |
>> And that fact, that you can successfully build and run kernel for a |
| 31 |
>> couple of hours, does not make it "good, well tested stable candidate" |
| 32 |
> |
| 33 |
> Having people run it for 7 weeks is not a couple of hours. |
| 34 |
> |
| 35 |
|
| 36 |
First of all, as i said early - it is NOT 7 weeks(thus - not a couple of |
| 37 |
hours either). And example with Nvidia drivers is not point of beginning |
| 38 |
a flamewar. We ARE a distro. Then, we should propose INTEGRATION of some |
| 39 |
kind. |
| 40 |
|
| 41 |
If some open-source modules with active upstreams, included in portage, |
| 42 |
do not support yet 3.10.* which will lead to unbootable system for some |
| 43 |
stable users - what you should say? "Oops, sorry, guys?" That's not how |
| 44 |
stable should work. We should either mark such modules as forever |
| 45 |
unstable(or even mask?), saying "guys, shit happens, do not use this in |
| 46 |
Gentoo, unless you are dead sure, that you can handle problems with |
| 47 |
updates" or slowing down stabilization(i am not talking about security |
| 48 |
stabilization right now). And as for security stabilization, if you say |
| 49 |
that version bump BRINGS security fixes, you KNOW what they are, and you |
| 50 |
do NOT file a security bug about old stable(and now - vulnerable!) |
| 51 |
kernel on Gentoo bugzilla, then current stabilization bug has no |
| 52 |
relation to security(as Gentoo Security team does not know about |
| 53 |
security problems), period. |
| 54 |
|
| 55 |
|
| 56 |
> Well, my thoughts is that the way we are doing it now we aren't going to |
| 57 |
> be able to deal with the lack of resources; so, a different approach is |
| 58 |
> necessary and I don't see how it is "old, but also breakable"... |
| 59 |
> |
| 60 |
|
| 61 |
I undestand your disturbance as Gentoo Kernel team member. But your |
| 62 |
proposal does not seem good to me. |
| 63 |
|
| 64 |
-- |
| 65 |
Best regards, Sergey Popov |
| 66 |
Gentoo developer |
| 67 |
Gentoo Desktop Effects project lead |
| 68 |
Gentoo Qt project lead |
| 69 |
Gentoo Proxy maintainers project lead |
Archives