On Mon, May 24, 2004 at 03:14:21PM +0200, Christoph Hellwig wrote: > 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.
For out of tree module writers, yes, but not as debian packages. Not all out of tree modules adapt to 2.6 gracefully, and not all provide a clean way for building with make-kpkg and produce a clean debian package. Just doing make modules_install as root may be easy, but it is _NOT_ the debian way, and should be frowned upon. Furthermore, the user need often to rebuild said modules for his own system, which needs some infrastructure (ideally a full unpacked kernel source, configured for the kernel flavor he uses) to be built. > > 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. So, you can't make presence in the kernel source a guarantee for quality. And i was not speaking only about filesystems, but also about hardware drivers. I also remember some time when HIGHMEM was buggy on power3, or when cpufreq was broken on non pmac powerpc. > > > 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. Huh ? Did i say that ? I believe it is more sure to have them tested on one architecture it is used most, before unleashing it on every unsuspecting architecture, most of them it was never tested on previously. > > 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. Sure, great for you, this hardly frames you as an authority of the per arch case though. > OTOH for people who only care for their little castle made of sand such > work is probably not interesting at all. You are despissing the work of the per arch maintainers again, please scale down your attitude on this. Sure it is interesting, but such work life in its own timeframe, and for the stuff that is actually included in the powerpc patch, which is not all that much, i believe either it is not ready to be pushed into the main kernels, but still usefull for the debian powerpc, or the path to it being included upstream is too lengthy to be worth it. As an anecdote, i have been trying to push my pegasos 1 patches to the -benh tree since almost a year (well, since summer last year), and altough benh said he would look at it, he didn't find time for it, for which i didn't blame him since i also didn't take time to push them through other channels, and as said some of those stuff needs to be cleaned up, but then on the other said, i have mailed the author of the via-ide driver, asking for counsel on how to solve the hack i have there properly, but never got anyresponse from him, so you can't said i am not interested in getting the stuff upstream, just that if you are not _in_, you have maybe a harder time to find the right way to push those changes in. And i would very much welcome counsel on how to do this properly, i was quite disapointed to notice that even if the 2.6 kernel handled IDE channels per channel, it didn't get the right irq for the second channel, nor was there an obvious way of doing it. > 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. See, the new debian kernel maintainer, which means that we who have been doing per port maitnenance are a not worth mentioning. > > > 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. So, what did i say. It is the responsability of the arch maintainer to be compatible with the centralized kernel-source package, but there is no way we will take responsability for compatibility with any random patch not packaged outside the kernel-source package. > > 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. Yeah, which is why second hand ibook G3 800 are a hot item right now. > > 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. See. So, you could take the responsability to test the orinoco patches, and if they also work for you, it would be easy enough to migrate them from the popc package into the kernel-source package. The main problem is one of flexibility and communication. It is way easier to just put it in the powerpc patch at first, and then have it testedi by the debian/unstable users, than to ask for its inclusion in a centralized repository or whatever. This is also the reason the per package maintenance debian has works better for us than let's say a BSD like system. And most modern wifi cards come with binary only drivers. What do you plan to do about this ? > > Because > > there is no other arch which does notebook today ? > > x86_64, alpha? sparc? what about the various mips/arm/sh based > handhelds? x86_64 is x86 still, and doesn't count. And i suppose there are more m68k notebooks out there than alpha/sparc ones. about handhelds, i am not entirely sure these would benefit from the orinioco driver, not sure though. But again, if there is a need, then the driver can be migrated. Ideally i would see the patches organised as follow : -> the official kernel source tree. -> 'official' debian patches. -> per arch port patches. The two latest being maybe dvidied between official and eperimental patches or something such. A subversion repository would make migration of those among these different patch pools quite easy. > > 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.. Well, welcome to the world of non-mainstream users. So, build yourself a kernel with said patch, and if it works, fill a bug report against the kernel-source package to have it included, and another (or the same) against the powerpc kernel package to have it removed. What is so difficult with that ? This is the way debian works, and it has done rather well these past 10 years. > Also there's lots of pci-based orinoc variants sharing the base driver, > see drivers/net/wireless/ for the details. Same as above. > 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. Ah, but the difference is that for one group (or one person of that group) the "need" is enough to be transformed in action, that is actually including the driver in the powerpc kernel patch, while for the whole group of others it was not even worth it providing a bug report. This is how it works in the free/open/whatever world, those who really need something do the job, and it happens, for those who can't get bothered, they can only hope someone else will do it. Friendly, Sven Luther >
