public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Tom Wijsman <TomWij@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Cc: gregkh@gentoo.org
Subject: Re: [gentoo-dev] Vanilla sources stabilization policy change
Date: Fri, 9 Aug 2013 10:10:23 +0200	[thread overview]
Message-ID: <20130809101023.6618a356@TOMWIJ-GENTOO> (raw)
In-Reply-To: <20130808222906.GA30314@kroah.com>

[-- Attachment #1: Type: text/plain, Size: 2267 bytes --]

On Thu, 8 Aug 2013 15:29:06 -0700
Greg KH <gregkh@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  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

  reply	other threads:[~2013-08-09  8:14 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-24 14:02 [gentoo-dev] Vanilla sources stabilization policy change Mike Pagano
2013-07-24 17:37 ` Peter Stuge
2013-07-24 17:43   ` Alex Xu
2013-07-24 17:46     ` Rich Freeman
2013-07-24 17:54       ` Peter Stuge
2013-07-24 18:25         ` Rich Freeman
2013-07-24 19:01           ` Peter Stuge
2013-07-24 19:10             ` Ben Kohler
2013-07-24 19:15               ` Peter Stuge
2013-07-24 20:40                 ` Tom Wijsman
2013-07-24 20:40                 ` Rich Freeman
2013-07-24 20:45                   ` Ciaran McCreesh
2013-07-24 23:09                   ` Greg KH
2013-07-25  1:42                     ` Rich Freeman
2013-08-07  9:37                     ` Tom Wijsman
2013-08-07 22:44                       ` Greg KH
2013-08-07 22:50                         ` Peter Stuge
2013-08-07 23:19                           ` Greg KH
2013-08-08  2:43                             ` Tom Wijsman
2013-08-08 22:29                               ` Greg KH
2013-08-09  8:10                                 ` Tom Wijsman [this message]
2013-08-08 23:44                             ` Peter Stuge
2013-08-09  8:23                               ` Tom Wijsman
2013-08-08  2:37                         ` Tom Wijsman
2013-08-08 22:32                           ` Greg KH
2013-08-09  8:34                             ` Tom Wijsman
2013-08-09 10:38                               ` Rich Freeman
2013-08-09 13:28                                 ` Tom Wijsman
2013-08-09 19:27                                   ` Greg KH
2013-08-09 19:30                               ` Greg KH
2013-08-09 19:46                                 ` Tom Wijsman
2013-08-09 19:57                                   ` Greg KH
2013-07-24 20:22             ` Tom Wijsman
2013-07-24 20:06         ` Tom Wijsman
2013-07-24 17:49     ` Peter Stuge
2013-07-24 17:58       ` Alex Xu
2013-07-24 18:16         ` Peter Stuge
2013-07-24 20:59           ` Tom Wijsman
2013-07-24 22:17             ` Markos Chandras
2013-08-07  9:47               ` Tom Wijsman
2013-07-27  8:02           ` Sergey Popov
2013-07-27  8:56 ` Chí-Thanh Christopher Nguyễn
2013-07-27 13:28   ` Alexander Berntsen
2013-07-27 13:32     ` Manuel Rüger
2013-07-29 21:45       ` Alexander Berntsen
2013-08-07  9:58       ` Tom Wijsman
2013-07-27 18:20     ` Chí-Thanh Christopher Nguyễn
2013-07-27 13:58   ` Rich Freeman
2013-07-27 18:55     ` Mike Pagano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130809101023.6618a356@TOMWIJ-GENTOO \
    --to=tomwij@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    --cc=gregkh@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox