Re: Hardware compatibility test: draft proposal
Giacomo A. Catenazzi wrote:
> Wouter Verhelst wrote:
>> On Fri, Aug 22, 2008 at 12:55:34PM +0200, Giacomo Catenazzi wrote:
>>> Wouter Verhelst wrote:
>>> I'm not so sure that the test should be packages.
>>> The system is too different on early boot from a Debian system.
>>
>> In what way? Note that a Debian Live system *is* a normal Debian system;
>> you build a Debian Live image by giving the debian-live script a bunch
>> of packages; it then installs them into a chroot, changes a few things
>> so that the system will actually boot from CD-ROM, and then create an
>> ISO image from it.
>>
>> How is that "too different" from a Debian system? Or are you talking
>> about something else?
ok. I was thinking about doing hardware test a lot earlier
(i.e. in initramfs).
But probably it is not really needed, and we probably could assume
that system is enough reasonable.
Anyway, we can try with debian-live, and ev. move things
earlier.
>>> The "modular" thing should be put mainly on the testing
>>> development side.
>>
>> Yeah, I'm not suggesting we provide vendors with a bunch of packages;
>> the packages thing is a way for us to make it easier to actually develop
>> this without having one maintainer who has to write/accept/maintain
>> *all* the tests in the system. But hey, this is debian-devel, not
>> debian-announce ;-)
>>
>>>> - Vendors who pass this test on a particular bit of hardware are
>>>> allowed
>>>> to advertise that fact; it might be nice to have provide them with a
>>>> logo that they may use for this purpose.
>>> This should be discussed after we have comprehensive tests,
>>
>> Sure.
>>
>>> and probably to LI. I don't want to see packages with logo of 10
>>> distributions.
>>
>> To me, it's not about seeing a logo on a package. It's about seeing
>> another vendor besides HP make a commitment that "Yes, Debian will be
>> supported. We won't run away scared to the hills if you say that you're
>> running Debian." Because that's what most vendors will do currently.
>>
>> I think you'll also find aving a generic "Linux" hardware compatibility
>> test isn't very useful; if we provide hardware vendors with such a
>> thing, they'll go "I ran that test, and it said 'pass'; but my
>> shiny-new-network-card-chipset-that's-supported-in-the-latest-development-kernel-only
>>
>> isn't supported in Debian? That's probably a bug in Debian, then".
>>
>> And it doesn't even have to be "too new" stuff; it may also be that some
>> particular bit of hardware is supported by some free out-of-tree driver
>> which is supported by some distributions, but not necessarily by all of
>> them. Would you test for that in a generic "Linux" compatibility test?
>> If you don't, you'll fail on an amount of hardware that works perfectly
>> well in most distributions; and if you do, you'll succeed on hardware
>> that won't be supported by a number of distributions, possibly the one
>> the hardware vendor cares about most (because, say, they use it
>> themselves for their webservers).
>>
>> No, I think we *do* need a Debian-specific test.
The LinuxFirmwareKit has few kernels. IIRC redhat, suse and
latest vanilla, so vendors could check the support of various
distributions.
I think we could be done in the same way: we allow installing/selecting
other kernels. The tests are the same, only the kernel could change,
and "obviously, the default kernel is the Debian stable kernel.
In this manner, vendor could test new-hardware with requires new-kernel
but on other side, vendors have information about Debian kernel, so they
could ev. try to backport drivers for us.
I think doing it Debian specific is more difficult, because it
requires a lot more work.
we should share some burden to upstreams (I'm thinking mainly about
xorg: test about 2D, 3D accelerations, etc.; i2c, etc.).
ciao
cate
Reply to: