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