Re: [wli@holomorphy.com: Re: NMU: kernel]
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?
Reply to: