Join us on irc.freenode.net in #fedora-meeting-2 for the Fedora 26
Final Release Readiness Meeting meeting.
The meeting is going to be held on Thursday, July 6th, 2017 at 19:00
UTC. Please check the [1] link for your time zone.
We will meet to make sure we are coordinated and ready for the Final
release of Fedora 26. Please note that this meeting is going to be
held even if the release is delayed at the Go/No-Go meeting on the
same day two hours earlier.
You may received this message several times, but it is by purpose to
open this meeting to the teams and to raise awareness, so hopefully
more team representatives will come to this meeting. This meeting
works best when we have representatives from all of the teams.
For more information please check the [2] link.
As I will not be available for this meeting, Jaroslav Reznik <jreznik>
will be the moderator. Please contact Jaroslav in case of a need for
additional information.
[1] https://apps.fedoraproject.org/calendar/meeting/6285/
[2] https://fedoraproject.org/wiki/Release_Readiness_Meetings
Thank you for your support,
Regards, Jan
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
= Proposed Self Contained Change: Samba AD =
https://fedoraproject.org/wiki/Changes/Samba_AD
Change owner(s):
* Alexander Bokovoy <abokovoy AT redhat DOT com>
* Andreas Schneider <asn AT redhat DOT com>
Samba AD is an open source implementation of an Active Directory set
of tools and protocols. It allows Windows clients to be enrolled and
managed using native Windows tools. In addition, Samba AD can serve as
a domain controller for Fedora workstations and servers utilizing
DCERPC, LDAP and Kerberos.
== Detailed Description ==
Samba AD is an implementation of an Active Directory set of tools and
protocols. It is developed and released as part of Samba suite.
Upcoming Samba 4.7 release will contain changes to allow Samba AD to
be built and used with MIT Kerberos. Prior to Samba 4.7 it was
impossible to compile Samba AD with MIT Kerberos. As result, Samba AD
was not packaged in Fedora.
== Scope ==
* Proposal owners:
Samba packages in Fedora already include a stub subpackage samba-dc
that is going to be replaced with a full Samba AD implementation.
Appropriate dependencies are already present in Fedora 27/Rawhide or
will be added together with Samba 4.7 update. This mostly concerns
upgrade of Samba-related libraries: libtevent, libldb, libtdb, and MIT
Kerberos update to support new APIs added to accommodate Samba AD
(already in Rawhide).
* Other developers:
N/A (not a System Wide Change)
* Release engineering:
- https://pagure.io/releng/issue/6869
- We believe no impact to Release Engineering is needed for this change
* List of deliverables:
N/A (not a System Wide Change)
* Policies and guidelines:
N/A (not a System Wide Change)
* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
= Proposed Self Contained Change: Remove SSH-1 from OpenSSH clients =
https://fedoraproject.org/wiki/Changes/Remove_SSH-1_from_OpenSSH
Change owner(s):
* Jakub Jelen <jjelen AT redhat DOT com>
Upstream removes support for SSH-1 protocol and we plan to do the same
in Fedora. The protocol is years obsolete and not even supported in
current default binaries (only in openssh-clients-ssh1 subpackage).
== Detailed Description ==
SSH-1 protocol was introduced more than 20 years ago and is no longer
considered secure. OpenSSH package in Fedora is built without SSH-1
protocol since 2015 (SSH-1 clients are available in
openssh-clients-ssh1 subpackage). OpenSSH upstream plans to remove the
code completely in next release, which prevents us from using this
technique further and remove the support completely (unless there will
be significant demand for compat package).
== Scope ==
* Proposal owners:
Remove subpackage openssh-clients-ssh1 and potentially create
compat-openssh-clients-7.5 package with clients supporting SSH-1
protocol.
* Other developers:
N/A (not a System Wide Change)
* Release engineering:
#6867 https://pagure.io/releng/issues/6867
* List of deliverables:
N/A (not a System Wide Change)
* Policies and guidelines:
N/A (not a System Wide Change)
* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
= Proposed System Wide Change: Modular Server =
https://fedoraproject.org/wiki/Changes/Modular_Server
Change owner(s):
* Langdon White <langdon AT fedoraproject DOT org>
The Modularity Working Group, Factory 2.0, Base Runtime, and Server
Working Group would like to propose using the modular infrastructure
for creating and delivering the Fedora Server Edition for Fedora 27.
While we are still working through some of the kinks leading up to the
release of Fedora 26, we believe that the changes to the
infrastructure and technology implementations will be available with
sufficient time to harden the components in time for the 27 release.
== Detailed Description ==
The modularity effort is fairly well known and significantly more
information may be found on the Modularity Website [
https://docs.pagure.org/modularity/ ] or the YouTube Channel [
https://www.youtube.com/channel/UC4O8G9SZwqtkIAuKcT8-JpQ ]. In short,
modularity is attempting to disconnect the lifecycle of applications
from 1) each other 2) the operating system while still maintaining the
ease of use of a typical Linux Distro.
This change proposal is to promote the work done in the Boltron
Release (preview container image in advance of the F26 release) to
Fedora mainline through the Fedora Server Edition. We will also be
working with the community to complete the available content for
Fedora Server Edition as modules.
Other edition and spins will not change at this point; users who want
to create a Fedora server (as opposed to capital-S Fedora Server)
without Modularity can use one of these other spins, including the
Fedora Cloud Base image, or else use the "everything netinst".
== Scope ==
* Proposal owners:
The Modularity WG, Factory 2.0, Base Runtime, and Server WG teams all
have contributions to this effort. The work that each team is doing is
significant and wide ranging. We are hoping to:
- collect and incorporate feedback in to the system management
experience of using modules (through dnf)
- modularize a significant amount of the content available for Fedora
Server (focusing on current Server roles)
- define tools and best practices for implementing modules and keeping
them up to date
* Other developers:
- Packagers are already working on modularizing applications;
- the Modularity WG will provide like to support additional package
maintainers in modularizing their applications
* Release engineering:
See [[Changes/ModularRelease]] [
https://fedoraproject.org/wiki/Changes/ModularRelease ]
[ https://pagure.io/releng/issue/6852 ]
* List of deliverables:
This change replaces the Fedora 26 Server release-blocking
deliverables with exactly the same things (DVDs and netinst images)
but delivered via Modularity instead of the traditional process.
Although we want to enable changes to module lifecycles over time, it
is worth noting that this Change Proposal does NOT change the normal
13 month commitment for anything in the release.
* Policies and guidelines:
New guidelines are required, they are currently in Draft state and we
will be collecting feedback to them during the F26 lifecycle for
ratification prior to F27.
- Fedora_Packaging_Guidelines_for_Modules [
https://fedoraproject.org/wiki/Fedora_Packaging_Guidelines_for_Modules
]
- Container:Guidelines [ https://fedoraproject.org/wiki/Container:Guidelines ]
At this point there are no changes expected to existing guidelines
* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
= Proposed System Wide Change: Host and Platform =
https://fedoraproject.org/wiki/Changes/Host_and_Platform
Change owner(s):
* Petr Šabata <contyk AT redhat DOT com>
Host and Platform is an evolution of the Base Runtime module concept
introduced in Fedora 26 Boltron, splitting the minimal system further
into independent modules allowing for greater flexibility when
composing and maintaining the base system.
This change focuses on modular content structure;
[[Changes/ModularRelease]] [
https://fedoraproject.org/wiki/Changes/ModularRelease ] deals with
details regarding modular delivery.
== Detailed Description ==
The end goal of this change is to provide the modular base operating
system content in a way that allows for hardware enablement and
general userspace separation, enabling different update cadence and
life cycles for each of the two parts.
Being the successors of Base Runtime, the two new modules will include
all the content Base Runtime does as well as content from additional
Fedora 26 Boltron modules currently extending it. Additional system
configuration & management services and utilities are expected to be
part of the base system experience, making all the essential content
available for installation from the base level modules that are
enabled by default.
=== Implementation ===
The concept is defined by the following set of objectives and expectations:
* Host and Platform are built and composed as modules, benefiting from
all the modularity pipeline enhancements Factory 2.0 provides and are
distributed with useful module metadata
* The Host part should deliver hardware enablement components such as
the kernel, bootloaders, firmware, possibly additional device drivers
and components closely linked to these
* The Platform part defines the operating system release and includes
various base userspace components ranging from the C library and init
system to system management & deployment tools, container runtime and
possibly several services commonly considered to be part of the base
system experience
* The Host and Platform modules should be independent, making it
possible to run the same Host with different Platforms and vice versa
* Each of the two modules has its own life cycle, update cadence and
versioning scheme
* The Host can only be experienced through the Platform
* The Platform part provides all the content needed to produce
container base images; the Platform can therefore run without the Host
in that scenario
* Both modules are built in a shared, self-hosting buildroot (also
known as the Bootstrap module) providing all the build time
dependencies needed to build the Host and Platform as well as itself
* While independent on the source level, given the shared build
environment the modules' binaries are tightly coupled and the Host
part therefore needs to be built for every supported Platform it's
intended to be distributed with
* The Platform module provides the minimal build environment for
application level modules -- this means that modules built against a
certain version of Platform are built using the Platform compiler;
this doesn't affect what additional compilers are available to the end
users, for example via additional application level modules
=== Modules ===
At minimum the group is going to deliver three modules, one of which
being an implementation detail only that won't be part of the Host and
Platform compose.
* '''The Host''' includes the kernel, bootloaders, firmware, and
components tightly coupled with any of these
* '''The Platform''' includes the C standard library, the init system,
basic system tools, filesystem and networking utilities, system Python
runtime, system management and deployment tools such as dnf and
anaconda, container runtime(s) and possibly additional system services
and components necessary to provide a reasonable base system
environment
* '''The Bootstrap''' module includes a self-hosting package set
needed to build the Host and Platform modules. Host and Platform are
subsets of this module. The binaries are not part of the compose.
This module is also part of Fedora 26 Boltron, defining the buildroot
for Base Runtime and several other modules.
Host and Platform modules might be implemented as simple modules or
module stacks, depending on what provides more practical value. Given
that the content of each will be bound by the same life cycle and
update cadence, we don't expect to split them into sub-units unless
necessary.
The Host module might be a module stack from day one to simplify
packaging of the UEFI bootloader.
The Bootstrap module will be initially created by manually tagging
traditional Fedora binaries into a special purpose, module-like tag.
The module is self-hosting so that it can later rebuild itself, as
well as serve as a base for building future releases, spins, and
derived distributions. Unfortunately it's not possible to build the
new Bootstrap module using the Fedora 26 Boltron version due to the
introduction of a new architecture (s390x) and numerous FTBFS issues.
=== Differences from Base Runtime ===
[[File:Base_Runtime_becomes_Host_and_Platform.png|120px|thumb|right|Base
Runtime becomes Host and Platform]]
Fedora 26 Boltron Base Runtime module was created with a different set
of requirements in mind: it was meant to provide a minimal bootable
environment with hardware enablement, init system, basic system tools
and a minimal package manager. Unlike Host and Platform, Base Runtime
is usable on its own.
Base Runtime is both smaller and larger than Host and Platform -- it
provides the basic functionality of both but the Base Runtime
userspace package set is much smaller than that of the Platform.
== Scope ==
* Proposal owners:
Modularity WG will prepare both modules -- define the generic module
metadata, buildroots, profiles, components and API. The group will
also build the components and will deliver an installer boot image,
container base image and virtual machines built from the Host &
Platform content. The group will also create and maintain additional
modules needed to accomplish these tasks, such as a "self-hosting
buildroot package set" module similar to the one used for building
Base Runtime for Fedora 26 Boltron. The group will assist package
maintainers and release engineering with fixing packaging problems,
component build and module compose issues.
* Other developers:
Package maintainers are expected to fix packaging & build issues
affecting packages they maintain in a timely fashion.
* Release engineering:
#6815 [ https://pagure.io/releng/issue/6815 ]
* List of deliverables:
Modularity & modular compose will be affected.
* Policies and guidelines:
Not needed for this change.
* Trademark approval:
Not needed for this change
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
= Proposed System Wide Change: Modular Release =
https://fedoraproject.org/wiki/Changes/ModularRelease
Change owner(s):
* Ralph Bean < rbean AT redhat DOT com >
The build, release, distribution, and update changes associated with
and required for the [Changes/Modular_Server] and
[Changes/Host_and_Platform] Changes.
== Detailed Description ==
=== Preamble ===
This change is intended to cover the workflow and technical tooling
aspects of a “modular” release for F27.
There are other Changes that are not part of the scope of this Change,
but which are related:
* [[Changes/Modular_Server]] is a proposal to replace the Fedora
Server edition with a modular release for F27.
* [[Changes/Host_and_Platform]] deals with the content of what goes
into the core of the modular release for Fedora Server (the Modular
Server) in F27.
This Change is about how we’re going to get those two other changes
through the infra/build/release tooling.
Client tooling is being worked on (I have seen some cool demos from
the May-June timeframe. Ask about them!), but client tooling is not
part of the scope of this Change proposal.
Note that there currently are no proposals to replace either Fedora
Workstation or Fedora Atomic with modular revisions. This means that
here we cannot move to replace existing workflows wholesale, but have
to look at maintaining the two flows (traditional and modular) in
tandem, for at very least the F27 release cycle.
(The [[Changes/ArbitraryBranching]] change is also related to this
proposal, but not covered in any further detail here.)
=== Builds ===
Module builds for the F27 cycle will look much like they did for the
F26 cycle. No major changes here.
See the F26 Change document for details here, [[Changes/ModuleBuildService]]
As soon as the FPC approves the [[Module:Guidelines]], we can open up
the MBS for use by the general packager group.
'''Dependencies:'''
* We need the Modularity team to take the module guidelines to the
FPC, work through them, and get an agreed-upon version approved.
* We are indirectly dependent on release engineering to create some
initial tags for bootstrapping the host and platform content. This
should be referenced in that Change proposal.
=== Automation ===
Ok, I lied. One thing about builds will change: we’re going to
automate rebuilds with [[Infrastructure/Factory2/Focus/Freshmaker]].
==== Module Rebuilds ====
For '''F26''', if a packager wanted to update an rpm in a module, they would:
* Patch the spec file of that rpm, commit, and push.
* Switch to a checkout of the module that included that rpm, and run
`mbs-build submit` which would kick off the appropriate builds.
* If another module included that same rpm stream, and the packager
forgot about it, then they’re just out of luck.
For '''F27''', we’re working on a system to automate this. The
workflow will be:
* Patch the spec file of an rpm, commit, and push.
* Watch the fireworks.
The freshmaker daemon will notice the commit, then look up all modules
that depend on that rpm stream. It will submit requests to the
module-build-service to build those modules.
We won’t have a nice UI for this for F27, but we will have a JSON API
provided by freshmaker to query and find the list of module builds
that were triggered as a result of your commit (or anyone else’s
commits to any other packages).
There are some exceptions here. We will have a site-wide policy
configured for freshmaker to not do automated rebuilds for a
blacklisted set of modules. This blacklist set must include the
bootstrap module. It includes many thousands of rpm streams and an
update to any one of them would cause a mass-rebuild of (nearly) every
other module. This is too much, so we’ll instead rely on the
bootstrap maintainers and release engineering to only request these
rebuilds via MBS by hand.
==== Container Rebuilds ====
We're approaching container rebuilds in two phases: for short hand,
we're calling them the "slow" flow and the "fast" flow. We'll do the
[https://m.rit.edu/default/video/index?feed=youtube-reporter&id=QPHUTRnWrP4
slow flow] first for F27. The fast flow is a stretch goal for F27,
but will more likely land in F28.
In the '''slow flow''', we automatically kick off rebuilds of
containers when rpms that previously went into those containers are
'''shipped to the updates repo in Bodhi'''. The lag time here can be
around a week to two weeks.
Freshmaker will watch on fedmsg to find when those rpms make it to the
master mirror and will kick off the appropriate builds. The container
rebuild process should already be pulling from that repo; so we should
be good to go.
In the '''fast flow''', we automatically kick off rebuilds of
containers when rpms that previously went into those containers are
'''first added to an update in Bodhi'''. The lag time here can be
quite fast. As soon as you make a specfile patch and the rpms get
built, the update can be created which in turns triggers freshmaker to
kick off container rebuilds.
'''fast flow''' container rebuilds require a yum repository with the
rpms to be available ''before'' they are mashed into the updates repo.
For this, we're building [[Infrastructure/Factory2/Focus/ODCS]]. This
"on demand compose service" will be used by freshmaker to produce
repos of rpm and module content for container rebuilds, as well as
taskotron test runs.
No further details on ODCS here, but it does require non-standard
write access to a subtree of /mnt/koji. We will need support from
Fedora Release Engineering and Fedora Infrastructure in the
request-for-resources ticket for this.
'''Dependencies''':
* We’ll need Fedora Infrastructure to kindly support us through the
request-for-resources process.
* We need Fedora Infrastructure to finish implement service-account
support for OpenID Connect (in ipsilon).
* After that, we need to be granted an OIDC service account so that
freshmaker can submit builds to the module-build service.
* The VM for ODCS will need non-standard write access to a subtree of
/mnt/koji (we don't need to write to the whole thing, just a new
/mnt/koji/compose/odcs/ directory where we can write out temporary
composes).
=== Composes ===
We will continue to do general composes with the same tool - pungi.
* For rawhide, the compose configuration should list the master
streams of all modules to be included in the rawhide compose. The
latest builds in those streams will be included in each nightly
compose: https://pagure.io/pungi-fedora/blob/master/f/variants-modular.xml
* For branched, the compose configuration should list f27 streams of
all modules to be included in the F27 server compose. The latest
builds in those streams will be included in each nightly compose.
* For the alpha and beta candidates, release engineering will need to
pin the versions of the module streams in the variants-module.xml file
in the f27 branch of the pungi-fedora repo. This will allow them to
stabilize the release and allow for systematic QA and go/no-go
decisions.
As mentioned in the automation section above, we're introducing a new
tool called the ODCS to generate temporary, throwaway composes for
automated testing and automated layered image creation.
'''Dependencies''':
* The image building work from F26. For F26 "Boltron", we wanted to
produce base images but ran into more issues than expected. Most all
of those are resolved now. Full completion of that work (being able
to produce base images in koji via pungi from modular content) is a
hard requirement for F27, where it was a soft requirement for F26.
* The variants files for F27. The Factory2 team will produce these
and submit them to release-engineering's pungi-fedora repo. Releng
will need to review and eventually merge.
* As the beta cycle unfolds, Release Engineering will need to freeze
the module versions in variants-modular.xml, adding in new versions
only to address blocker bugs (like how we do today with the
f26-compose tag).
=== Updates ===
Updates to the (modular) Fedora Server release will be managed by Bodhi.
Fun facts:
* The Bodhi database model now has multi-type (modular) support.
* The Bodhi API now has multi-type (modular) support.
* The Bodhi bindings and CLI and web UI now have multi-type (modular) support.
The only thing left to do is (take a deep breath) the masher.
See [[Infrastructure/Factory2/Focus/Bodhi]] for how to plan to handle
the '''code changes''' to Bodhi.
As for '''configuration''', we’re going to need to be able to mash
updates for traditional style Fedora Workstation and Fedora Atomic
while also mashing updates for (Modular) Fedora Server.
We will need:
* f27-updates, f27-updates-testing and all the normal associated
-pending and -candidate tags for Workstation and Atomic. The F27
“release” in Bodhi’s database will point at this tags, as per usual.
* f27-modular-updates, f27-modular-updates-testing, and similar kinds
of -pending and -candidate tags for Server. We will then need to
additionally create a separate Modular F27 “release” in Bodhi’s
database that points to those tags.
The masher will produce separate modular-updates and
modular-updates-testing repos alongside the traditional updates and
updates-testing repos.
Note - the work we've already done here paves the way for containers
in Bodhi, but a workflow that has layered image updates passing
through Bodhi is likely not in the cards for F27. Someone will have
to take it up for F28.
'''Dependencies''':
* We need the content generator flags enabled in koji for the MBS (see
https://pagure.io/releng/issue/6799 ).
* We need the tags hierarchy created for modular updates.
* We need the release created in the bodhi DB (for the modular repos)
at the same time that the traditional release is created.
* Release-engineering runs the push command. There will inevitably be
problems with the first iteration of our modularized bodhi masher.
Please work with the Factory2 team to solve them as we move forwards
with the release.
=== Mirrors ===
We don’t expect that mirroring this content will require any changes
to mirrormanager or mirrorlist.
We will be creating an extra compose and an extra set of updates
repos, but there are no fundamental changes to the mirroring process.
We will have an additive increase in load on mirrors, but no an
exponential one.
There has been lots of worry here. Let me explain. Once upon a time,
we thought that (with Modularity) we would distribute every version of
every module ever built. Users could switch between any of them, at
any time, since they would all be available on the mirrors. This
would explode our storage ask of the mirror volunteers.
But, this is not how our modularized bodhi masher will work. We will
distribute multiple streams of the same rpms, but we will not retain
or mirror multiple versions of the same stream. Only the latest
builds of a module stream will be included in the updates repo, not
every version we ever built.
The F27 server compose should go exactly where it would normally go in
the published tree.
The F27 modular-updates repos should sit right next to the traditional
updates and updates-testing repos.
== Scope ==
* Proposal owners:
We have to finish and deploy freshmaker, our bodhi changes, including
changes to pungi. We'll be actively working with the infrastructure
and releng teams on deployment and configuration.
* Other developers:
Is there any work required of other developers? No. They will still be
able to use the "traditional" workflow to build and ship content for
Fedora Workstation and Fedora Atomic. To participate in the
development of Fedora Server, they'll need to learn how to create new
modules (the module guidelines should cover this).
* Release engineering:
ticket #6852 [https://pagure.io/releng/issue/6852]
* List of deliverables:
I don't think anything on this list changes. See [[Changes/Modular_Server]].
* Policies and guidelines:
See [[Changes/Modular_Server]].
* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
OVERVIEW
========
As the modularity work starts to enter Fedora with the Fedora 27
release, a typical Change Proposal did not seem to do justice on
capturing the moving parts and dependencies for the work to successfully
land. As a result, this document attempts to capture, at a high level,
the goals and deliverables for F27. We are also providing links to the
details to most aspects. Some of the details are still in progress and
will change over the F26 lifecycle (e.g. which modules will be included
for F27 Server).
THE GOAL
========
The Modularity and Server Working Groups plan, with the help of many
other groups in Fedora, to deliver a fully modularized version of the
Fedora Server Edition. As an equal and complementary goal, the tooling
for module creation/development, deployment and automatic testing will
be as simple and automated as possible.
[*Change*](https://fedoraproject.org/wiki/Changes/Modular_Server)
CAVEATS
=======
- Although modularity allows for lifecycle changes, there is no plan
for anything besides the normal 13 month lifecycle at this point.
- Available content as modules will be less than a typical Server release
- Only components that are a part of a module will be available
- Any RPM that is a part of module will be available to be
installed directly or in addition to the “install profile” install of
the module
ASPECTS TRACKED
===============
- Infrastructure Changes/Improvements:
- Bodhi: changes to support updating & tracking modules:
[*Change*](https://fedoraproject.org/wiki/Changes/ModularRelease)
- Arbitrary branching: enables modules to versions bound to
something other than Fedora release number:
[*Change*](https://fedoraproject.org/wiki/Changes/ArbitraryBranching)
- Bugzilla & ABRT module-awareness are still in progress
- COPR: support for building modules has been added and will be
improved over the F26 cycle
- Automation (Freshmaker)
- On Demand Compose Service (for testing and container rebuilds)
- Greenwave: for policy/gating in Bodhi. User interactions
take place in Bodhi.
- Installation & System Management
- Anaconda: still in progress
- DNF: Work underway to support modules, additional features need
to be added. Please report comments/features/bugs in the [*normal
manner*](https://github.com/rpm-software-management/dnf/wiki/Bug-Reporting).
- Gnome Software: still in progress
- Host & Platform module(s): Base components that provide the
“operating system” aspects of Modular Fedora:
[*Change*](https://fedoraproject.org/wiki/Changes/Host_and_Platform),
[*Content tracker*](https://github.com/fedora-modularity/hp)
- Application modules ([*Content
Tracking*](https://github.com/fedora-modularity/f27-content-tracking))
- TBD language modules (1 or more versions each)
- TBD database modules (1 or more versions each)
- TBD web server modules (1 or more versions each)
- TBD utility server modules (1 or more versions each)
- Applications as System Containers ([*Content
Tracking*](https://github.com/fedora-modularity/f27-content-tracking))
- TBD system integrated containers
- Module Guidelines and Processes:
[*Ticket*](https://pagure.io/Fedora-Council/tickets/issue/123)
- HowTos, Examples, and Tools for Modules:
[*Website*](https://docs.pagure.org/modularity/)
BENEFITS FOR USERS
==================
- Content available in multiple streams - good examples needed
- Software Collections done the right way - Languages, Databases
- No visible change to dnf/yum unless you want to select non-default
versions
FURTHER DETAILS
===============
- [*Bodhi
Milestone*](https://github.com/fedora-infra/bodhi/milestone/4) for
Modularity
- Bodhi Changes [*Focus
document*](https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/Bod…
- Freshmaker Focus doc
[*https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/Freshmaker*](https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/Freshmaker)
- ODCS Focus doc
[*https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/ODCS*](https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/ODCS)
- Branching Focus doc
[*https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/ArbitraryBranching*](https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/ArbitraryBranching)
Langdon White
Fedora Modularity Objective Lead
= Proposed Self Contained Change: Remove krb5-appl =
https://fedoraproject.org/wiki/Changes/Remove_krb5-appl
Change owner(s):
* Robbie Harwood (rharwood) <rharwood at f p dot o >
Remove src:krb5-appl (produces packages krb5-appl-clients and
krb5-appl-servers) from the distribution.
== Detailed Description ==
These packages will likely be officially deprecated upstream soon, and
probably should not be used in most cases anyway. It contains legacy
kerberized utilities, like rsh. There are no packages which depend
them. There have been no changes to this package in Fedora since 2013,
and no new capabilities upstream since 2010 when it branched from the
mainline krb5 distribution.
== Scope ==
* Proposal owners:
To implement this Change proposal.
* Other developers:
N/A (not a System Wide Change)
* Release engineering:
https://pagure.io/releng/issue/6854
* List of deliverables:
N/A (not a System Wide Change)
* Policies and guidelines:
N/A (not a System Wide Change)
* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic