stable? quality assurance?
in [Kernel]
|
Prev: KVM: MMU: introduce pte_prefetch_topup_memory_cache()
Next: NET_NS: unregister_netdevice: waiting for lo to become free (after using openvpn) (was Re: sysfs bug when using tun with network namespaces)
From: Valdis.Kletnieks on 12 Jul 2010 11:00 On Mon, 12 Jul 2010 15:42:32 +0300, Alexey Dobriyan said: > On Mon, Jul 12, 2010 at 3:35 PM, Marcin Letyns <mletyns(a)gmail.com> wrote: > > Last time I tried freebsd it wasn't stable. It had problems with my hard > > drive controler. > > This thread needs more anecdotal evidence. To be fair, the continual re-appearance of this thread is *always* anecdotal. It's always somebody who has trouble getting it to work on *their* hardware, or with *their* software, and insisting that stuff doesn't get shipped unless it works properly on everything. Apparently, having it work on 99.997% of the gear out there isn't good enough for them. Then there's the inevitable call for "no shipping with blocker bugs" - never with a good objective definition of what constitutes a "blocker" bug. Ted had it right - you insist on fixing *everything*, you end up with Debian Obsolete. It's the nature of the beast - you *will* detect regressions at something resembling an exponential-decay curve. The only question that remains is how close to zero it has to decay before the ship date - and there's no single answer for that which fits everybody. One point to note is that if you ship earlier, the decay rate increases because of wider deployment. As a result, it's quite probable that you get to some objective level of "stable" faster by releasing early and then releasing a half-dozen dot releases, instead of waiting for the 3 or 4 dozen people testing it before release to shake out all the bugs (which obviously won't happen due to things like access to hardware).
From: David Newall on 12 Jul 2010 12:00 Marcin, >> I don't expect fair consideration of these comments; why change when >> shooting the messenger is so much more satisfying? >> Q.E.D. First, for the sake of brevity, I want it agreed that we're talking about new kernels, not those which are old, time-tested and patched. I didn't notice anyone say they want Linux development to slow down; rather, and not just in this thread but in many threads before, that kernels released as "stable" fail to meet the common meaning of that word; and this needs to be improved. Predictably, the common response sounds a bit like "shut up, go away, you're an idiot, it doesn't happen to me." These are not useful as they serve not one whit to improve the situation, but give pause to those who might otherwise want to bring up a valid issue, once more. Expectations are key to the problem. When Linus says, "here is a shiny new, stable kernel", he creates expectations. When that kernel proves unstable, those expectations are dashed and confidence in Linux suffers. There's no reason why development methods need to change in order to reduce the number of flaky "stable" kernels. It would be sufficient to replace the somewhat deceptive word "stable" with one that is more accurate; beta or gamma test make sense as they already have industry acceptance. Clearly "stable" is not appropriate, as implicitly agreed by others who have advised: "don't use in production"; "wait at least a year"; and more. Thus 2.6.34 is the latest gamma-test kernel. It's not stable and I doubt anybody honestly thinks otherwise. As to whether other operating systems are stable, well that's a fair question. I agree that few large bodies of computer code are flawless, and so stability can be relative. In that spirit I venture to put the stipulated kernels into order of decreasing reliability: Best is BSD, Solaris & OS X; then Windows; and then there's Linux. If named distributions had been included, the list would look better (for us); they'd go in the first group. Thank goodness for the Debian, Red Hat and Novell (to name just a few) for giving the world something which does, at least largely, meet expectations. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Marcin Letyns on 12 Jul 2010 13:50 2010/7/12 David Newall <davidn(a)davidnewall.com>: > > First, for the sake of brevity, I want it agreed that we're talking about > new kernels, not those which are old, time-tested and patched. > > I didn't notice anyone say they want Linux development to slow down; >rather, > and not just in this thread but in many threads before, that kernels > released as "stable" fail to meet the common meaning of that word; and > this needs to be improved. I remember when Greg (correct me if I'm wrong) said something like there are no more stable releases. Those are distros which should choose a 'proper' kernel. This seems to be working well: Ubuntu usually ships with the one release older kernel, the same about Debian, but they're much more restrictive and some other distros. Those who wants to live on a bleeding edge they choose Fedora with the latest kernel etc. Personally, I consider the LTS kernel is a stable one and IMHO, like someone said in this thread before, the latest mainline kernel shouldn't be called stable, but differently. > Predictably, the common response sounds a bit like > "shut up, go away, you're an idiot, it doesn't happen to me." �These are not > useful as they serve not one whit to improve the situation, but give pause > to those who might otherwise want to bring up a valid issue, once more. Yes, I apologize for this. After reading your response now, such complains are much more clear to me. >�There's no > reason why development methods need to change in order to reduce the > number > of flaky "stable" kernels. �It would be sufficient to replace the somewhat > deceptive word "stable" with one that is more accurate; beta or gamma >test > make sense as they already have industry acceptance. �Clearly "stable" is > not appropriate, as implicitly agreed by others who have advised: "don't >use > in production"; "wait at least a year"; and more. > > Thus 2.6.34 is the latest gamma-test kernel. �It's not stable and I doubt > anybody honestly thinks otherwise. This is the whole point IMHO. :D Fully agree with you here. > As to whether other operating systems are stable, well that's a fair > question. �I agree that few large bodies of computer code are flawless, and > so stability can be relative. �In that spirit I venture to put the > stipulated kernels into order of decreasing reliability: Best is BSD, > Solaris & OS X; then Windows; and then there's Linux. �If named > distributions had been included, the list would look better (for us); they'd > go in the first group. �Thank goodness for the Debian, Red Hat and Novell > (to name just a few) for giving the world something which does, at least > largely, meet expectations. > In my opinion you shouldn't compare the latest Linux kernel (however, such comparison would be fair if the latest Linux kernel would be a 'real' stable one) to other operating systems, but rather you should just compare proper Linux distributions: Debian, RHEL to FreeBSD and Solaris, OpenSuse, Kubuntu to Windows and OS X etc. Otherwise, it's like comparing some *BSD development branch to Debian. The similar situation to described in this thread is when comes to Fedora. There are people (Linux newbies etc.) who can consider Fedora is just an another ordinary, Linux distribution, but they're wrong. Fedora usually ships with the latest, experimental stuff and if some newbie (or even developer) decides to use Fedora and then he discovers things simply brake he can consider Linux is a mess. Fedora shipped with KDE 4.0 development release and even Linus was taken in, because he probably thought it's a stable KDE release. Imho there should be a notice what people have to deal with. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Stefan Richter on 12 Jul 2010 14:00 Martin Steigerwald wrote: > Bugzilla severity and priority fields or something similar could be used to > set the importance of a bug report and the regression list could be sorted > by importance. One important criterion also would be whether someone could > confirm it, reproduce it. Even when I reported those desktop freezes, > unless someone confirmed them it might just happen for me. Well a "confirm" > or vote button might be good, so that the amount of confirmations could be > counted. "I can reproduce it" comments are often very helpful. "It is important to me (and it should be to you too)" comments perhaps not so much. If a bug doesn't make any progress, it may be because the cause of the bug (i.e. which subsystem is at fault or when the bug was introduced) is not known well enough. In such a case, more reproducers won't really help (let alone stating that it is important to somebody); then somebody needs to delve deeper into it and narrow the cause further down. A bug which can be reproduced by several people is usually a bug that can be reproduced quite reliably, and hence is a bug whose cause can likely be found by bisection. A bug report with a to be blamed git commit ID attached (at least as far as the reporter could determine), Cc'd to author and committer of that commit, has more chances to get fixed quicker than others. So, votes don't help IMO; good reports do. And the reports need to be early enough --- i.e. somebody needs to run -rc kernels --- since coming up with a fix, validating the fix, and merging it may take time. If there is little progress on a regression for which at least the faulty subsystem is known, and the release goes by, the merge window opens, and you see a pull request for that subsystem, then reply to that pull request with a friendly reminder that there is still an unresolved regression in that subsystem waiting for attention. [...] > As told already I will rebalance my decision on which kernel to use. If or when you cannot spare resources to test a kernel yourself (be it Linus' final release, or an -rc, not to mention linux-next), you can also look out for Raphael's regression lists around the time of a final release, to get a picture whether it is a worse or better one. -- Stefan Richter -=====-==-=- -=== -==-- http://arcgraph.de/sr/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Stefan Richter on 12 Jul 2010 14:10
David Newall wrote: > Thus 2.6.34 is the latest gamma-test kernel. It's not stable and I > doubt anybody honestly thinks otherwise. It works stable for what I use it for. If it doesn't for you, then I hope you are already in contact with the respective subsystem developers to get the regressions that you experience fixed. -- Stefan Richter -=====-==-=- -=== -==-- http://arcgraph.de/sr/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |