= Proposed Self Contained Change: Ansible python3 default =
https://fedoraproject.org/wiki/Changes/Ansible_python3_default
Owner(s):
* Kevin Fenzi <kevin at scrye dot com>
Ansible started out as a python2 only application, but in recent years
a large amount of work has gone into porting things to python3. Last
year, the Fedora ansible package started shipping a ansible-python3
allowing users to switch to python3 on the control host easily if they
wished, but left the default as python2. Now in Fedora 29, the default
will be switched and the python3 version will be the only version
shipped.
== Detailed description ==
The Fedora ansible package will be changed to default to python3 with
the 'ansible' package. Note that this change is on the control host,
you can control what python is used on target hosts via your
inventory. You may continue to use python2 there, or use python3 as
your target hosts require.
== Scope ==
* Proposal owners:
Modify ansible package (already done)
* Other developers:
N/A (not a System Wide Change)
* Release engineering:
#releng-7414 https://pagure.io/releng/7414
** 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: Stop building 389-ds-base on i686 =
https://fedoraproject.org/wiki/Changes/389-ds-base-remove-686
Owner(s):
* Mark Reynolds <mreynolds at redhat dot com>
389-ds-base does not work properly on i686 hardware in regards to atomic types.
== Detailed description ==
389-ds project have found an issue which causes system instability on
all versions of 1.4.x of the server on i686 platform. This is a
hardware limitation of the platform related to how we consume atomic
types. This may lead to thread unsafety and other issues.
- FreeIPA server will not be available on i686 due to this
- slapi-nis set of plugins will not be available on i686 due to this
- Upgrade of i686 instance of Fedora with FreeIPA server will not be
possible without fully uninstalling FreeIPA replica
== Scope ==
* Proposal owners:
This only requires a change to spec file to exclude i686
* Other developers:
N/A (not a System Wide Change)
* Release engineering:
#6894: https://pagure.io/releng/issues/6894
** 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
I'm going to extend this by a week and cancel tomorrow's Server SIG
meeting. People have been very distracted with dealing with Beta blockers
and we've extended this request to a wider audience (it got picked up by
certain news sources). Let's give it a little more time to percolate.
If you have thoughts, I'd really like to hear them.
On Mon, Mar 26, 2018 at 8:04 AM Stephen Gallagher <sgallagh(a)redhat.com>
wrote:
> Quick reminder to please send me your thoughts on this; I'll be collating
> them tonight and sending them out for us to discuss tomorrow.
>
>
> On Tue, Mar 20, 2018 at 4:58 PM Stephen Gallagher <sgallagh(a)redhat.com>
> wrote:
>
>> During today's Server SIG IRC meeting[1], we discussed plans for Fedora
>> 29 and onwards. In particular, we've decided that we're probably going to
>> retire the concept of "server roles" from our overall goals. Adam
>> Williamson -- representing Fedora QA -- raised the point that the related
>> release criteria and test goals come directly from the Fedora Server
>> Product Requirements Document (PRD) [2]. He correctly pointed out that we
>> should start by revising the PRD and have that filter down ultimately into
>> the release criteria.
>>
>> Looking at the Fedora Wiki, the Fedora Server PRD is now over four years
>> old and thus is ripe for an update. To that end, we're going to start with
>> a brainstorming exercise to update our Mission Statement. The current
>> statement reads:
>>
>> Fedora Server is a common base platform with "featured server roles"
>> built on top of it. We commit to produce, test, and distribute these server
>> roles.
>>
>> Clearly, this is no longer going to work for us, since we're planning to
>> retire the server role concept. So what I'd like is this: If you are
>> reading this, I'd like you to send me your view of what the
>> purpose/goals/efforts of Fedora Server should be over the next 2-3 years
>> (or even longer). I would ask that you send your thoughts directly to me,
>> not as a reply on the list. This is so as not to influence anyone else's
>> answers or to start a debate before the brainstorming is concluded. I will
>> gather the responses and send them back out to the list as a complete set
>> on Monday. The floodgates should then open to try to find the common
>> elements and start turning them into an actionable strategy (the discussion
>> will also continue at the Server SIG meeting on Tuesday).
>>
>> Once that discussion settles down, I will take the major points we come
>> to agreement on and start putting together a draft of a new Products
>> Requirement Document. We can then discuss and tweak the PRD up to the
>> Fedora 29 System-Wide Change Proposal deadline, at which point the Server
>> SIG will submit its F29 Changes to FESCo.
>>
>> Thank you all in advance for your help with this.
>>
>>
>> [1]
>> https://meetbot.fedoraproject.org/fedora-meeting-1/2018-03-20/serversig.201…
>> [2] https://fedoraproject.org/wiki/Server/Product_Requirements_Document
>>
>>
>>
= Proposed System Wide Change: Ruby on Rails 5.2 =
https://fedoraproject.org/wiki/Changes/Ruby_on_Rails_5.2
Owner(s):
* Pavel Valena <pvalena at redhat dot com>
* Vít Ondruch <vondruch at redhat dot com>
* Jun Aruga <jaruga at redhat dot com>
Ruby on Rails 5.2 is the latest version of well known web framework
written in Ruby.
== Detailed description ==
The Ruby on Rails stack is evolving quickly and Fedora needs to keep
pace with it. Therefore the whole Ruby on Rails stack should be
updated from 5.1 in Fedora 28 to 5.2 (latest version) in Fedora 29.
This will ensure that all the Ruby developers using Fedora have the
latest and greatest RPM-packaged Ruby on Rails.
== Scope ==
* Proposal owners:
** The whole Rails stack has to be updated
** Some dependencies of the Rails stack will need update
=== Packages need to be created/updated ===
- rubygem-activestorage - Create package
- rubygem-actioncable - Update to 5.2.x
- rubygem-actionmailer - Update to 5.2.x
- rubygem-actionpack - Update to 5.2.x
- rubygem-actionview - Update to 5.2.x
- rubygem-activejob - Update to 5.2.x
- rubygem-activemodel - Update to 5.2.x
- rubygem-activerecord - Update to 5.2.x
- rubygem-activesupport - Update to 5.2.x
- rubygem-rails - Update to 5.2.x
- rubygem-railties - Update to 5.2.x
- rubygem-arel - Update to 9.0.x
* Other developers:
Update Rails dependent packages to be working with Ruby on Rails 5.2
* Release engineering:
#7410 https://pagure.io/releng/issue/7410
**List of deliverables:
None
* Policies and guidelines:
Not needed
* Trademark approval:
Not needed
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
Release status of the Fedora 28 Beta is NO-GO.
Due to missing RC for the F28 Beta release and presence of blocker
bugs, the decision is “No Go”. The Beta release slips for one week to
“Target #1” date (April 3rd). We are not going to slip the Final GA
yet.
For more information please check the minutes from the F28 Beta
Go/No-Go meeting [1][2].
[1] https://meetbot.fedoraproject.org/fedora-meeting-1/2018-03-22/f28-beta-go-n…
[2] https://meetbot.fedoraproject.org/fedora-meeting-1/2018-03-22/f28-beta-go-n…
Regards,
Jan
--
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: Python 3.7 =
https://fedoraproject.org/wiki/Changes/Python3.7
Owner(s):
* Charalampos Stratakis <cstratak at fedoraproject dot org>
* Miro Hrončok <churchyard at fedoraproject dot org>
* Tomáš Orsava <torsava at fedoraproject dot org>
* Petr Viktorin <pviktori at fedoraproject dot org>
Update the Python 3 stack in Fedora from Python 3.6 to Python 3.7.
== Detailed description ==
Python 3.7 adds numerous features and optimizations. See the upstream
notes at https://www.python.org/dev/peps/pep-0537/#features-for-3-7
and https://docs.python.org/3.7/whatsnew/3.7.html .
=== Important dates ===
* 2018-05-21 Python 3.7.0 candidate 1
* 2018-06-04 Python 3.7.0 candidate 2 (if necessary)
* 2018-06-15 Python 3.7.0 final
* 2018-07-11 Fedora 29 Mass Rebuild
* 2018-08-14 Fedora 29 Change Checkpoint: Completion deadline (testable)
(From https://www.python.org/dev/peps/pep-0537/#schedule and
https://fedoraproject.org/wiki/Releases/29/Schedule .)
=== PEP 552 – Deterministic pycs ===
One change is notable from the packaging viewpoint:
https://www.python.org/dev/peps/pep-0552/ – “Deterministic pycs”. We
may decide to use the new UNCHECKED_HASH mode, which would mean that
bytecode cache is not validated on import, i.e. changing a
RPM-installed *.py file manually will have no effect (unless the
corresponding __pycache__/*.pyc is updated or removed).
== Scope ==
We will coordinate the work in a side tag and merge when ready.
* Proposal owners:
*# Retire python37 from F29+
*# Update python3 to what was in python37
*#* Mass rebuild all the packages that BR python3/python3-devel...
(~2300 listed in [http://fedora.portingdb.xyz/ Python 3 Porting
Database for Fedora])
*# Reintroduce python36 from Fedora 25. Update it to have all fixes
and enhancements from python3 in Fedora 28 (or 29 before this change)
* Other developers:
Maintainers of packages that fail to rebuild during the mass rebuild
will be asked, using bugzilla, to fix or remove their packages from
the distribution. If any issues appear, they should be solvable either
by communicating with upstreams first and/or applying downstream
patches. Also the package maintainers should have a look at:
https://docs.python.org/3.7/whatsnew/3.7.html#porting-to-python-3-7 .
And python-maint team will be available to help with fixing issues.
* Fedora QA:
Based on some troubles with the
https://fedoraproject.org/wiki/Changes/Python3.6 , we'd like to have
an ack from QA before we merge the side tag.
* Release engineering:
https://pagure.io/releng/issue/7390
A targeted rebuild for all python packages will be required, before
the mass rebuild.
** List of deliverables:
nope
* Policies and guidelines:
nope
* Trademark approval:
nope
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
Join us on irc.freenode.net in #fedora-meeting-1 for this important
meeting, wherein we shall determine the readiness of the Fedora 28
Beta.
The meeting is going to be held on Thursday, March 22, 2018 at 17:00
UTC. Please check the [1] link for your time zone.
Before each public release Development, QA and Release Engineering
meet to determine if the release criteria are met for a particular
release. This meeting is called the Go/No-Go Meeting. Verifying that
the Release criteria are met is the responsibility of the QA Team.
Release Candidate (RC) availability and good QA coverage are
prerequisites for the Go/No-Go meeting. If you have any bug on the
list, please help us with Beta release. If we won't be ready by
Thursday, we will use this meeting to review blockers and decide what
to do.
In the meantime, please keep also an eye on the Fedora 28 Beta Blocker list [2].
For more details about this meeting please follow the [3] link.
[1] https://apps.fedoraproject.org/calendar/meeting/8824/
[2] http://qa.fedoraproject.org/blockerbugs/milestone/28/beta/buglist
[3] https://fedoraproject.org/wiki/Go_No_Go_Meeting
Thank you in advance 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
Join us on irc.freenode.net in #fedora-meeting-1 for the Fedora 28
Beta Release Readiness Meeting meeting.
The meeting is going to be held on Thursday, March 22, 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 Beta
release of Fedora 28. 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.
[1] https://apps.fedoraproject.org/calendar/meeting/8823/
[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
Hi all,
Today I am writing to announce some changes in Fedora Release
Engineering. Effective Friday the 23rd of March 2018 Mohan Boddu will
be taking over as the primary person responsible for Release
Engineering in Fedora. Mohan has effectively been the primary person
since Fedora 26 as he has been doing most of the work. I will be
taking on a new role within Red Hat, and will no longer be in the
internal Release Engineering team.
Going forward Mohan will be supported by Suzanne Yeghiayan as project
manager for release engineering. All requests for work should go though
pagure[1] or taiga[2] to be groomed, prioritised and scoped.
I have posted a blog post[3] with some of my thoughts in reflection
looking back at the last 8 or so years.
Thank you all for you support over the years and your continued support
of Mohan and the rest of the Release Engineers in Fedora.
Dennis
[1] https://pagure.io/releng
[2] https://taiga.fedorainfracloud.org/project/acarter-fedora-docker-at
omic-tooling/
[3] https://ausil.us/wordpress/?p=143