mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: Thorsten Leemhuis <fedora@leemhuis.info>
Cc: Takashi Iwai <tiwai@suse.de>,
	Romano Giannetti <romano@dea.icai.upcomillas.es>,
	Andrew Morton <akpm@linux-foundation.org>,
	roger@computer-surgery.co.uk, linux-kernel@vger.kernel.org,
	perex@suse.cz
Subject: Re: easy alsa patches for the stable kernel?
Date: Sat, 08 Sep 2007 19:49:13 +0200	[thread overview]
Message-ID: <46E2E099.9040402@s5r6.in-berlin.de> (raw)
In-Reply-To: <46E24177.7070702@leemhuis.info>

Thorsten Leemhuis wrote:
> On 08.09.2007 01:38, Takashi Iwai wrote:
[backports to -stable]
>> Linux will suck really if one breaks so-called stable thing easily
>> without actually testing.  For stable stuff, "it should be good" isn't
>> enough.  It must be: "it IS good."

This applies (or should apply...) to everything that goes to Linus in
his pre -rc1 merge windows.  To post -rc1 submissions and even more so
to -stable submissions, additional criteria apply.

However, there are special kernel trees out there which accept
backports.  Linux distributors do backports, because they have the means
to do so.

> Linux IMHO will suck even more if crucial pieces of hardware does not
> work for people easily, because Linux won't get even used then and will
> frustrate people.
> 
> Don't get me wrong; I understand and agree mostly to the points you
> raised. But we nevertheless need to find a way to make todays hardware
> usable more quickly, as that hardware is often on the market only for
> some months or a year until the successor-model replaces it (which might
> need new drivers or workarounds) --

In the end there is but one solution to this:  Open specs.

> but it sometimes even for small
> alsa-fixes takes as many months to make it from the developers out to
> the kernel and from there to the distributions the user uses.
> 
> It works better in some areas of the kernels (SATA and Network drivers
> come to my mind) where patches make it quicker into the linus- and
> stable-kernels -- in parts that is due to better cooperation with the
> hardware-vendors, but it seems the sub-tree maintainers have a better
> patch-/workflow, which has a strong impact as well.

Feature additions to SATA and networking, e.g. support of additional
hardware, are not backported to -stable or merged post -rc1 either, I
presume.  Maybe they are better in getting stuff ready in time before
merge windows open --- I don't know, I don't watch these subsystems.
Maybe they have less trouble with closed or nonexisting specs...?
-- 
Stefan Richter
-=====-=-=== =--= -=---
http://arcgraph.de/sr/

  reply	other threads:[~2007-09-08 17:49 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-22 22:29 hda_intel : Patch + Regression in 2.6.18 -> 2.6.22 Roger Gammans
2007-09-05 15:38 ` Andrew Morton
2007-09-05 16:05   ` Takashi Iwai
2007-09-05 16:16     ` Andrew Morton
2007-09-05 16:44       ` Takashi Iwai
2007-09-06 15:09         ` Romano Giannetti
2007-09-06 15:25           ` Takashi Iwai
2007-09-06 21:48             ` Romano Giannetti
2007-09-07  8:22               ` Romano Giannetti
2007-09-07 10:21                 ` Takashi Iwai
2007-09-07 12:04                   ` easy alsa patches for the stable kernel? (was: Re: hda_intel : Patch + Regression in 2.6.18 -> 2.6.22) Thorsten Leemhuis
2007-09-07 12:58                     ` Takashi Iwai
2007-09-07 19:42                       ` easy alsa patches for the stable kernel? Thorsten Leemhuis
2007-09-07 20:59                         ` Romano Giannetti
2007-09-07 23:42                           ` Takashi Iwai
2007-09-10  8:46                             ` Toshiba A305 hda-intel (Was: Re: easy alsa patches for the stablekernel?) Romano Giannetti
2007-09-07 23:38                         ` easy alsa patches for the stable kernel? Takashi Iwai
2007-09-08  6:30                           ` Thorsten Leemhuis
2007-09-08 17:49                             ` Stefan Richter [this message]
2007-09-09 10:45                               ` Thorsten Leemhuis
2007-09-05 16:26     ` hda_intel : Patch + Regression in 2.6.18 -> 2.6.22 Roger Gammans
2007-09-05 16:46       ` Takashi Iwai
2007-09-05 17:01         ` Roger Gammans
2007-09-05 17:18           ` Takashi Iwai

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=46E2E099.9040402@s5r6.in-berlin.de \
    --to=stefanr@s5r6.in-berlin.de \
    --cc=akpm@linux-foundation.org \
    --cc=fedora@leemhuis.info \
    --cc=linux-kernel@vger.kernel.org \
    --cc=perex@suse.cz \
    --cc=roger@computer-surgery.co.uk \
    --cc=romano@dea.icai.upcomillas.es \
    --cc=tiwai@suse.de \
    /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

all inboxes | Powered by JetHome®