** 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

Reply via email to