Hi Mariusz,
Thanks for your work at fixing all this code. I'm wondering though,
given the type of errors, this code should never have been able to
build at all, so that means that it might not be used at all.
As a general rule of thumb, keep in mind that we're not much tempted
to fix known unused code, especially if it's unmaintained. The reason
is simple : when some code does not work, people who need it often
maintain patches in their tree to make it work. When we start changing
things there, their patches often apply with rejects. Anyway, *I* am
still for a clean kernel because I know that there's nothing more
annoying than spending days chasing a bug which we discover was known
for years.
So what I can propose you is that we :
- postpone those patches for 2.4.35-pre
- ask maintainers of each of these files if he accepts to fix the
file, because some of them are totally against any such change.
- we would merge the accepted patches and those without any reply
which we consider relevant early in the 35-pre cycle so that
people have some time to inform us about the potential conflicts
they encounter.
Quite frankly, there should be very few problems, considering that we
have affected more files with the gcc4 patches and that nobody
complained.
As an exception, if you get some maintainer's approval for some of
the patches during 2.4.34 cycle, of course I will merge them first
because as I said, it's important to maintain supported code in good
shape.
Is it OK for you ?
Regards,
Willy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
