> I need to redo next 7 patches because your update :-(
> My fault, I should be faster.
You should be _timely_.
The big patches also means that it is damn painful for me to merge your
patches. In fact, of _all_ the subsystems in the whole kernel, right now
the ALSA code is absolutely the worst by a big marging when it comes to
And your changeset names are just dates, for chrissake!
Please, fix this up. Your CVS tree means that nobody else can comment
sanely on the changes, it makes _your_ merges harder (not just mine), and
we've several times lost real work that went into the standard tree
because of that.
Right now some audio drivers don't compile, apparently because their
makefiles are broken etc etc. Getting huge drops with totally unrelated
changes every two months is _not_ acceptable.
Talk to David about the problems with an external CVS tree, he had many of
the same problems with his sparc/networking tree a long time ago. David,
maybe you can talk about how you solved them.
This is worse than the ACPI stuff, which is saying something. The ACPI
tree has actually tried to merge in sane chunks lately, and make a clean
BK tree available (in contrast, your BK patches don't even apply, since
there are missing chunks etc small "details").
There's a strong hint in the fact that the patches are so big that you
can't post them. And that hint says that something is WRONG.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/