Hi Lukas TL;DR for your questions: - yes we need the seeded-in-ubuntu statement, but wording might be improved - It is ok to be superficial (or even not) tested if shown to be reasonably covered elsewhere
--- Details --- > #0 "seeded-in-ubuntu" policy: Why could this be a problem It is the inverse, the only place it is listed is when checking further dependencies. ``` TODO: - no other Dependencies to MIR due to this TODO: - checked with check-mir TODO: - not listed in seeded-in-ubuntu TODO: - none of the (potentially auto-generated) dependencies (Depends TODO: and Recommends) that are present after build are not in main ``` That check is meant to detect the following situation early on. Package `foo` shows as component mismatch and is processed. Then much later once all completed `foo` is promoted and then it shows up as additional component mismatch because `foo` depends on `bar` which also needs to be promoted. The check here is meant to spot "hey you need to file and process `bar` as well" early on to avoid late surprises. > #2 testing/qa requirements: Should we accept a single "superficial" autopkgtest as sufficient [...] ? We tried to prepare for this with recent rule changes. As you say sometimes there can only be done "so much" at the lib level (more a unittest than an actual workload). The following sections are related: ``` RULE: - If no build tests nor autopkgtests are included, and/or if the package RULE: requires specific hardware to perform testing, the subscribed team RULE: must provide a written test plan in a comment to the MIR bug, and RULE: commit to running that test either at each upload of the package or RULE: at least once each release cycle. In the comment to the MIR bug, RULE: please link to the codebase of these tests (scripts or doc of manual RULE: steps) and attach a full log of these test runs. This is meant to RULE: assess their validity (e.g. not just superficial) TODO: - The package can not be tested at build or autopktest time because TBD TODO: to make up for that here TBD is a test plan/automation and example TODO: test TBD (logs/scripts) RULE: - In some cases a solution that is about to be promoted consists of RULE: several very small libraries and one actual application uniting them RULE: to achieve something useful. This is rather common in the go/rust space. RULE: In that case often these micro-libs on their own can and should only RULE: provide low level unit-tests. But more complex autopkgtests make no RULE: sense on that level. Therefore in those cases one might want to test on RULE: the solution level. RULE: - Process wise MIR-requesting teams can ask (on the bug) for this RULE: special case to apply for a given case, which reduces the test RULE: constraints on the micro libraries but in return increases the RULE: requirements for the test of the actual app/solution. RULE: - Since this might promote micro-lib packages to main with less than RULE: the common level of QA any further MIRed program using them will have RULE: to provide the same amount of increased testing. TODO: - This package is minimal and will be tested in a more wide reaching TODO: solution context TBD, details about this testing are here TBD ... TODO: - does have a test suite that runs at build time TODO: - test suite fails will fail the build upon error. TODO: - does have a non-trivial test suite that runs as autopkgtest TODO: - if special HW does prevent build/autopkgtest is there a test plan, code, TODO: log provided? TODO: - if a non-trivial test on this level does not make sense (the lib alone TODO: is only doing rather simple things), is the overall solution (app+libs) TODO: extensively covered i.e. via end to end autopkgtest ? ``` It has to be a case by case decision. For example strictly speaking DPDK is a library, but extended tests make sense. Another lib does nothing but escaping URLs, that might be tested at a higher level. The sections above were added a while ago to make this clear. Combined they allow: - If testing at the lib makes no sense to state so and kind of "be allowed to be promoted without adding an odd test" - but at the same time by being forced to state by what it is covered instead, we ensure that it covered somewhere (otherwise lib would say need to be tested above; and above doesn't care => no test) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1973784 Title: [MIR] libldac To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libldac/+bug/1973784/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
