Re: [wli@holomorphy.com: Re: NMU: kernel]
On Mon, May 24, 2004 at 04:45:39PM +0200, Sven Luther wrote:
> > magically belongs into kernel-image- for a single architecture.
>
> Ah, but it is particularly those that complain about not cleanly
> applicating patches, and i would say they have less priority than per
> port patches and it is their responsability they build on top of the per
> port patches.
I agree with the pririty thing. But that doesn't mean we shouldn't
do everything reasonable to avoid breaking them. And avoiding per-port
source differences where easily possible is more than just reasonable,
in fact I'd call it stupid to not do it.
> > So make that kernel-patch- ppc-only for the time beeing and ask for
> > testers. Or just send an anncouncement for damn fs to lkml and -fsdevel
>
> I don't read lkml anymore, i even erased my archive, once i noticed that
> mutt was not anymore able to handle it.
>
> And how about ppc-only should it be ?
Either mark it Architecture: powerpc or add a debconf note that the
patch is completely untested on anything but ppc.
> Any different than the ppc patch we have now ?
It wouldn't be in the default kernel-image.
> About the announcement, that would be the responsability
> of the author of the patch, no ?
Usually yes. Not that there are any clear rules..
> > Exactly. And the best way to make sure it works is to not keep the
> > amount of source differences very very low. e.g. asfs suddenly
> > breaks any new filesystem that adds to fs/Makefile or fs/Kconfig in
> > the matching area. But strangely only on powerpc while for all other
> > architectures it'll apply. With your attitude of I include what I
> > want, not what's ppc-specifc you cause maintaince pain for other
> > people's packages.
>
> Well, you have it the wrong way around. If a random filesystem is added
> to the kernel-source, it will break the powerpc patch, and i will fix
> it. Now if a random third party filesystem is broken on powerpc, too bad
> for them, and i don't see how the situation is any different than having
> a kernel-patch-sfs and a kernel-patch-randomfs conflicting with each
> other.
It's completely stupid to have the sources on different architectures
differing, while for patch to conflict it's a just a fact of life that
happens.
Having features patches applied and not platform-depend fatures on only
one architecture completely defeats the idea of a portable operating
system
> Well, i believe that what should be in a debian kernel, and more to the
> point a debian per-arch kernel, is different than what should be in the
> mainstream kernel archives.
Of course there's a difference, mostly due to different release cycles.
But that really applies to fixes only and not to new features.
> > Buy one that doesn't. At least intel and prism54 have sane free
> > drivers. For now the 11Mbit net is enough for me anyway, but that
> > starts to get really offtopic.
>
> And do they come in ibook/G4 airport format ?
No, that format is apple-propritary. They either come as cardbus cards
for which no ibook has slots or usb devices which can be used on an
ibook.
But I'm completely lost on how this relates to the discussion.
> > I'm not sure why these should be different from 'official' patches.
>
> Well, the per arch patches should be the responsability of the per arch
> maintainer, which let's him react to the per arch bug reports in a
> quicker way, thus gaining flexibility and quickness to respond, and
> later be moved to the official debian pacthes, which are those that are
> in the kernel-source package, if it is felt appropriate.
No. Again, architecture-dependand sources files are under completele
control of the arch-maintainer anyway, common patch repository or not.
And for architecture-independent source files the arch maintainer is
much better server by getting feedback from someone who is knowledgeable
in that area. If you don't get feedback in say 24 hours you can still
commit it as a patch marked to be only for your architecture.
Code review can never hurt, lack of code review hurts very often.
> > Of per-arch patches those who don't touch other architectures' code
> > (arch/$ARCH, include/asm-$ARCH, per-arch drivers) can go into the
> > generic code, checked in by the arch maintainer without needing to
>
> A, sure, but the difference is that if let's say i am experimenting a
> patch for some obscure subarch, and i don't really have a control over
> who will test it or not, i could be bringed to do many new uploads to
> debian/unstable of small changes, and once they stabilize, they go into
> the kernel-source package or whatever.
You can test a kernel package even without an upload to the archive, and
if you're experiemting around that shouldn't be done anyway. Just
create a branch in SVN for it and when you're done with experimenting
merge it back to trunk after review. In fact with the model of common
patch repository but differen source packages you could even do a
release to unstable from that branch. I'd just hate to see any of those
branch releases getting into stable, because that's exactly the
situation we and security team want to avoid.
> > discuss them. All per-arch patches that do not fall into that category
> > should be discussed on debian-kernel and either they are safe enough
> > to be applied all the time or they'll be applied only for the arch
> > at the end of the patchkit.
>
> Thus adding an additional layer of bureaucracy on top of a perfectly
> working system. Let's just add them to the per arch patch, and then
> discuss them with an existing example. Once it is discussed, it can be
> moved out again, or whatever, but in the meantime, the user get to
> benefit from the patch, and test it.
So public discussion and review of patches if bureaucracy for you? I
tend to very strongly disagree, it's absolutely nessecary for high
quality software.
Reply to: