2008/1/9, Jesse Keating <jkeating@xxxxxxxxxx>: > On Wed, 09 Jan 2008 22:18:25 +0100 > Thorsten Leemhuis <fedora@xxxxxxxxxxxxx> wrote: > And if we had chosen that, it likely still wouldn't be where it is > today, because it wouldn't have had the exposure. It was functional > for the vast majority of uses and the exposure got more and more things > fixed on it. If there was an alternative then everybody would just > switch back to the old method, and no bugs would get filed and no > corner cases would get discovered. Then we might have a fallback method for people that want to test firewire. Because if it does not work for some userland apps, then people will just escape.(to RHEL based or others). If we really want to have valuable testers for firewire, I think they have to be taken with care. For now i'm building a own kmod-ieee1394 but it is not interesting to have it build that way... instead of within the kernel. then providing a compat-libraw1394 (without juju support) with the appropriate blacklisting for kernel modules, and that's would be all... See experiments here: http://kwizart.free.fr/fedora/testing/8/SRPMS/ I do think the firewire problem is different from others. Nicolas (kwizart) > > -- > Jesse Keating > Fedora -- All my bits are free, are yours? > > -- > fedora-devel-list mailing list > fedora-devel-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
