** Description changed: - This is a work in progress. + [Availability] + The package thin-provisioning-tools is already in Ubuntu main as per LP: #1828887. this is a "soft MIR request" so this package gets a re-review since it was completely re-written in rust. + The package thin-provisioning-tools build for the architectures it is designed to work on. + It currently builds and works for architectures: amd64 arm64 armhf ppc64el riscv64 s390x + TODO: The former version of the package also built for i386 + Link to package https://launchpad.net/ubuntu/+source/thin-provisioning-tools - Note that this was already included in main as per LP: #1828887. - This is a "soft MIR request" so this package gets a re-review since it was completely re-written in rust. + [Rationale] + The package is already in main. This is a re-review request to ensure the rust version is in a good shape to be maintained in main. For further information, see the Rationale section from the previous MIR in LP: #1828887. + + There is no specific deadline for accepting this MIR proposal. We should + not upload the new package to devel until this is accepted. + + [Security] + - No CVEs/security issues in this software in the past (Ubuntu and Debian CVE trackers are empty and query for "site:www.openwall.com/lists/oss-security thin-provisioning-tools" is empty as well). + + - no `suid` or `sgid` binaries + - no executables in `/sbin` and `/usr/sbin` + - Package does not install services, timers or recurring jobs + TODO: - Security has been kept in mind and common isolation/risk-mitigation + TODO: patterns are in place utilizing the following features: + TODO: TBD (add details and links/examples about things like dropping + TODO: permissions, using temporary environments, restricted users/groups, + TODO: seccomp, systemd isolation features, apparmor, ...) + TODO-A: - Packages does not open privileged ports (ports < 1024). + TODO-B: - Packages open privileged ports (ports < 1024), but they have + TODO-B: a reason to do so (TBD) + TODO-A: - Package does not expose any external endpoints + TODO-B: - Package does expose an external endpoint, it is + TODO-B: TBD endpoint + TBD purpose + TODO: - Packages does not contain extensions to security-sensitive software + TODO: (filters, scanners, plugins, UI skins, ...) + + RULE: The package should not use deprecated security algorithms like 3DES or + RULE: TLS/SSL 1.1. The security team is the one responsible to check this, + RULE: but if you happen to spot something it helps to provide a hint. + RULE: Provide whatever made you suspicious as details along that statement. + RULE: Or remove the following lines entirely if you did not spot anything. + TODO: - I've spotted what I consider deprecated algorithms, the security team + TODO: should have a more careful look please, details are: + + [Quality assurance - function/usage] + RULE: - After installing the package it must be possible to make it working with + RULE: a reasonable effort of configuration and documentation reading. + TODO-A: - The package works well right after install + TODO-B: - The package needs post install configuration or reading of + TODO-B: documentation, there isn't a safe default because TBD + + [Quality assurance - maintenance] + RULE: - To support a package, we must be reasonably convinced that upstream + RULE: supports and cares for the package. + RULE: - The status of important bugs in Debian, Ubuntu and upstream's bug + RULE: tracking systems must be evaluated. Important bugs must be pointed out + RULE: and discussed in the MIR report. + TODO: - The package is maintained well in Debian/Ubuntu/Upstream and does + TODO: not have too many, long-term & critical, open bugs + TODO: - Ubuntu https://bugs.launchpad.net/ubuntu/+source/thin-provisioning-tools/+bug + TODO: - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=thin-provisioning-tools + TODO: - Upstream's bug tracker, e.g., GitHub Issues + TODO: - The package has important open bugs, listing them: TBD + TODO-A: - The package does not deal with exotic hardware we cannot support + TODO-B: - The package does deal with exotic hardware, such hardware is available + TODO-B: to the team for debugging, test, verification and development via: + RULE: This is about confidence to be able to maintain the package, therefore + RULE: any option (the examples or anything else you add) is "valid", but it + RULE: depends on the case if that is then considered sufficient. + RULE: The following examples are in descending order in regard to how "ok" they + RULE: likely will be. + TODO-B1: - testflinger under the following queue(s): TBD + TODO-B2: - (multiple) Canonical systems in the TBD computing center/lab + TODO-B3: - an engineering sample in engineers home on TBD team, manager TBD + TODO-B4: - (multiple) cloud providers as type: TBD + TODO-B5: - hopefully somewhen getting it due to TBD + + [Quality assurance - testing] + RULE: - The package must include a non-trivial test suite + RULE: - it should run at package build and fail the build if broken + TODO-A: - The package runs a test suite on build time, if it fails + TODO-A: it makes the build fail, link to build log TBD + TODO-B: - The package does not run a test at build time because TBD + + RULE: - The package should, but is not required to, also contain + RULE: non-trivial autopkgtest(s). + TODO-A: - The package runs an autopkgtest, and is currently passing on + TODO-A: this TBD list of architectures, link to test logs TBD + TODO-B: - The package does not run an autopkgtest because TBD + + RULE: - existing but failing tests that shall be handled as "ok to fail" + RULE: need to be explained along the test logs below + TODO-A: - The package does have not failing autopkgtests right now + TODO-B: - The package does have failing autopkgtests tests right now, but since + TODO-B: they always failed they are handled as "ignored failure", this is + TODO-B: ok because TBD + + 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 + + [Quality assurance - packaging] + RULE: - The package uses a debian/watch file whenever possible. In cases where + RULE: this is not possible (e.g. native packages), the package should either + RULE: provide a debian/README.source file or a debian/watch file (with + RULE: comments only) providing clear instructions on how to generate the + RULE: source tar file. + TODO-A: - debian/watch is present and works + TODO-B: - debian/watch is not present, instead it has TBD + TODO-C: - debian/watch is not present because it is a native package + + RULE: - The package should define the correct "Maintainer:" field in + RULE: debian/control. This needs to be updated, using `update-maintainer` + RULE: whenever any Ubuntu delta is applied to the package, as suggested by + RULE: dpkg (LP: #1951988) + TODO: - debian/control defines a correct Maintainer field + + RULE: - It is often useful to run `lintian --pedantic` on the package to spot + RULE: the most common packaging issues in advance + RULE: - Non-obvious or non-properly commented lintian overrides should be + RULE: explained + TODO: - This package does not yield massive lintian Warnings, Errors + TODO: - Please link to a recent build log of the package <TBD> + TODO: - Please attach the full output you have got from + TODO: `lintian --pedantic` as an extra post to this bug. + TODO-A: - Lintian overrides are not present + TODO-B: - Lintian overrides are present, but ok because TBD + + RULE: - The package should not rely on obsolete or about to be demoted packages. + RULE: That currently includes package dependencies on Python2 (without + RULE: providing Python3 packages), and packages depending on GTK2. + TODO: - This package does not rely on obsolete or about to be demoted packages. + TODO: - This package has no python2 or GTK2 dependencies + + RULE: - Debconf questions should not bother the default user too much + TODO-A: - The package will be installed by default, but does not ask debconf + TODO-A: questions higher than medium + TODO-B: - The package will not be installed by default + + TODO-A: - Packaging and build is easy, link to debian/rules TBD + TODO-B: - Packaging is complex, but that is ok because TBD + + [UI standards] + TODO-A: - Application is not end-user facing (does not need translation) + TODO-B: - Application is end-user facing, Translation is present, via standard + TODO-B: intltool/gettext or similar build and runtime internationalization + TODO-B: system see TBD + + TODO-A: - End-user applications that ships a standard conformant desktop file, + TODO-A: see TBD + TODO-B: - End-user applications without desktop file, not needed because TBD + + [Dependencies] + - No further depends or recommends dependencies that are not yet in main (not including the bundled rust dependencies) + + [Standards compliance] + TODO-A: - This package correctly follows FHS and Debian Policy + TODO-B: - This package violates FHS or Debian Policy, reasons for that are TBD + + [Maintenance/Owner] + - The owning team is Ubuntu Server and I have their acknowledgement for that commitment + - The owning team is already subscribed to the package + + - The Ubuntu Server team is aware of the implications by a static build and + commits to test no-change-rebuilds and to fix any issues found for the + lifetime of the release (including ESM) + + - The Ubuntu Server team is aware of the implications of vendored code and (as + alerted by the security team) commits to provide updates and backports + to the security team for any affected vendored code for the lifetime + of the release (including ESM). + + TODO-C: - This package uses vendored rust code tracked in Cargo.lock as shipped, + TODO-C: in the package (at /usr/share/doc/<pkgname>/Cargo.lock - might be + TODO-C: compressed), refreshing that code is outlined in debian/README.source + TODO-D: - This package uses vendored code, refreshing that code is outlined + TODO-D: in debian/README.source + + TODO-B: - This package is rust based and vendors all non language-runtime + TODO-B: dependencies + + - The package has been built within the last 3 months in https://launchpad.net/~athos-ribeiro/+archive/ubuntu/thin-provisioning-tools/+packages + - Build link on launchpad: https://launchpad.net/~athos-ribeiro/+archive/ubuntu/thin-provisioning-tools/+build/29393562 + + [Background information] + TODO: The Package description explains the package well + TODO: Upstream Name is TBD + TODO: Link to upstream project TBD + TODO: TBD (any further background that might be helpful
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2091303 Title: [MIR] thin-provisioning-tools To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/thin-provisioning-tools/+bug/2091303/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
