Re: [wli@holomorphy.com: Re: NMU: kernel]
On Mon, May 24, 2004 at 03:01:19PM +0200, Sven Luther wrote:
> Don't be ridicoulous. Out of tree modules should be avoided if possible,
> not created artificially.
Huh? Out of tree modules are a _lot_ easier to deal with than a kernel
patch.
> Also, I guess even if it is of dubious quality, i guess it is of better
> quality than some of the driver actually present in the tre, some of
> them don't even build.
There's a bunch of legacy filesystems that are indeed buggy and haven't
been updated. I wouldn't compile those into a kernel for any
architecture, though.
> > You abuse your position as powerpc kernel maintainer to get your
> > pet patches in without proper review.
>
> Bah, you have to check the history of it. Before i took over the powerpc
> packages, almost nobody used the official kernel for powerpc, all used
> self built kernels from the -benh tree. The kernel packages only
> supported powermacs, and totaly ignored all other subarches. This is a
> module _I_ need on my powerpc architecture, _I_ take the responsability
> for in case of breakage, and _I_ do the job to get the stuff packaged.
> (Well, wiuth Jens recently, but at the start it was just me). The
> powerpc kernel guys didn't even do proper tagging of their corresponding
> bitkeeper tree.
The statement above was in reference to the orinoco and asfs patches. I
see it hard to arue you need them to install, and afterwards you'd be
much better served with a kernel-patch- patckage for either patch that
you can maintain, and people can apply on all architectures if they feel
interested in it.
> And, sorry, but this is the way thing work in debian, it is the
> maintainer who decide what should (or should not) be in the package, and
> he is the ultimate authority on this, and now you come out of nowhere,
> and want to give leasons on how i should do the work, sorry, but that is
> not going to work. And upto now, i have seen no evidence whatsoever that
> you did more than speak about this stuff anyway, so you are in a rather
> bad place for giving leasons, ...
I've made sure that about 80% changes in kernel-patch-debian are
reviewed by the upstream maintainers and in most cases included now.
OTOH for people who only care for their little castle made of sand such
work is probably not interesting at all.
Besides that I have worked on kernel maintaince for a comercial
distributor in the past, am very active upstream contributor, and have
worked with all kinds of people (including distribution vendors,
volunteers, hardware companies, etc..) to get their changes up to
standards and included upstream. I certainly know what I'm talking
about and to help the new debian kernel maintainer with that experience.
> > How do you easily make sure new Architecture: all patches don't break
> > a large per-arch patch later?
>
> Well, you don't, there is actually no easy way to do this, even if you
> have a centralized design. I guess it is the responsability of the new
> arch: all patch to make sure it doesn't conflict with the different per
> arch patches, as it is the responsability of the per arch patch to make
> sure it doesn't conflict with changes of the kernel-source package.
Umm, no. If the per-arch patches are small and everything remotely
possible is in the common tree it's easy to check for breakage in
the arch patches. If not it'll randomly break and no one will care.
>
>
> I can assure you that the user feedback and BTS provide for almost
> immediate notice when such a port package break, and the patch
> maintainer fies the problem, no big issue there.
>
> This is how debian works, things go into unstable (or eperimental) and
> get tested. If they break, people notice, do a bug report, and it gets
> fixed.
>
> > Why does the orinoc driver do snooping on ppc and not others?
>
> because the main wifi card on ppc happen to be the airport card and it
> is widely used and people need the snooping support ?
define "need". Besides that there's no more ppc notebook in production
using the linux-supported, orinoco-based airport card.
> Because most x86
> users use mostly proprietary drivers to achieve the same thing ?
Huh? I use exactly the same orinoc drivers on ppc and x86, usually
just upstream but when I need snooping I know where to look for the
patches.
> Because
> there is no other arch which does notebook today ?
x86_64, alpha? sparc? what about the various mips/arm/sh based
handhelds?
> And also, this is not so much a problem than a feature. It is small
> scale testing before full scale deployement. If it works well on ppc,
> and some users say, hey we want this also on x86, they adapt the patch,
> or ask the kernel maintainers to do it, and voila, it is available also
> on x86 or even all arches (altough i doubt you will go out and snoop
> wifi stuff with your sun workstation :).
but with my tadpole sparcbook if it's pcmcia driver was supported..
Also there's lots of pci-based orinoc variants sharing the base driver,
see drivers/net/wireless/ for the details.
Anyway, your counter-arguing your above statement here. only for those
people actually using orinoco the patch has any affect, and of those
it's unlikely one group "needs" it more than the others.
Reply to: