public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Adrian Bunk <bunk@kernel.org>
To: ciol <ciol13@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [poll] Is the megafreeze development model broken?
Date: Thu, 8 Nov 2007 02:36:05 +0100	[thread overview]
Message-ID: <20071108013605.GD26163@stusta.de> (raw)
In-Reply-To: <fgtfqa$h9j$1@ger.gmane.org>

On Wed, Nov 07, 2007 at 11:56:57PM +0100, ciol wrote:
> Hi, I'd like to ask you a few questions:
>
> * Do you like the way linux distributions integrate the kernel?
>
> * Wouldn't you prefer they ship with the stable and still maintained 
> 2.6.16.X, while providing optionally the latest kernel for those who want 
> or just have a new hardware?

No.

With 2.6.16 "new hardware" roughly equals to "sold during the
last 2-3 years", so most users would be forced to use this "option".

"providing optionally the latest kernel" would be a horror to support 
for a distribution.

>From all I hear all big distributions spend 3-6 months of QA work 
between pushing a kernel into the development branch of their 
distribution and putting it into a release.

They can't do this work for 4-6 different upstream kernels each year.

And if they'd omit it, their custumers would both blame them for 
shipping such a buggy distribution and swamp their support with bug
reports.

> * Do you think the megafreeze development model [1] and the "I don't trust 
> in upstream" development model are broken? (And why)
>...

Definitely not.

If your "stable base system" contains the kernel you lose the hardware 
support for recent hardware.

What should be more important for users than having their hardware 
supported?

And although it's off-topic for linux-kernel, your suggested 
"well-maintained additional package collections" also sound horrific:

As an example, consider the following:
- a new version of GNOME might require a new version of GTK+
- recently GTK+ 2.12 entered Debian testing, and this new version
  exposed a serious bug in the xfwm4 package that was at that time
  in testing

There are at least two obvious problems with what you propose:
- for avoiding breakages for users a huge amount of coordination
  work between the "additional package collections" would be required
- most users want their software to work correctly, not crash, etc.
  when a distribution has a 2-3 months freeze before a release that's 
  not lost time, that's time where _all_ software that will be shipped 
  gets tested and bugs fixed

There's one important thing you must have in mind:
Geeks (like you and me) can get the latest software versions from the 
development versions of their distribution, but for most users - for 
whom a computer is a tool that should simply work (no matter whether 
it's a server or a desktop) and not a toy - the QA work done during a 
freeze has a _huge_ value.

Fedora, openSUSE and Ubuntu all offer new releases every 6 months, which 
results in the software in the latest release always being less than
1 year old plus the user getting the QA work and the resulting stability 
of a freeze. This seems to be a good solution for desktop user.

cu
Adrian (2.6.16 maintainer)

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


  parent reply	other threads:[~2007-11-08  1:36 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-07 22:56 [poll] Is the megafreeze development model broken? ciol
2007-11-07 23:06 ` Rik van Riel
2007-11-07 23:11   ` ciol
2007-11-08  1:36 ` Adrian Bunk [this message]
2007-11-08 20:45   ` ciol
2007-11-08  6:18 ` Stephen Hemminger
2007-11-08 13:38 ` David Newall
2007-11-08 14:26 ` Chris Snook
2007-11-08 20:41   ` ciol
2007-11-09  0:15     ` Chris Snook
2007-11-12 11:09 ` Eric W. Biederman
2007-11-12 13:51   ` Tuomo Valkonen
2007-11-12 15:20     ` Adrian Bunk
2007-11-12 16:02       ` Tuomo Valkonen
2007-11-12 16:56         ` Adrian Bunk
2007-11-12 17:16           ` Tuomo Valkonen
2007-11-12 17:34             ` Adrian Bunk
2007-11-12 17:42               ` Tuomo Valkonen
2007-11-13 10:11                 ` David Newall
2007-11-12 17:37         ` Rogelio M. Serrano Jr.
2007-11-12 17:53           ` Tuomo Valkonen
2007-11-13 12:28             ` Radoslaw Szkodzinski
2007-11-13 13:09               ` Tuomo Valkonen
2007-11-12 16:13       ` Rogelio M. Serrano Jr.
2007-11-12 17:14         ` Adrian Bunk
2007-11-12 17:18           ` Tuomo Valkonen
2007-11-12 23:39             ` Matthias Schniedermeyer
2007-11-13  0:12               ` Tuomo Valkonen
2007-11-12 17:30           ` david
2007-11-12 18:25           ` Rogelio M. Serrano Jr.

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=20071108013605.GD26163@stusta.de \
    --to=bunk@kernel.org \
    --cc=ciol13@gmail.com \
    --cc=linux-kernel@vger.kernel.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