On Tue, 2017-05-02 at 23:29 +0530, Ritesh Raj Sarraf wrote: > As members, we should come up with a "Certification Policy" guide. Which > should > define what constitutes a particular machine being marked certified. Then a > testsuite could be built accordingly.
Sounds good to me, would you mind starting a wiki page for this? > It will have to go beyond the "does boot" scope, in my opinion. Clearly, since each bit of hardware in each particular situation has a probably unique set of features that need testing in their own way. For example if there is a USB missile launcher attached, it should definitely use isenkram install pymissile and ask the user to run the tests for that. > Like most other Enterprise Linux Distributions, Debian too picks a > particular kernel (stable- lts) and to some extent also backports > fixes into it. That makes it a completely unique kernel, against > which certification needs to be done. It is true that we use a unique version of Linux/kFreeBSD/Hurd but I would advocate a different approach. There is a lot of hardware that will never run mainline Linux and will never be able to be fully supported by Debian. These systems should be able to be certified to work with Debian but the certification would make it clear which version of each component was used, including those that were not from Debian. For example ARM systems will be able to have OpenGL but only with the proprietary binary drivers. Other systems will be able to run one release of Debian but not another (for example my MIPS router can run jessie but not stretch because the CPU requirements changed). > In all the certification tools I've worked with, rigorous stress > tests are the most important part. For example, for file systems, > doing large amounts of I/O with different chunks; Buffered and Direct > I/O etc. Single queue, multi queue. WRITE_SAME and TRIM related HW > Commands. CPU Burn, Memory tests, Network etc. That sounds like a description of anarcat's stressant project. https://gitlab.com/anarcat/stressant > All core components of a server hardware needs tests to certify any > server hardware. I would strongly suggest *not* limiting this project to servers. There are at least various types of cloud providers, laptops, desktops, SBCs, routers, TVs etc that Debian can probably run on in some way. > Yes. But I think we need to provide a tool, process and guideline for them to > follow. So far, from what I've checked, not much engagement has been initiated > from the hardware vendors. I think instead of a tool, we want a framework for packages available in Debian to provide both automatic and manual instructions for testing things outside of the Debian system. Then we want a setup that can run the automatic tests and provide the manual instructions to the user. The process would then be: boot ISO, wait for auto tests, do manual tests and enter results, click submit, take photo of certification and or save any digital artefacts of the certification to external media. -- bye, pabs https://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
