| |||||||||||||
|
| |||||||||||||
ECNECNPosted Oct 28, 2008 1:33 UTC (Tue) by nick.lowe (subscriber, #54609)In reply to: ECN by dlang Parent article: Stable kernel 2.6.27.4
"unfortunantly this is one of the problems with a time-based release"
I couldn't agree more! My main objection to all of this is Ubuntu's definition of RC which seems to
The release date is set in stone in the version number (200)8.10. To me, it is an absurd way to
(Log in to post comments)
ECN Posted Oct 28, 2008 1:53 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
you need to be fair here.
Ubuntu has delayed a release in the past, so the release date isn't as fixed as you make it out to be.
also, the debian model of "don't release it until there are no known bugs" is also known to have it's own problems (releses that can be delayed for years)
since you feel very strongly about this, you really should be telling the ubunto folks your opinion, not just posting them on a third party website.
ECN Posted Oct 28, 2008 1:57 UTC (Tue) by ncm (subscriber, #165) [Link]
Nothing but embarrassment keeps them from releasing 8.10 in November. The insanity lies not in picking a name that implies a target date, but in letting embarrassment at missing the target date trump release quality.
ECN Posted Oct 28, 2008 8:48 UTC (Tue) by njs (subscriber, #40338) [Link]
...But they're not compromising release quality. As mentioned upthread, in a comment you replied to before writing this comment, they've already released a workaround -- one that was less risky than re-rolling their whole kernel package, and that had already been tested to fix the problem.
You know I respect you a lot, but in this thread, it feels almost like some need to find things to be angry about is overpowering your technical judgement. Hope everything's alright...
ECN Posted Oct 28, 2008 19:01 UTC (Tue) by ncm (subscriber, #165) [Link]
Not angry, disgusted. I read through the whole launchpad thread, and was exposed to the denialism you must have missed.
I agree that 8.10 with the procps workaround will work OK on low-speed links. But the workaround is enormously more complicated, and has much broader effect, than the patch, so would need more testing, not less. And how will the workaround ever be got rid of?
My brother runs Ubuntu on his laptop, and brings it to me for fixups. The last upgrade (F -> G) was such a mess I that haven't encouraged him to bring it in for H. I certainly wouldn't suggest he do it himself.
ECN Posted Oct 28, 2008 5:18 UTC (Tue) by jamesh (subscriber, #1159) [Link]
There will always be one more thing that'd be nice to fix before a release, but you need to stop at some point if you want to make a release. If you are going to freeze things make releases, you can do worse than regular time based releases (since it gives a good indication of when features that miss the release will be made available).
In this case, a problem was identified with two possible solutions: disable the problem code or fix it. While in the long term disabling the code is the wrong solution, it must have been deemed to be the less risky choice in the context of the upcoming release (i.e. which change is less likely to introduce more bugs). So, the choice made is actually related to release quality.
You'll see the same sort of decisions made elsewhere, picking a low risk solution for the short term and a correct solution for the long term. For example, disabling the dynamic ftrace feature in the 2.6.27 series rather than merging a proper fix.
|
|
||||||||||||