Public bug reported:
Note: I know it is the template so far, but after the discussions at the
sprint I want something we can start working on together.
Background: after evaluation it was considered easier to maintain to
provide a good and secure ntp experience as well as some people asking
me if it could be preferred.
--- MIR ---
1. Availability: The package is Ubuntu universe and builds for the
architectures it is designed to work on.
2. Rationale: NTP in general is needed quite a lot, but we want to
exchange ntpd which is the current implementation in main with chrony
for 18.04.
3. Security: In fact the request came in by security Team, so I guess I
call this section done
-- EVERYTHING BELOW TBD FOR NOW --
Quality assurance:
After installing the package it must be possible to make it working with a
reasonable effort of configuration and documentation reading.
The package must not ask debconf questions higher than medium if it is going to
be installed by default. The debconf questions must have reasonable defaults.
There are no long-term outstanding bugs which affect the usability of the
program to a major degree. To support a package, we must be reasonably
convinced that upstream supports and cares for the package.
The status of important bugs in Debian's, Ubuntu's, and upstream's bug tracking
systems must be evaluated. Important bugs must be pointed out and discussed in
the MIR report.
The package is maintained well in Debian/Ubuntu (check out the Debian PTS)
The package should not deal with exotic hardware which we cannot support.
If the package ships a test suite, and there is no obvious reason why it cannot
work during build (e. g. it needs root privileges or network access), it should
be run during package build, and a failing test suite should fail the build.
The package uses a debian/watch file whenever possible. In cases where this is
not possible (e. g. native packages), the package should either provide a
debian/README.source file or a debian/watch file (with comments only) providing
clear instructions on how to generate the source tar file.
The package should not rely on obsolete or about to be demoted packages. That
currently includes package dependencies on Python2 (without providing Python3
packages), and packages depending on GTK2.
UI standards: (generally only for user-facing applications)
End-user applications must be internationalized (translatable), using the
standard intltool/gettext build and runtime system and produce a proper PO
template during build.
End-user applications must ship a standard conformant desktop file.
Dependencies:
All binary dependencies (including Recommends:) must be satisfiable in
main (i. e. the preferred alternative must be in main). If not, these
dependencies need a separate MIR report (this can be a separate bug or
another task on the main MIR bug)
Standards compliance: The package should meet the FHS and Debian Policy
standards. Major violations should be documented and justified. Also,
the source packaging should be reasonably easy to understand and
maintain.
Maintenance: The package must have an acceptable level of maintenance
corresponding to its complexity:
All packages must have a designated "owning" team, regardless of complexity,
which is set as a package bug contact.
Simple packages (e.g. language bindings, simple Perl modules, small
command-line programs, etc.) might not need very much maintenance effort, and
if they are maintained well in Debian we can just keep them synced
More complex packages will usually need a developer or team of developers
paying attention to their bugs, whether that be in Ubuntu or elsewhere (often
Debian). Packages that deliver major new headline features in Ubuntu need to
have commitment from Ubuntu developers willing to spend substantial time on
them.
Background information:
The package descriptions should explain the general purpose and context of the
package. Additional explanations/justifications should be done in the MIR
report.
If the package was renamed recently, or has a different upstream name, this
needs to be explained in the MIR report.
--- Affected Packages ---
Maas - needs to change dependencies and maybe template
cloud-init - needs to support writing ntp config to chrony instead of ntpd
ceph-base - change recommends from ntpd to chrony (it only intends to get good
time, so that should be ok)
seeds - remove seeding of ntp
chrony - MIR itself (seeding)
chrony - add default enabled apparmor profile
** Affects: chrony (Ubuntu)
Importance: Undecided
Status: New
** Description changed:
Note: I know it is the template so far, but after the discussions at the
sprint I want something we can start working on together.
Background: after evaluation it was considered easier to maintain to
provide a good and secure ntp experience as well as some people asking
me if it could be preferred.
--- MIR ---
- TBD
+ 1. Availability: The package is Ubuntu universe and builds for the
+ architectures it is designed to work on.
- Thoroughly go through UbuntuMainInclusionRequirements, check that the
- package meets all the points there. Write down issues that violate the
- requirements. If this package has nontrivial problems, it is not
- eligible for main inclusion, and needs to be fixed first.
+ 2. Rationale: NTP in general is needed quite a lot, but we want to
+ exchange ntpd which is the current implementation in main with chrony
+ for 18.04.
- File a bug report about the package, titled "[MIR] sourcepackagename".
- Include the rationale and description of the violations of
- UbuntuMainInclusionRequirements, and a confirmation that you checked the
- requirements carefully.
+ 3. Security: In fact the request came in by security Team, so I guess I
+ call this section done
- Subscribe ubuntu-mir to the bug report (do not assign it to anyone), so
- that it appears in the MIR bug list.
- The MIR team reviews the reports, and sets acceptable ones to In
- Progress or Fix Committed. They might also delegate portions of the
- review to other teams, assign it to them, and set it to Incomplete;
- common cases are getting a thorough security review from the security
- team (please see SecurityTeam/Auditing for details on requesting an
- audit), or getting a sign-off from particular team leads about
- maintenance commitments.
+ -- EVERYTHING BELOW TBD FOR NOW --
- Add the package to a seed, or as a (build-)dependency of a package in
- main. The package will not be moved to main automatically, but will show
- up in the component-mismatches list, or if the dependency is only in
- proposed, the component-mismatches-proposed list.
+ Quality assurance:
- Archive administrators will review the component-mismatches output, and
- for each package waiting to move into main, look for a corresponding
- bug.
+ After installing the package it must be possible to make it working with a
reasonable effort of configuration and documentation reading.
+ The package must not ask debconf questions higher than medium if it is going
to be installed by default. The debconf questions must have reasonable defaults.
+ There are no long-term outstanding bugs which affect the usability of the
program to a major degree. To support a package, we must be reasonably
convinced that upstream supports and cares for the package.
+ The status of important bugs in Debian's, Ubuntu's, and upstream's bug
tracking systems must be evaluated. Important bugs must be pointed out and
discussed in the MIR report.
- The submitter should then take responsibility for adding the package to
- the seeds as per SeedManagement or adding a dependency to it.
+ The package is maintained well in Debian/Ubuntu (check out the Debian PTS)
+ The package should not deal with exotic hardware which we cannot support.
+ If the package ships a test suite, and there is no obvious reason why it
cannot work during build (e. g. it needs root privileges or network access), it
should be run during package build, and a failing test suite should fail the
build.
+ The package uses a debian/watch file whenever possible. In cases where this
is not possible (e. g. native packages), the package should either provide a
debian/README.source file or a debian/watch file (with comments only) providing
clear instructions on how to generate the source tar file.
+ The package should not rely on obsolete or about to be demoted packages. That
currently includes package dependencies on Python2 (without providing Python3
packages), and packages depending on GTK2.
+ UI standards: (generally only for user-facing applications)
- The archive administrators will promote approved packages to main if
- some other package or the seeds want it (see component-mismatches
- output).
+ End-user applications must be internationalized (translatable), using the
standard intltool/gettext build and runtime system and produce a proper PO
template during build.
+ End-user applications must ship a standard conformant desktop file.
+ Dependencies:
+
+ All binary dependencies (including Recommends:) must be satisfiable in
+ main (i. e. the preferred alternative must be in main). If not, these
+ dependencies need a separate MIR report (this can be a separate bug or
+ another task on the main MIR bug)
+
+ Standards compliance: The package should meet the FHS and Debian Policy
+ standards. Major violations should be documented and justified. Also,
+ the source packaging should be reasonably easy to understand and
+ maintain.
+
+ Maintenance: The package must have an acceptable level of maintenance
+ corresponding to its complexity:
+
+ All packages must have a designated "owning" team, regardless of complexity,
which is set as a package bug contact.
+ Simple packages (e.g. language bindings, simple Perl modules, small
command-line programs, etc.) might not need very much maintenance effort, and
if they are maintained well in Debian we can just keep them synced
+ More complex packages will usually need a developer or team of developers
paying attention to their bugs, whether that be in Ubuntu or elsewhere (often
Debian). Packages that deliver major new headline features in Ubuntu need to
have commitment from Ubuntu developers willing to spend substantial time on
them.
+ Background information:
+
+ The package descriptions should explain the general purpose and context of
the package. Additional explanations/justifications should be done in the MIR
report.
+ If the package was renamed recently, or has a different upstream name, this
needs to be explained in the MIR report.
--- Affected Packages ---
Maas - needs to change dependencies and maybe template
cloud-init - needs to support writing ntp config to chrony instead of ntpd
ceph-base - change recommends from ntpd to chrony (it only intends to get
good time, so that should be ok)
+ seeds - remove seeding of ntp
+ chrony - MIR itself (seeding)
+ chrony - add default enabled apparmor profile
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1744072
Title:
MIR Chrony in 18.04
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/chrony/+bug/1744072/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
