On Mon, May 24, 2004 at 11:15:41AM +0200, Christoph Hellwig wrote: > On Mon, May 24, 2004 at 10:57:37AM +0200, Sven Luther wrote: > > Well, it is a module, if you don't like it, don't use it. It has no > > impact on anyone not having such file systems, but for those who have, > > it provides a service that is quite important for them, and would be > > missing if it were not there. > > But having it as part of the debian kernel package means it should > follow certain quality guidelines. If a _feature_ is not upstream > it should be in a kernel-patch-* package specific to it. In fact > as you said it's a module so it wouldn't even need to be a patch > but could easily built out of tree if we had the nessecary > infrastructure (the BTS has a bug open for that, I don't remember the > #)
Don't be ridicoulous. Out of tree modules should be avoided if possible, not created artificially. 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. > > Again, i, as the pegasos upstream and the > > powerpc kernel maintainer, take the responsability for this, so i > > believe it is ok for inclusion in the debian powerpc kernel package. I > > 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. 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, ... > > > Given that everyone extremly dislikes the single source package scheme > > > I think I'll give up the fight on this one. Following Jens' suggestion > > > I'd at least keep a common CVS repository of patches though, even if > > > > Please make it a subversion one at least. CVS is quite outdated, and has > > very low fleibility in moving files around, which we will probably be > > doing a lot. The ideal way of handling that would be to open a alioth > > project for the kernel, and have space there for every kernel packager > > (and third party module packager) to store their stuff in a common > > (subversion) repository. Works pretty well for many other debian > > projects. I still prefer the easier to use subversion over the more > > obscure arch though, but i would abide with the decision of the other > > users. > > I couldn't really care less whether it's SVN or CVS for myself as > long as I don't have to run a POS like apache+mod_svn on my systems. Then go with subversion. The infrastructure for it is already in alioth, and it has been used with success by other debian teams. Arch would be even better, but it is more heavy to use, and thus brings other problems with it. Now, if there was a bitkeeper to arch gateway, i would reconsider. > > Yes, i agree with that, altough i somewhat disagree with your way of > > clasifying the patches. I think it is a good thing to have one or more > > patches in a arch specific patch, be it for localized testing before a > > wider usage, or because the patch, in despite of not being arch specific > > is of restricted use outside that arch. > > Any difference of sources between architectures is a maintaince pain. Sure, but on the other hand, it brings greater independence and flexibility, so you have to see what is more important. > How do you explain people syscall foo works strange on architecture one > but not architecture 2 because of strange patches? Well, this is not the case on powerpc, so ... > 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. 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 ? Because most x86 users use mostly proprietary drivers to achieve the same thing ? Because there is no other arch which does notebook today ? 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 :). In the meantime we get active user feedback on the driver, which is rather a positive thing. > Why is asfs part of the ppc kernel but not other > so I can't read the amiga disks on my PC? Will you do this ? If so, you are welcome to port said driver. Beware though, it has never been tested on little endian boxes. But then again, same reasoning as above apply. Friendly, Sven Luther
