Re: easy alsa patches for the stable kernel?

On 08.09.2007 01:38, Takashi Iwai wrote:
At Fri, 07 Sep 2007 21:42:36 +0200,
Thorsten Leemhuis wrote:
[...]
Sorry, but why?
It's just this line afaics...
+ SND_PCI_QUIRK(0x1179, 0xff50, "TOSHIBA A305", ALC268_TOSHIBA),
...which afaics is doing nothing more then "if DMI-Data matches FOO then
apply know workaround BAR". Is that correct or am I missing something
here (another patch that this one depends on that isn't in 2.6.23 yet
maybe?)?
The patch is based on the workaround codes that have been added after
2.6.23. Thus the patch cannot work for 2.6.23 or earlier.

Yeah, that's why I said: you are in the best position to route patches
to stable and why I didn't send the patch for my particular problem to
the stable maintainers myself. ;-)

But there are now and then patches that just take care of applying
already known workarounds on specific machines automatically by adding
the proper DMI informations; here are some from 2.6.23 which might IMHO
would be of interest for 2.6.22.x as well:
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8f41b56645f03e6f50407211d6f0f0627ae95e4e
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=febe3375ea690a6cf544c33fa0fea1a06ff451ee
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8481da5a8d009d9bbac3d1483b579940e6dd9d59
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f8f794ab27dd3c6d9965ec5434775ead23d3d7a2
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ef64adbbba1b215e8b523b50ef9d568b4bf2e1e3
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7d87de2db2213e6e9413532445b14c92dae42c85

The problem is often that I
want first the merge to Linus tree, and then I forget to submit to
stable tree when the merge takes long time in the end. (Ther merge of
alsa.git is too spotty, and that's another big problem for me. In
short, I do NOT maintain alsa.git tree at all...)
Then I as one of all those long-time-lkml-lurkers without programming
skills dare to say that maybe the alsa-project might need to improve its
workflow? Maybe you guys should maintain two git-trees (or multiple
branches in one tree; sorry, I'm not a git expert and not sure what the
correct terms are)?
We do have different branches, too. Most fix patches are usually in
the branch to be pushed (although they are rarely done).

Well, the latter is IMHO one problem.

But, the point is that I am no official subsystem maintainer.

Well, I suppose he reads LKML now and then as well?

I have an access right to add the patches to ALSA HG tree, which is
converted to git tree automatically. So, eventually, 90% of patches
come from me. But, the maintenance of git tree and push request are
out of my hand. It's a frustrating situation to me, too.

Yeah, I can feel your pain.

some will just say "linux sucks" and switch back to some other OS --
especially if they never have heard of alsa or don't really know what a
kernel really is or does.

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."

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) -- 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.

[...]

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

Relevant Pages

  • Re: [PATCH] delete devfs
    ... been merging patches at a rate of about 10MB/month. ... Andrew would like to see a 2.6 tree which continues to change ... In his vision of the future, the kernel.org kernel will be the most ... keeps the developers happy and gets new code out to users quicker. ...
    (Linux-Kernel)
  • Re: [v4l-dvb-maintainer] [PATCH] media: replace remaining __FUNCT ION__ occurences
    ... I have merged the remaining pending patches into a mercurial tree, ... such a patch, I will try to get to it this week. ... codingstyle / whitespace cleanup, it should appear in a separate patch, ...
    (Linux-Kernel)
  • 2.6.17-mm4
    ... The RAID patches have been dropped due to testing failures in -mm3. ... The SCSI Attached Storage tree has been restored. ... See the `hot-fixes' directory for any important updates to this patchset. ... Fix reject due to git-agpgart.patch. ...
    (Linux-Kernel)
  • 32bit mce unification (Re: Re-implement MCE log ring buffer as per-CPU ring buffer II)
    ... Could you come up with a tree we can look at? ... This currently includes the two error injection patches as last (used ... Some are broken and some following patches from Andi are ... When the feature is removed from the kernel, ...
    (Linux-Kernel)
  • Re: If you want me to quit I will quit
    ... Why do other people get over 100 checkpatch fixes into the tree at once ... or Linus applies patches directly bypassing the maintainers (like the ... And Linus didn't even bother to answer what the correct path for my ... cannot be even reached, according to MAINTAINERS: ...
    (Linux-Kernel)