** Changed in: highway (Ubuntu)
Status: New => Incomplete
** Description changed:
[Availability]
The package highway is already in Ubuntu universe.
The package highway build for the architectures it is designed to work on.
- It currently builds and works for all Ubuntu architectures except for i386
(not needed there)
+ It currently builds and works for all Ubuntu architectures
Link to package https://launchpad.net/ubuntu/+source/highway
[Rationale]
RULE: There must be a certain level of demand for the package
- The package highway is required in Ubuntu main as a build and runtime
dependency of jpeg-xl (LP: #)
- The package highway will generally be useful for a large part of our user
base
- The binary package libhwy1t64 needs to be in main to achieve JPEG XL support
- It would be great and useful to community/processes to have the
package highway in Ubuntu main, but there is no definitive deadline.
[Security]
- No CVEs/security issues in this software in the past
- https://ubuntu.com/security/cve?package=highway
- https://security-tracker.debian.org/tracker/source-package/highway
-
- no `suid` or `sgid` binaries
- no executables in `/sbin` and `/usr/sbin`
- Packages do not install services, timers or recurring jobs
- Packages do not open privileged ports (ports < 1024).
- Packages do not expose any external endpoints
- Packages do not contain extensions to security-sensitive software (filters,
scanners, plugins, UI skins, ...)
[Quality assurance - function/usage]
- The package works well right after install
[Quality assurance - maintenance]
- The package is maintained well in Debian/Ubuntu/Upstream and does not have
too many, long-term & critical, open bugs
- Ubuntu https://bugs.launchpad.net/ubuntu/+source/highway/+bug
TODO: - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=highway
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, it is present at TBD
TODO-B: to be able to test, fix and verify bugs
[Quality assurance - testing]
- The package runs a test suite on build time, if it fails it makes the build
fail, link to build log https://launchpad.net/ubuntu/+source/highway/1.2.0-2
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: - 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).
RULE: If possible such things should stay in universe. Sometimes that is
RULE: impossible due to the way how features/plugins/dependencies work
RULE: but if you are going to ask for promotion of something untestable
RULE: please outline why it couldn't provide its value (e.g. by splitting
RULE: binaries) to users from universe.
RULE: This is a balance that is hard to strike well, the request is that all
RULE: options have been exploited before giving up. Look for more details
RULE: and backgrounds https://github.com/canonical/ubuntu-mir/issues/30
RULE: Just like in the SRU process it is worth to understand what the
RULE: consequences a regression (due to a test miss) would be. Therefore
RULE: if being untestable we ask to outline what consequences this would
RULE: have for the given package. And let us be honest, even if you can
RULE: test you are never sure you will be able to catch all potential
RULE: regressions. So this is mostly to force self-awareness of the owning
RULE: team than to make a decision on.
TODO: - The package can not be well tested at build or autopkgtest time
TODO: because TBD. To make up for that:
TODO-A: - We have access to such hardware in the team
TODO-B: - We have allocated budget to get this hardware, but it is not here
TODO-B: yet
TODO-C: - We have checked with solutions-qa and will use their hardware
TODO-C: through testflinger
TODO-D: - We have checked with other team TBD and will use their hardware
TODO-D: through TBD (eg. MAAS)
TODO-E: - We have checked and found a simulator which covers this case
TODO-E: sufficiently for testing, our plan to use it is TBD
TODO-F: - We have engaged with the upstream community and due to that
TODO-F: can tests new package builds via TBD
TODO-G: - We have engaged with our user community and due to that
TODO-G: can tests new package builds via TBD
TODO-H: - We have engaged with the hardware manufacturer and made an
TODO-H: agreement to test new builds via TBD
TODO-A-H: - Based on that access outlined above, here are the details of the
TODO-A-H: test plan/automation TBD (e.g. script or repo) and (if already
TODO-A-H: possible) example output of a test run: TBD (logs).
TODO-A-H: We will execute that test plan
TODO-A-H1: on-uploads
TODO-A-H2: regularly (TBD details like frequency: monthly, infra: jira-url)
TODO-X: - We have exhausted all options, there really is no feasible way
TODO-X: to test or recreate this. We are aware of the extra implications
TODO-X: and duties this has for our team (= help SEG and security on
TODO-X: servicing this package, but also more effort on any of your own
TODO-X: bug triage and fixes).
TODO-X: Due to TBD there also is no way to provide this to users from
TODO-X: universe.
TODO-X: Due to the nature, integration and use cases of the package the
TODO-X: consequences of a regression that might slip through most likely
TODO-X: would include
TODO-X: - TBD
TODO-X: - TBD
TODO-X: - 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]
- debian/watch is present and works
- debian/control defines a correct Maintainer field
- Lintian overrides are present, but ok because this was affected by the
t64 transition
- This package does not rely on obsolete or about to be demoted packages.
- This package has no python2 or GTK2 dependencies
- The package will be installed by default, but does not ask debconf
questions
- Packaging and build is easy, link to debian/rules
https://salsa.debian.org/debian-phototools-team/highway/-/blob/master/debian/rules
-
[UI standards]
- Application is not end-user facing (does not need translation or .desktop
file)
[Dependencies]
- No further depends or recommends dependencies that are not yet in main
[Standards compliance]
- This package correctly follows FHS and Debian Policy
[Maintenance/Owner]
- The owning team will be Ubuntu Desktop (~desktop-packages) and I have their
acknowledgement forthat commitment
- This does not use static builds
- This does not use vendored code
- This package is not rust based
- The package has been built within the last 3 months in the archive
- Build link on launchpad:
https://launchpad.net/ubuntu/+source/highway/1.2.0-2
[Background information]
- The Package description explains the package well
- Upstream Name is highway
- Link to upstream project https://github.com/google/highway
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2070807
Title:
[MIR] highway
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/highway/+bug/2070807/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
