-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 He pillado de rondón este correo, que me ha parecido muy interesante, sobre lo que se hace o puede hacer para actualizar el kernel entre versiones, porqué no es conveniente, y porqué es mejor preparar actualizaciones de drivers en su lugar. Viene a raiz de que Greg comenta que le gustaría actualizar el kernel con más frecuencia que entre versiones cada 6 o 9 meses. - -- Saludos Carlos E.R. - ---------- Forwarded message ---------- Date: Sat, 04 Oct 2008 10:33:35 +0200 From: Susanne Oberhauser <...@novell.com> To: opensuse Subject: Re: [opensuse] Release schedule change? "Greg Freemyer" <> writes:

On 10/3/08, John Andersen <> wrote:

...

Greg Freemyer wrote:

...

I was just looking at an email from Novell and saw:

openSUSE 11.1 (currently in development, to be released December 2008)

I thought the current release schedule was every 8 or 9 months. Has Novell gone back to every 6 month?

I hope so.

I would rather have good solid releases than frequent and broken releases.

A new kernel comes out roughly every 2 months. I don't like running a vanilla, nor a factory kernel. So it is annoying sometimes to have to wait 8+ months to get the latest kernel feature you may want. ie. The wireless driver someone just asked about.

well, there's two alternatives: either you rev the kernel, which, optional or not means the slight risk of regressions for those who try it (and a significant retesting effort to ensure regressions are caught in testing, not in release ) OR you figure how to provide the latest drivers or hardware related subsystems to just those who need it: http://www.linux-foundation.org/en/Driver_Backport The basic idea is that for a specific product (a laptop model, a chipset model) you 'freeze' the current driver. Then you collect all these frozen drivers into one repository, create a driver update disk if needed and make sure you can easily make an ISO of the repo. You also make the DUD and the ISO to the online repo, so that if these media are used, the online update repo is already registered. This whole bundle is called a 'driver kit' for that hardware. Why does this make more sense than rev'ing the kernel? Various reasons: Most driver updates are for new chipsets anyway, not for driver bugs. If there is a driver bug it usually only hits specific chipset revisions. So driver kits allow you to focus the retesting effort. Next, reving the kernel will also update sysfs and other system management related subsystems. That means hal and the sys mgmt toolchain may need revisions. In many cases that gives you half a system update anyway, and all of that needs to be tested for regressions... And the kernel obviously also brings plenty of driver updates that also bear the risk of regressions (e1000e toast, to name a recent one). We (as in SUSE) have worked long on the infrastructure and what's needed behind the scenes for driver kits, our friends at canonical and redhat are implementing the last step for a cozy user experience, an infrastructure to find and register the right driver kits automatically (Jockey and a driver database). Now why is this going so slow? Because there's some speculations and FUD on why this 'is bad for the kernel' or 'bad for the community' I believe, to the contrary, that a end user friendly and tester friendly solution ot this hardware enablement problem will be a Real Good thing for Linux. The drivers needs to be upstream, too anyway, to have it included in the next distribution releases. S. - -- Susanne Oberhauser +49-911-......... SUSE -- a Novell Business OPS Engineering Maxfeldstraße 5 Processes and Infrastructure Nürnberg SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) - -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjnSpEACgkQtTMYHG2NR9UvzwCeIzN+cXIXClSm/F2V3hilmdC5 2kMAoJE/nTHMTVXLHCZDughWDXrcer0D =dP6t -----END PGP SIGNATURE-----