Fedora 24 Final Release Readiness Meeting on Thursday, June 9th @
19:00 UTC
by Jan Kurik
This Thursday, we will meet on irc.freenode.net in #fedora-meeting-1
to make sure we are coordinated and ready for the release of Fedora 24
on Tuesday, June 14th, 2016.
Please note that this meeting will occur even if the release is
delayed at the Go/No-Go meeting on the same day two hours earlier.
The meeting is scheduled at 19:00 UTC. Please follow the [FedoCal]
link to find the time of the meeting in your time-zone.
[FedoCal] https://apps.fedoraproject.org/calendar/meeting/4105/
You may received this message several times as this meeting is opened
to all teams. I also hope this will raise awareness and more team
representatives will come to this meeting. This meeting works best
when we have representatives from all of the teams.
Thanks for attending,
Jan
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
7 years, 10 months
F25 Self Contained Change: Fedora Scale-Out Docker Registry
by Jan Kurik
= Proposed Self Contained Change: Fedora Scale-Out Docker Registry =
https://fedoraproject.org/wiki/Changes/FedoraDockerRegistry
Change owner(s):
* Adam Miller <maxamillion AT fedoraproject DOT org>
This is a proposal for a change to the Fedora Infrastructure and
Fedora Release Engineering tooling to provide a scalable Docker
Registry solution for Fedora that is integrated with the Fedoar Docker
Layered Image Build Service.
== Detailed Description ==
Change Wrangler note: as the Change description is quite complex,
please check the Change page for the details.
== Scope ==
* Proposal owners
- Implement the proposed Design of a Scaled-Out Docker Registry
-- Deploy Pulp
-- Deploy Crane
-- Deploy Docker-Distribution Registry
-- Integrate with MirrorManager for content distribution
- Document the system
(Change Wrangler note: as the Scope section is quite complex, please
check the Change page for the details)
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
7 years, 10 months
F25 Self Contained Change: Release Engineering Automation Workflow Engine
by Jan Kurik
= Proposed Self Contained Change: Release Engineering Automation
Workflow Engine =
https://fedoraproject.org/wiki/Changes/ReleaseEngineeringAutomationWorkfl...
Change owner(s):
* Adam Miller <maxamillion AT fedoraproject DOT org>
Centralized entry point, logging, and dash board for pre-defined
Automated Workflow tasks used by the Release Engineering team with
delegation and self-service tasks for members of various teams who
normally depend on Release Engineering for various tasks.
== Detailed Description ==
Currently Fedora Release Engineering Automation tasks are performed by
various scripts run on various machines within the Fedora
Infrastructure with no real centralized logging. Some of these are
automated by chron jobs and some run by hand by request of various
members within the Fedora Community, normally around Fedora Test Days.
Finding information about old tasks is not always the easiest of
things to do and the delegation of tasks is currently not available.
The goal here is to provide a solution that removes those barriers.
Workflows will be executed and potentially orchestrate actions between
multiple other systems or tools such as bodhi, pungi, and koji.
Fedmsgs will be emitted with information about the start and
completion of workflows along with metadata about them.
In the event of a compose, certain fedmsg output will be picked up by
taskotron and autocloud to perform various levels of testing.
(Change Wrangler note: as the section is quite complex, please check
the Change page to get more details)
== Scope ==
* Proposal owners shall have to:
- Determine what the "Engine" will be after evaluation and working
with the Fedora RelEng and Infrastructure teams for advisement.
- Deploy RelEng Automation Workflow Engine
-- Fully automated deployment in Fedora Infrastructure Ansible
- Document Workflow Automation
-- How workflows are created
-- How to run workflows
-- How new contributors can get started
* Release engineering
- Deploy the "Engine"
* Policies and guidelines
- Need to determine who can create/run workflows
- Define guidelines for writing workflows
(Change Wrangler note: as the Scope section is quite complex, please
check the Change page to get more details)
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
7 years, 10 months
F25 Self Contained Change: The GNU C Library version 2.24
by Jan Kurik
= Proposed Self Contained Change: The GNU C Library version 2.24 =
https://fedoraproject.org/wiki/Changes/GLIBC224
Change owner(s):
* Carlos O'Donell <carlos AT redhat DOT com>
Switch glibc in Fedora 25 to glibc version 2.24.
== Detailed Description ==
The GNU C Library version 2.24 will be released at the beginning of
August 2016; we have started closely tracking the glibc 2.24
development code in Fedora Rawhide and are addressing any issues as
they arise. Given the present schedule Fedora 24 will branch after the
GLIBC 2.24 upstream release.
In addition, we plan the following packaging changes:
* Split NSS (Name Service Switch) modules into separate RPM
subpackages (#1338889)
* Leave assertions enabled (#1338887)
* Use one program to implement sln and ldconfig (#1315476)
* Provide a libcrypt implementation not based on libfreebl3.so (#1324623)
== Scope ==
* Proposal owners: Update glibc to 2.24 from tested upstream release.
* Other developers: Aside from Carlos O'Donell <carlos AT redhat DOT
com>, Florian Weimer <fweimer AT redhat DOT com>, Torvald Riegel
<triegel AT redhat DOT com>, Martin Sebor <msebor AT redhat DOT com>,
and Patsy Franklin <pfrankli AT redhat DOT com>, no other developers
are required. These developers need to ensure that rawhide is stable
and ready for the Fedora 24 branch. Given that glibc is backwards
compatible and we have been testing the new glibc in rawhide it should
make very little impact when updated.
* Release engineering: In general coordination with release
engineering is not required. A mass rebuild is not required.
* Policies and guidelines: The policies and guidelines do not need to
be updated.
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
7 years, 10 months