On Thu, 8 Aug 2013 15:29:06 -0700 Greg KH <gre...@gentoo.org> wrote: > On Thu, Aug 08, 2013 at 04:43:09AM +0200, Tom Wijsman wrote: > > > > > On Thu, Aug 08, 2013 at 12:50:32AM +0200, Peter Stuge wrote: > > > > I think this supports the argument that the better kernel is > > > > always the one with the most fixes. > > > > Define "better"; because 3.10.0 has also been worse than the last > > 3.9 release in some ways, despite it having more fixes than the > > last 3.9. > > How was it "worse"? You don't seem to define that either :)
The point is rather whether it can be defined, therefore it is also worse in some ways; of course without statistics you can't really define it, but as long as there is reason to believe it people are going to follow this train of thoughts. For example, the LTS kernels. > Yes, there are always going to be bugs and regressions, but as long as > we are fixing them more than we are making them, we are doing ok. That's might be a false impression; have you took a set of commits from back in time, analyzed what they caused and have a report available? There's reason enough to be wary of refactoring, new features and more to regress the first release of a new branch; and none of these are actually fixes, they are not ok when you are looking for stability. (Add to that that fixes can also cause bugs and regressions.) Later releases in a branch don't contain such commits, only fixes; so, therefore skipping the first releases of a branch is a normal thing to do, unless there's proof or more convincing argumentation that it is a stupid thing to do I don't see a change in this behavior any time soon. Without statistics, neither person is wrong or right; so, both behaviors happen and are based on thoughts, reasoning and beliefs. So, when stated that the "better kernel is always the one with the most fixes" one needs to objectively define "better"; otherwise that sentence is meaningless. Without a definition and supporting evidence, that is a contradiction. -- 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
