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 #) > 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. > > 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. > 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. How do you explain people syscall foo works strange on architecture one but not architecture 2 because of strange patches? How do you easily make sure new Architecture: all patches don't break a large per-arch patch later? Why does the orinoc driver do snooping on ppc and not others? Why is asfs part of the ppc kernel but not other so I can't read the amiga disks on my PC?