F24 System Wide Change: Systemd file triggers
by Jan Kurik
= Proposed System Wide Change: Systemd file triggers =
https://fedoraproject.org/wiki/Changes/systemd_file_triggers
Change owner(s):
Zbigniew Jędrzejewski-Szmek <zbyszek AT in DOT waw DOT pl>
systemd daemon-reload is invoked once or twice per rpm transaction.
== Detailed Description ==
Instead of having every package which carries a systemd unit call
systemctl daemon-reload on its own, systemd is reloaded just once
after installation of all packages, using rpm file triggers on
/usr/lib/systemd/system, /etc/systemd/system.
Packages still have to call systemctl preset as necessary, and
try-restart on their own unit if appropriate. RPM macros provided by
systemd are modified to remove all calls to daemon-reload from them.
No changes to packages using those macros are required, but a rebuild
is necessary to remove the calls to systemctl daemon-reload.
== Scope ==
Proposal owners:
* Update the macros provided by systemd and add appropriate file triggers.
Other developers: potentially rebuild some packages.
Release engineering: N/A
List of deliverables: N/A
Policies and guidelines: N/A
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
8 years, 5 months
F24 System Wide Change: GHC 7.10
by Jan Kurik
= Proposed System Wide Change: GHC 7.10 =
https://fedoraproject.org/wiki/Changes/GHC_7.10
Change owner(s):
Jens Petersen <petersen AT redhat DOT com >
Update Fedora's version of the GHC Haskell compiler to version 7.10.
== Detailed Description ==
GHC 7.10 is major new version of the de facto standard Haskell
compiler released in 2015. This change involves updating ghc and
associated packages and updating and rebuilding all the Haskell
packages in Fedora built with ghc.
== Scope ==
Proposal owners:
* Create a Koji f24-ghc side tag for building all the packages,
including also secondary architectures
* Update ghc and ghc-rpm-macros
* Update and rebuild all the Haskell packages in the side tag
* Once building is complete move all the side tag builds to Rawhide
(before F24 branches)
Other developers: None
* A few packages outside the Haskell SIG may need an update to build
with ghc-7.10, but the Haskell SIG can provide assistance if needed.
Release engineering:
* Sidetag and secondary architecture building will need assistance
from release-engineering.
List of deliverables:
* N/A (not a System Wide Change)
Policies and guidelines:
* None
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
8 years, 5 months
Reminder: Fedora 21 end of life on 2015-12-01
by Kevin Fenzi
Greetings.
This is a reminder email about the end of life process for Fedora 21.
Fedora 21 will reach end of life on 2015-12-01, and no further updates
will be pushed out after that time. Additionally, with the recent
release of Fedora 23, no new packages will be added to the Fedora 21
collection.
Please see https://fedoraproject.org/wiki/DNF_system_upgrade for more
information on upgrading from Fedora 21 to a newer release.
kevin
8 years, 5 months
Migration of the mailing-lists to Mailman3 and HyperKitty
by Aurelien Bompard
Dear list users,
The Fedora Engineering team has been working on a new system for our
mailing lists. Mailman 3 came out earlier this year and it has a new
shiny web UI: HyperKitty.
The Fedora Hosted lists will be migrated on November 16th, and the
Fedora project lists later in the week. After migration you should be
able to use the new hyperkitty UI to post and read the lists if you
choose or continue to get emails in the traditional way.
There may be some changes in some headers, so if you filter your list
emails be ready to adjust your filters. See wiki page below for
details:
http://fedoraproject.org/wiki/Mailman3_Migration
Some lists using mailman2 features not yet available in mailman3 will
be migrated later. More information as well as current lists migrated,
being migrated and deferred for migration can be found at:
http://fedoraproject.org/wiki/Mailman3_Migration/Status
If you have any questions, feel free to ask on the infrastructure
list: infrastructure(a)lists.fedoraproject.org.
If you find a problem or issue, please file a fedora infrastructure
ticket and we will work to fix things for your case or bug:
https://fedorahosted.org/fedora-infrastructure/
The Fedora Infrastructure team
8 years, 5 months
F24 Self Contained Change: Product Definition Center
by Jan Kurik
= Proposed Self Contained Change: Product Definition Center =
https://fedoraproject.org/wiki/Changes/ProductDefinitionCenter
Change owner(s): Ralph Bean <rbean at redhat dot com>
The Product Definition Center (PDC) is a webapp and API designed for
storing and querying product metadata. We want to stand up an instance
in Fedora Infrastructure and automatically populate it with data from
our existing releng tools/processes. It will enable us to develop more
sane tooling down the road for future releases.
== Detailed Description ==
We need something more sophisticated than we have now to model releng
processes. Right now, we have a collection of shell scripts, python
bits, and koji tasks that all know "how to do" whatever it is that
needs to be done. Whatever artifacts they produce, is what we produce.
When we introduced new types of artifacts (server/cloud/workstation,
vagrant, docker, atomic, etc..) as requirements for releng in the past
few years, we started to strain the existing processes. Those scripts
became much more complicated and difficult to debug.
Long term, we would like to move to a more structured architecture for
releng workflow, one that uses basic software engineering paradigms,
like MVC. To start on that journey, we're looking to deploy something
which can serve just as the M there (the Model).
With such a thing, we could rewrite some of our scripts to behave
dynamically in response to state of the model. In the best case
scenario (read: utopia), we would simply define a new variant of a
deliverable in the model, and our tools would produce it. (Of course,
things will involve more work than that).
== Scope ==
Note that this change should not affect any other development efforts.
It does not require new instrumentation of any of our existing tools
and so, should it fail as a project, there is no need for a
contingency plan to back things out -- we can just abandon it.
* Proposal owners:
- Set up a devel instance of PDC (already done here).
- Write pdc-updater, the daemon that updates PDC with data from our
existing toolchain (via fedmsg).
- Write an audit script that checks that PDC's data is consistent.
- Set up and deploy staging and production instances of PDC and
pdc-updater in fedora-infra.
- Run the audit scripts to ensure that PDC's knowledge is consistent
with the actual state of our release infra.
- Install the audit script in cron (or something) and attach it to a
nagios alert, so we're made aware of inconsistencies.
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (not a System Wide 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
8 years, 5 months