| 2024-06-26 18:56:14 |
Jeremy Bícha |
bug |
|
|
added bug |
| 2024-06-26 19:13:57 |
Jeremy Bícha |
highway (Ubuntu): status |
New |
Incomplete |
|
| 2024-06-26 19:15:20 |
Jeremy Bícha |
description |
[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)
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 |
[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
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 |
|
| 2024-06-26 19:58:27 |
Jeremy Bícha |
description |
[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
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 |
[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
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: #2006001)
- 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
- Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=highway
- Upstream's bug tracker https://github.com/google/highway/issues
[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 for that 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 |
|
| 2024-06-27 00:22:29 |
Jeremy Bícha |
description |
[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
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: #2006001)
- 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
- Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=highway
- Upstream's bug tracker https://github.com/google/highway/issues
[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 for that 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 |
[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
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: #2006001)
- 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
- Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=highway
- Upstream's bug tracker https://github.com/google/highway/issues
- The package does not deal with exotic hardware we cannot support
[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 for that 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 |
|
| 2024-06-27 16:50:17 |
Jeremy Bícha |
description |
[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
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: #2006001)
- 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
- Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=highway
- Upstream's bug tracker https://github.com/google/highway/issues
- The package does not deal with exotic hardware we cannot support
[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 for that 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 |
[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
Link to package https://launchpad.net/ubuntu/+source/highway
[Rationale]
- The package highway is required in Ubuntu main as a build and runtime dependency of jpeg-xl (LP: #2006001)
- 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
- Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=highway
- Upstream's bug tracker https://github.com/google/highway/issues
- The package does not deal with exotic hardware we cannot support
[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 for that 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 |
|
| 2024-06-27 16:50:42 |
Jeremy Bícha |
description |
[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
Link to package https://launchpad.net/ubuntu/+source/highway
[Rationale]
- The package highway is required in Ubuntu main as a build and runtime dependency of jpeg-xl (LP: #2006001)
- 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
- Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=highway
- Upstream's bug tracker https://github.com/google/highway/issues
- The package does not deal with exotic hardware we cannot support
[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 for that 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 |
[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
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: #2070882)
- 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
- Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=highway
- Upstream's bug tracker https://github.com/google/highway/issues
- The package does not deal with exotic hardware we cannot support
[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 for that 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 |
|
| 2024-07-02 14:18:20 |
Jeremy Bícha |
highway (Ubuntu): assignee |
|
Jeremy Bícha (jbicha) |
|
| 2024-07-02 14:18:29 |
Jeremy Bícha |
bug |
|
|
added subscriber MIR approval team |
| 2024-07-02 14:19:54 |
Jeremy Bícha |
description |
[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
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: #2070882)
- 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
- Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=highway
- Upstream's bug tracker https://github.com/google/highway/issues
- The package does not deal with exotic hardware we cannot support
[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 for that 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 |
[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
Link to package https://launchpad.net/ubuntu/+source/highway
[Rationale]
- The package highway is required in Ubuntu main as a build and runtime dependency of jpeg-xl (LP: #2070882)
- 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
- Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=highway
- Upstream's bug tracker https://github.com/google/highway/issues
- The package does not deal with exotic hardware we cannot support
[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 for that 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 |
|
