** Changed in: showtime (Ubuntu)
Status: Expired => Incomplete
** Description changed:
[Availability]
The package showtime is already in Ubuntu universe.
The package showtime build for the architectures it is designed to work on.
It currently builds and works for architectures: all except i386
Link to package https://launchpad.net/ubuntu/+source/showtime
[Rationale]
- The package showtime is required in Ubuntu main as a default video player
for Ubuntu Desktop.
- The package showtime will generally be useful for a large part of our user
base
- Package showtime covers the same use case as totem, but is better because
it is more actively maintained and has improved UI/UX, thereby we want to
replace it. GNOME Core officially switched from totem to showtime for GNOME 49
and we want to do that swap too.
- There is no other/better way to solve this that is already in main or
should go universe->main instead of this.
- This is the first time package will be in main
- The binary package showtime needs to be in main to achieve a better video
player for Ubuntu Desktop.
- All binary packages built by showtime need to be in main. (There is only
one binary package.)
- - It would be great and useful to community/processes to have the package
showtime in Ubuntu main, but there is no definitive deadline. Specifically,
although Loupe and Ptyxis were mentioned in Ubuntu Desktop 25.10 plans,
Showtime was not; therefore Showtime is a lower priority than those other apps.
-
https://discourse.ubuntu.com/t/ubuntu-desktop-25-10-the-questing-quokka-roadmap/61159
+ - It would be great and useful to community/processes to have the
+ package showtime in Ubuntu main, but there is no definitive deadline.
[Security]
- No CVEs/security issues in this software in the past
- no `suid` or `sgid` binaries
- no executables in `/sbin` and `/usr/sbin`
- Package does not install services, timers or recurring jobs
- Packages does not open privileged ports (ports < 1024).
- Package does not expose any external endpoints
- Packages does not contain extensions to security-sensitive software
[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/showtime
- Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=showtime
- Upstream https://gitlab.gnome.org/GNOME/showtime/-/issues
- The package does not deal with exotic hardware we cannot support
[Quality assurance - testing]
The package runs a few trivial metadata validation tests on build time, if it
fails it makes the build fail, link to build log
https://launchpad.net/ubuntu/+source/showtime/49~alpha-2/+latestbuild/amd64
It does not run more extensive tests because build time tests wouldn't
do a very good job of testing this app's specific functionality. The app
is mostly a frontend to gstreamer which does have a stronger testing
story.
- The package does not run an autopkgtest because it is a GUI video
player app and autopkgtest isn't a good fit for this kind of package
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-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
[Quality assurance - packaging]
- debian/watch is present and works
- debian/control defines a correct Maintainer field
- This package does not yield massive lintian Warnings, Errors
- Please link to a recent build log of the package
https://launchpad.net/ubuntu/+source/showtime/49~alpha-2/+latestbuild/amd64
- Please attach the full output you have got from `lintian --pedantic` as an
extra post to this bug.
- Lintian overrides are not present
- 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/gnome-team/showtime/-/blob/debian/latest/debian/rules
[UI standards]
- Application is end-user facing, Translation is present, via standard gettext
- End-user applications that ships a standard conformant desktop file, see
https://salsa.debian.org/gnome-team/showtime/-/blob/debian/latest/data/org.gnome.Showtime.desktop.in
[Dependencies]
- Used check-mir from ubuntu-dev-tools to validate all dependencies or
recommends are in main.
[Standards compliance]
- This package correctly follows FHS and Debian Policy
[Maintenance/Owner]
- The owning team will be debcrafters-packages and I have their
acknowledgment for that commitment
- The future owning team is not yet subscribed, but will subscribe to the
package before promotion
- 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:
[Background information]
- The Package description explains the package well
- Upstream Name is showtime (user-visible name is Video Player)
- Link to upstream project https://gitlab.gnome.org/GNOME/showtime
GNOME does not currently have a video thumbnailer solution. Our current
plan is to demote to universe the totem, totem-plugins, gir1.2-totem-1.0
and libtotem-dev binary packages while libtotem0, totem-common, and
totem-video-thumbnailer will stay in main.
We expect GNOME to recommend a thumbnailer solution, but we can't guarantee
that it will be ready in time for Ubuntu 26.04 LTS.
https://gitlab.gnome.org/Teams/Releng/AppOrganization/-/issues/35
** Description changed:
[Availability]
The package showtime is already in Ubuntu universe.
The package showtime build for the architectures it is designed to work on.
It currently builds and works for architectures: all except i386
Link to package https://launchpad.net/ubuntu/+source/showtime
[Rationale]
- The package showtime is required in Ubuntu main as a default video player
for Ubuntu Desktop.
- The package showtime will generally be useful for a large part of our user
base
- Package showtime covers the same use case as totem, but is better because
it is more actively maintained and has improved UI/UX, thereby we want to
replace it. GNOME Core officially switched from totem to showtime for GNOME 49
and we want to do that swap too.
- There is no other/better way to solve this that is already in main or
should go universe->main instead of this.
- This is the first time package will be in main
- The binary package showtime needs to be in main to achieve a better video
player for Ubuntu Desktop.
- All binary packages built by showtime need to be in main. (There is only
one binary package.)
- It would be great and useful to community/processes to have the
package showtime in Ubuntu main, but there is no definitive deadline.
[Security]
- No CVEs/security issues in this software in the past
- no `suid` or `sgid` binaries
- no executables in `/sbin` and `/usr/sbin`
- Package does not install services, timers or recurring jobs
- Packages does not open privileged ports (ports < 1024).
- Package does not expose any external endpoints
- Packages does not contain extensions to security-sensitive software
[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/showtime
- Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=showtime
- Upstream https://gitlab.gnome.org/GNOME/showtime/-/issues
- The package does not deal with exotic hardware we cannot support
[Quality assurance - testing]
The package runs a few trivial metadata validation tests on build time, if it
fails it makes the build fail, link to build log
- https://launchpad.net/ubuntu/+source/showtime/49~alpha-2/+latestbuild/amd64
+ https://launchpad.net/ubuntu/+source/showtime/49.0-1/+latestbuild/amd64
It does not run more extensive tests because build time tests wouldn't
do a very good job of testing this app's specific functionality. The app
is mostly a frontend to gstreamer which does have a stronger testing
story.
- The package does not run an autopkgtest because it is a GUI video
player app and autopkgtest isn't a good fit for this kind of package
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-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
[Quality assurance - packaging]
- debian/watch is present and works
- debian/control defines a correct Maintainer field
- This package does not yield massive lintian Warnings, Errors
- Please link to a recent build log of the package
- https://launchpad.net/ubuntu/+source/showtime/49~alpha-2/+latestbuild/amd64
+ https://launchpad.net/ubuntu/+source/showtime/49.0-1/+latestbuild/amd64
- Please attach the full output you have got from `lintian --pedantic` as an
extra post to this bug.
- Lintian overrides are not present
- 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/gnome-team/showtime/-/blob/debian/latest/debian/rules
[UI standards]
- Application is end-user facing, Translation is present, via standard gettext
- End-user applications that ships a standard conformant desktop file, see
https://salsa.debian.org/gnome-team/showtime/-/blob/debian/latest/data/org.gnome.Showtime.desktop.in
[Dependencies]
- Used check-mir from ubuntu-dev-tools to validate all dependencies or
recommends are in main.
[Standards compliance]
- This package correctly follows FHS and Debian Policy
[Maintenance/Owner]
- The owning team will be debcrafters-packages and I have their
acknowledgment for that commitment
- The future owning team is not yet subscribed, but will subscribe to the
package before promotion
- 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:
[Background information]
- The Package description explains the package well
- Upstream Name is showtime (user-visible name is Video Player)
- Link to upstream project https://gitlab.gnome.org/GNOME/showtime
GNOME does not currently have a video thumbnailer solution. Our current
plan is to demote to universe the totem, totem-plugins, gir1.2-totem-1.0
and libtotem-dev binary packages while libtotem0, totem-common, and
totem-video-thumbnailer will stay in main.
We expect GNOME to recommend a thumbnailer solution, but we can't guarantee
that it will be ready in time for Ubuntu 26.04 LTS.
https://gitlab.gnome.org/Teams/Releng/AppOrganization/-/issues/35
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2115912
Title:
[MIR] showtime
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/showtime/+bug/2115912/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
