From Fedora Project Wiki
Line 56: Line 56:


== Scope ==
== Scope ==
* Proposal owners:
* Proposal owners: Implement the proposal.
<!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
<!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->


* Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Other developers: Developers need to ensure that their packages continue to build and install with the new split tzdata/tzdata-minimal package changes.
<!-- What work do other developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->


* Release engineering: [https://pagure.io/releng/issues #Releng issue number] <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Release engineering: The tzdata maintainer will ensure that the package builds and passes all tests on F35.
[https://pagure.io/releng/issues #Releng issue number] <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuild required?  include a link to the releng issue.  
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuild required?  include a link to the releng issue.  
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->


* Policies and guidelines: N/A (not needed for this Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Policies and guidelines: The policies and guidelines do not need to be updated.
<!-- Do the packaging guidelines or other documents need to be updated for this feature?  If so, does it need to happen before or after the implementation is done?  If a FPC ticket exists, add a link here. Please submit a pull request with the proposed changes before submitting your Change proposal. -->


* Trademark approval: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
<!-- If your Change may require trademark approval (for example, if it is a new Spin), file a ticket ( https://pagure.io/Fedora-Council/tickets/issues ) requesting trademark approval from the Fedora Council. This approval will be done via the Council's consensus-based process. -->


* Alignment with Objectives:  
* Alignment with Objectives: This change is directly related to container minimization goals.
<!-- Does your proposal align with the current Fedora Objectives: https://docs.fedoraproject.org/en-US/project/objectives/ ? It's okay if it doesn't, but it's something to consider -->


== Upgrade/compatibility impact ==
== Upgrade/compatibility impact ==

Revision as of 11:44, 28 June 2021

Comments and Explanations
The page source contains comments providing guidance to fill out each section. They are invisible when viewing this page. To read it, choose the "view source" link.
Copy the source to a new page before making changes! DO NOT EDIT THIS TEMPLATE FOR YOUR CHANGE PROPOSAL.
Guidance
For details on how to fill out this form, see the documentation.


Change Proposal Name

tzdata-minimal

Summary

Split the tzdata package into two parts - tzdata and tzdata-minimal. tzdata will require tzdata-minimal. tzdata-minimal provides the minimal files needed to support UTC on containers.

Owner

  • Name: Patsy Griffin (Franklin)
  • Email: patsy@redhat.com


Current status

  • Targeted release: 35
  • Last updated: 2021-06-28
  • FESCo issue: <will be assigned by the Wrangler>
  • Tracker bug: <will be assigned by the Wrangler>
  • Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

This is the first step towards providing support for a minimal, UTC only version of tzdata for containers. The tzdata-minimal package will be a stand-alone, UTC only subset of tzdata. The tzdata package will require tzdata-minimal.

With this framework in place, other packages can develop code to detect a minimal tzdata installation. These packages will also need to provide appropriate messages when users request timezone information not provided by tzdata-minimal.

Feedback

We have had requests for this functionality in order to support minimal container installations. Currently some container kickstart installations already remove most of the timezone information provided by tzdata, leaving only UTC support available.

Both the glibc and python teams are aware of this proposed change. This change does not currently require changes in their code. The goal is for those packages that currently require tzdata as part of their build or install, move towards recommending tzdata instead.

Benefit to Fedora

This change will reduce the size of base container installations.

Scope

  • Proposal owners: Implement the proposal.
  • Other developers: Developers need to ensure that their packages continue to build and install with the new split tzdata/tzdata-minimal package changes.
  • Release engineering: The tzdata maintainer will ensure that the package builds and passes all tests on F35.

#Releng issue number

  • Policies and guidelines: The policies and guidelines do not need to be updated.
  • Trademark approval: N/A (not needed for this Change)
  • Alignment with Objectives: This change is directly related to container minimization goals.

Upgrade/compatibility impact

How To Test

User Experience

Dependencies

Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change), Yes/No


Documentation

N/A (not a System Wide Change)

Release Notes