devel-announce June 2017

devel-announce@lists.fedoraproject.org

9 participants
30 discussions

Fedora 26 Final Release Readiness Meeting on Thursday, July 6th @ 19:00 UTC
by Jan Kurik 30 Jun '17

30 Jun '17

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

1 0

F27 Self Contained Change: Samba AD
by Jan Kurik 29 Jun '17

29 Jun '17

= 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

1 0

F27 Self Contained Change: Remove SSH-1 from OpenSSH clients
by Jan Kurik 28 Jun '17

28 Jun '17

= 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

1 0

Fedora 26 Final Freeze
by Mohan Boddu 27 Jun '17

27 Jun '17

Hi all, Today, June 27th 2017, is an important day on the Fedora 26 schedule [1], with significant cut-offs. Today we have the Final Freeze [2]. This means that only packages which fix accepted blocker or freeze exception bugs [3][4][5] will be marked as 'stable' and included in the Final composes. Other builds will remain in updates-testing until the Final release is approved, at which point the Final freeze is lifted and packages can move to the 'updates' repository, pending updates will be pushed before final release as zero day updates. [1] https://fedoraproject.org/wiki/Releases/26/Schedule [2] https://fedoraproject.org/wiki/Milestone_freezes [3] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process [4] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process [5] https://qa.fedoraproject.org/blockerbugs/milestone/26/final/buglist Regards, Mohan Boddu

1 0

Planned Outage: fedora infrastructure cloud / copr reboots - 2017-06-26 21:00 UTC
by Kevin Fenzi 26 Jun '17

26 Jun '17

There will be an outage starting at 2017-06-26 21:00 UTC, which will last approximately 4 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2017-06-26 21:00 UTC' Reason for outage: We will be applying updates and rebooting the fedorainfracloud. This will affect copr builds, frontend and backend as well as any other applications hosted in the cloud.fedoraproject.org or fedorainfracloud.org domains. Affected Services: copr: frontend, backend and builds. *.fedorainfracloud.org and cloud.fedoraproject.org development and test instances. fedora magazine (fedoramagazine.org) and community blog (communityblog.fedoraproject.org) Contact Information: Ticket Link: https://pagure.io/fedora-infrastructure/issue/6135 Please join #fedora-admin or #fedora-noc on irc.freenode.net or add comments to the ticket for this outage above.

1 0

F27 System Wide Change: Modular Server
by Jan Kurik 26 Jun '17

26 Jun '17

= 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

1 0

F27 System Wide Change: Host and Platform
by Jan Kurik 26 Jun '17

26 Jun '17

= 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

1 0

F27 System Wide Change: Modular Release
by Jan Kurik 26 Jun '17

26 Jun '17

= 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

1 0

Fedora Modules & Fedora 27 Server Edition (Changes)
by langdon 25 Jun '17

25 Jun '17

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

1 0

F27 Self Contained Change: Remove krb5-appl
by Jan Kurik 23 Jun '17

23 Jun '17

= 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

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce June 2017