lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20071108013605.GD26163@stusta.de>
Date:	Thu, 8 Nov 2007 02:36:05 +0100
From:	Adrian Bunk <bunk@...nel.org>
To:	ciol <ciol13@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [poll] Is the megafreeze development model broken?

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ