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/
next prev parent 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®