devel-announce December 2017

devel-announce@lists.fedoraproject.org

7 participants
15 discussions

Modularity is Dead, Long Live Modularity!
by Stephen Gallagher 19 Dec '17

19 Dec '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Modularity is Dead, Long Live Modularity! ========================================= See this post in glorious technicolor at:https://communityblog.fedoraproject.org/modularity-dead-long-live-modula… Summary - ------- Fedora’s Modularity initiative aims to make it easy for packagers to create alternative versions of software and for users to consume those streams simply. We’ve been working on this for several years, resulting in the “Boltron” prototype this summer and the recent Fedora Modular Server beta. Feedback shows that these test releases didn’t meet the goal, and we’re incorporating that in a modified design which we think _will_. We plan to demo the new approach by DevConf.cz and FOSDEM. Retrospective - ------------- As you have probably read, the members of the Modularity Working Group and the Server Working Group decided that the current implementation of Modularity would not meet Fedora’s standard of excellence in time for a release in Fedora 27 — even with the extra time that the Fedora Council granted to the project. In particular, feedback received from the Fedora 27 Modular Server Beta release alerted us to several serious problems in the design. The most common feedback from users was: “How do I install package `foo` in Modular Server?”. In this case, `foo` ranged across a wide variety of software, including everything from the screen package to complex third-party applications. In that version of Modularity, a system was either all Modular or none of it was. To make software available in the fully-modular system, its packages needed to be part of a module — and unfortunately, we didn’t succeed in making many of those. The lack of available modules was a symptom of a larger problem with packager involvement. Some of this problem was due to disagreements with the implementation or design, and some of it was because creating modules turned out to be more time-consuming and had a steeper learning curve than we wanted. Additionally, the whole process was not obvious or well-socialized. The team produced a lot of documentation, but packagers needed to understand a whole lot of it before even getting started. As a result, all of the modules slated for delivery in F27 Modular Server were being developed by the Modularity team, a group that had limited expertise around many of the packages we desired to ship. There were other problems, of course. We didn’t really have a strong plan for how to handle upgrades from traditional deployments. We lacked a story for how third-party software should be loaded onto the system. And, we never got away from needing a “bootstrap” module (as explained below). So, we decided not to ship Modular Server in Fedora 27, and we activated our fallback plan of releasing Fedora 27 Server Edition in its classic incarnation at https://getfedora.org/server/. Moving Forward - -------------- With all of this in mind, we took Modularity back to the drawing board (or perhaps “chopping board”). We analyzed the various functionality that the design offered us and made some trade-offs. First and foremost, we gave up on the idea of a strictly-maintained, stable buildroot. Traditional Fedora builds are performed by building an RPM in a buildroot containing the latest packages available in the stable updates repository for a release (plus the overrides repo when needed to allow building against pre-release packages). With modularity, we hoped that we could define a small and specific buildroot which would be stable and maintained for the life of a release. We would then build every module against it. It turned out when we tried to implement this that it was basically impossible. It required us to find a point at which the entire buildroot could be used to build _itself_, a feat which has not been accomplished in Fedora for many years (if ever). Fedora packages are really only guaranteed to build successfully against a buildroot for which they have _already_ been built. If it builds against any other buildroot, this is a happy accident. There are many reasons for this; something in the dependency chain for one of the build dependencies may have broken, a bug may have been introduced in the compiler or linker resulting in an inability to continue, new default compiler flags may have been added that result in warnings becoming errors and so on. This was the easiest requirement to drop as it had never worked. We used a kludgy “bootstrap” module to work around this which provided a set of packages copied from non-Modular Fedora to be able to build the platform. In its place, **we will now build modules against the standard Fedora buildroot**. Since our buildroot now has access to everything that has been built for Fedora, we reconsidered another of our original goals that of providing a module to be the base platform upon which all of the other modules would depend. Originally, this was intended to define the provided API of the Base and indicate which portions of it should be considered stable. However, Fedora already has a stable updates policy for how things must act within a release. This policy has only a few outliers (Kernel, KDE, etc.), but for the most part, once we release the Beta, the platform API is stable for the life of the Fedora release. By relaxing this requirement, we realized that we could eliminate (or at least postpone) the requirement for having a defined platform module. What we decided instead is to treat Fedora’s “Everything” repository (essentially, the complete set of software available within a Fedora release) as the “platform module”, though the tooling will not report this content as a module. In practical terms, this means that **creators of modules will no longer need to go through the very painful process of tracking down which modules provide a dependency that they need**. Instead, they will be able to depend on the system version available in the Everything repo. If that version does not meet their needs, they will have several options described later. This provides us with several advantages, including **a straightforward upgrade path from a traditional deployment**, because we will retain the traditional repositories as well as a set of default modules. This means it will be possible to upgrade from a current Fedora 27 system to a modular Fedora 28 system without any special steps. In fact, this approach will also mean that modularity need not be limited to the Server Edition. Another practical advantage to this change is that **module-creation will become _significantly_ simpler**. Instead of a complex collection of a package and all of its dependencies, modules will now only need to describe the parts that differ from the base repository. For example, Fedora 28 will ship with the Node.js 8.x LTS release in the standard repository, and a module could be built to provide the 9.x experimental release as an option. We could also easily provide the older 6.x LTS release to support older applications. In these cases, we can ship very simple module definitions which just lists the dist-git branches matching the desired upstream releases. In fact, this will now be so simple that **we plan to provide tools to automate the creation of these modules**. Since most modules will now only require a single source package be in the components list, we plan to enable support for automatically building a single branch in dist-git for all active Fedora (and EPEL) releases. Even for more complex multi-package modules, the automatically-created module definitions provide an easy and obvious starting point. What Will It Look Like? - ----------------------- From an end-user’s perspective, **Fedora will ship with two sets of repositories.** One will be the traditional Fedora repositories (fedora, updates, and updates-testing) and the other will be a new set of repositories providing alternative and supplementary modules. We haven’t decided on a final name for these yet, so we will use the placeholder terms modular, modular-updates, and modular-updates-testing. With this design, **anyon who does not wish to access the additional versions of software provided by modules can disable the modular and modular-updates repositories and their system will function exactly as it does today**. Packages built with Fedora’s traditional process will be installed and managed from the regular fedora repository, as will default versions of packages which use the new process behind the scenes. **For anyone who wants access to additional versions of packages, these new module repositories will make them available**. Users will be able to interact with these new repositories by taking advantage of some new syntax in DNF, the same as was used in the Modular Server Beta. If a user wants to install a particular module stream, they can do `dnf install module[:stream[/profile]]` (e.g. `dnf install @nodejs:6`, which will install the default profile containing the nodejs and npm packages). If the user just wants to install whatever version is the default for this system, a `dnf install package` will continue to work as it always has. Conclusion - ---------- This refined plan offers an understandable, approachable, and deliverable future for Modularity. Packagers who don’t want to produce modules will be able to continue packaging exactly as they always have with **no modification** to their workflows. Those who want to provide alternative versions of software in a single release or to easily provide the same version across multiple releases will have new tools to simplify this. As the number of available modules grows, users of Fedora will have a much easier access to the exact version of software they want to accomplish their tasks. People doing rapid-prototyping can more easily access newer versions of packages and at the same time people running older applications can continue to access the older streams that they need. -----BEGIN PGP SIGNATURE----- Version: Mailvelope v2.1.0 Comment: https://www.mailvelope.com wkYEAREIABAFAlo5f/YJEHolVWI2uqOjAAD5RgCfeRL8DcETF34kmCOT5pXJ yzL0LLYAmwVmmd2DPHf1gzKZOjUfxiHlbuML =ZnhF -----END PGP SIGNATURE-----

1 0

Elections in January 2018 to FESCo, Council, Mindshare - the schedule
by Jan Kurik 15 Dec '17

15 Dec '17

Hi, I have published schedule for elections in January 2018 on the Elections [1] wiki page. The schedule is as follows: * Dec 15 - Jan 02: Selection of questions from Questionnaire * Jan 03 - Jan 10: Nomination period * Jan 11 - Jan 15: Interviews * Jan 16 - Jan 16: Voting Setup & Validation & Publishing of interviews * Jan 17 - Jan 24: Voting period * Jan 25: Result Announcement Please check the Election page [1] for more details on how the Elections (and interviews) are going to be organized. I am going to be on vacations, mostly off-grid, until January 4th, so if you need any help, please contact Bex [2] (and CC me, please). [1] https://fedoraproject.org/wiki/Elections [2] https://fedoraproject.org/wiki/User:Bex 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

Fedora 25 End Of Life
by Mohan Boddu 12 Dec '17

12 Dec '17

As of the 12th of December 2017, Fedora 25 has reached its end of life for updates and support. No further updates, including security updates, will be available for Fedora 25. Fedora 26 will continue to receive updates until approximately one month after the release of Fedora 28. The maintenance schedule of Fedora releases is documented on the Fedora Project wiki [0]. The Fedora Project wiki also contains instructions [1] on how to upgrade from a previous release of Fedora to a version receiving updates. Mohan Boddu. [0]https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle# Maintenance_Schedule [1]https://fedoraproject.org/wiki/Upgrading?rd=DistributionUpgrades

1 0

F28 Self Contained Change: Django 2.0
by Jan Kurik 12 Dec '17

12 Dec '17

= Proposed Self Contained Change: Django 2.0 = https://fedoraproject.org/wiki/Changes/Django20 Change owner(s): * Matthias Runge <Mrunge AT fedoraproject DOT org> * Miro Hrončok <Churchyard AT fedoraproject DOT org> * Petr Viktorin <Pviktori AT fedoraproject DOT org> This change is about upgrading python-django to version 2.0. The latest Django release drops support for Python 2, but a few Django apps packaged in Fedora do not yet support Python 3. A compatibility package will be provided for those. == Detailed Description == The latest Django release 2.0 finally drops support for Python 2.7. Not all dependent applications in Fedora can keep up with Djangos pace. This change describes a way how to enable both, keeping 2.7 compatibility and also leveraging the latest version. The python-django package will be updated to 2.0, Python 2 subpackage(s) will be removed. A new compatibility python2-django1.11 package will be created with Python 2 version of Django 1.11. The Django 1.11.x series is the last to support Python 2.7, it also has Long Term Support (supported until April 2020 by upstream). See the Django 2.0 release notes for details about Django compatibility with various Python versions. The new python2-django1.11 package will obsolete python2-django < 2 and python-django < 2, but it will deliberately not provide either of those. This will render packages depending on python(2)-django FTBFS (or broken runtime dependencies if they don't require Django at buildtime). This is intentional. If we don't do that, all Django packages in Fedora will just keep dragging the Legacy Python dependency chain forever. Package owners of Django applications requiring Python 2 will need to manually adjust their dependencies to use python2-django1.11 or move to Python 3 only (this is preferred but not always possible). Package owners of Django libraries will need to coordinate this with package owners of the applications. The rule of thumb is: If the library is not required by an application (packaged in Fedora) that uses Legacy Python, remove the Python 2 subpackage (or retire the package, if it cannot support Python 3). There will be packages that fail to build or have broken dependencies. Package owners shall fix those by the steps described above. Proposal owners will send dist-git Pull Requests or Bugzilla patches to help. Proven packager powers will be used to merge those after 14 days of no activity. The removal of leftover packages from Fedora will be coordinated with FESCo (for approval) and releng (for execution). Most of the Django packages in Fedora are already Python 3 compatible. Note that we are aware that naming the compatibility package python2-django would make this entire change much easier. But we'd very much like to retire the entire Python 2 based Django ecosystem at this point already. Creating python2-django1.11 and not providing python2-django is a compromise. Also, we plan to provide it as a contingency plan if necessary, see bellow. == Scope == * Proposal owners: drop Python 2 subpackage(s) from python-django, upgrade python-django to 2.0 and package python2-django1.11 for Python 2 only. * Django apps owners: Either update to Python 3 or use python2-django1.11 as a dependency. * Django libraries owners: Either drop Python 2 subpackages (eventually retire the package if no subpackages are left) or use python2-django1.11 as a dependency for the python 2 subpackages iff those are needed by apps. When removing subpackages, add proper Obosletes tags to their Python 3 counterparts. When orphaning entire packages, add Obosletes to the python3-django package. * Release engineering: releng will help with bulk retirement of packages that fail to keep up with this proposal Releng ticket: #7211 https://pagure.io/releng/issue/7211 * Policies and guidelines: - Python packaging guidelines - Documentation should be provided * List of packages requiring python2-django/ python-django without having django in their name: cobbler-web fts-monitoring gramps-webapp graphite-web pony pulp-server python2-kobo-admin python2-kobo-hub python2-pelican python2-testfixtures-tests python2-whitenoise python2-xmlrunner -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

1 0

F28 Self Contained Change: librealsense2
by Jan Kurik 12 Dec '17

12 Dec '17

= Proposed Self Contained Change: librealsense2 = https://fedoraproject.org/wiki/Changes/librealsense2 Change owner(s): * Till Hofmann <thofmann(a)fedoraproject.org> A new version of librealsense has been released, which does not support older camera versions. Bump librealsense to the new release and add the old library as librealsense1. == Detailed Description == The upstream librealsense2 release does not support older camera models such as F200, R200, LR200 and ZR300. Newer models are only supported by the new version. Thus, we need both libraries in order to support all camera models. The librealsense package will be bumped to the new release, and an additional librealsense1 package will be submitted for review. Currently, no package depends on librealsense: $ dnf repoquery --releasever=rawhide --alldeps --whatrequires 'librealsense*' Last metadata expiration check: 0:30:06 ago on Mon 11 Dec 2017 10:15:08 CET. librealsense-devel-0:2.7.9-0.2.fc28.i686 librealsense-devel-0:2.7.9-0.2.fc28.x86_64 See also the discussion on the devel list [1] for more info. == Scope == * Proposal owners: Update librealsense to latest upstream release, add Provides for librealsense2 Submit legacy librealsense1 for review * Other developers: N/A (not a System Wide Change) * Release engineering: #7204 https://pagure.io/releng/issue/7204 * 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) [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

1 0

Autumn Elections 2017 are cancelled
by Jan Kurik 08 Dec '17

08 Dec '17

During the Autumn 2017 Election cycle we wanted to try a new approach in the way how Elections are organized [1]. Unfortunately, at the beginning of the Voting period we realized the new way does not work as expected [2] and even we tried to put some mitigation plan in place [3], we have not succeeded. To come up with some workable solution we have decided to cancel the currently running Autumn 2017 Elections and start it again in early January 2018. In upcoming days I will publish a schedule for the January 2018 Elections as well as more details on how we are going to organize it. [1] https://pagure.io/Fedora-Council/tickets/issue/135 [2] https://pagure.io/Fedora-Council/tickets/issue/153 [3] https://lists.fedoraproject.org/archives/list/ambassadors@lists.fedoraproje… Regards, Jan -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

4 3

[Fedocal] Reminder meeting : Voting period is in progress
by jkurik＠fedoraproject.org 07 Dec '17

07 Dec '17

Dear all, You are kindly invited to the meeting: Voting period is in progress on 2017-12-09 from 00:00:00 to 00:00:00 UTC The meeting will be about: The Voting period of the currently running Fedora Elections in progress. Please vote for your candidates to Council [1], Mindshare[2] and FESCo [3]. You can vote until December 18th, 2017 when the voting ends at 23:59:00 UTC. To help you to make the right decision we have published Fedora Magazine article [4] summarizing this elections and pointing to interviews with nominees we have published on Community Blog. It is definitely worth a look [4]. [1] https://admin.fedoraproject.org/voting/about/council-december-2017 [2] https://admin.fedoraproject.org/voting/about/mindshare-december-2017 [3] https://admin.fedoraproject.org/voting/about/fesco-december-2017 [4] https://fedoramagazine.org/december-2017-elections/ More information available at: [https://fedoraproject.org/wiki/Elections](https://fedoraproject.org/wiki/El… Source: https://apps.fedoraproject.org/calendar/meeting/8656/

1 0

F28 Self Contained Change: Stratis Storage
by Jan Kurik 06 Dec '17

06 Dec '17

= Proposed Self Contained Change: Stratis Storage = https://fedoraproject.org/wiki/Changes/StratisStorage Change owner(s): * Andy Grover <agrover AT redhat DOT com> * Igor Gnatenko <ignatenkobrain AT fedoraproject DOT org> Add initial support for Stratis, a local storage management solution. This will allow initial testing and user feedback that will guide Stratis's development and stabilization. == Detailed Description == Stratis is a local storage system akin to Btrfs, ZFS, and LVM. Its goal is to enable easier setup and management of disks and SSDs, as well as enabling the use of advanced storage features -- such as thin provisioning, snapshots, integrity, and a cache tier -- without requiring expert-level storage administration knowledge. Furthermore, Stratis includes monitoring and repair capabilities, and a programmatic API, for better integration with higher levels of system management software. == Scope == * Change owner: Stratis is currently in-development, with a 0.5 release coming soon. COPR repo exists already (https://copr.fedorainfracloud.org/coprs/grover/stratis/) Additional work would be to adapt the existing packaging scripts to the new Rust library packaging support that is in F28. Early feedback in F28 will help us reach 1.0 for Fedora 29. Although there are clearly later opportunities for system-wide changes based on Stratis, this initial inclusion would be entirely self-contained. * Other developers: N/A (not a System Wide Change) * Release engineering: #7198 ( https://pagure.io/releng/issue/7198 ) * 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

Autumn Elections 2017: Interviews with candidates are postponed on December 12th, 2017
by Jan Kurik 04 Dec '17

04 Dec '17

Due to some technical and organizational difficulties we are going to delay the publishing of interviews to December 12th, 2017. Interviews with candidates which are ready to be published are going to be scheduled for December 12th. I am going to work with the remaining candidates on their interviews to make sure we have these ready by December 11th COB. More information is available in Council ticket [1]. [1] https://pagure.io/Fedora-Council/tickets/issue/153 Regards, Jan -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkyňova 99/71, 612 45 Brno, Czech Republic

1 0

Autumn Elections 2017: Voting period for Council and Mindshare is open
by Jan Kurik 04 Dec '17

04 Dec '17

The Voting period for Mindshare and Council has just started. Please follow the links bellow to vote for new members of Mindshare and Council teams: Mindshare voting: https://admin.fedoraproject.org/voting/about/mindshare-autumn-2017 Council voting: https://admin.fedoraproject.org/voting/about/council-autumn-2017 The voting period is open until December 18th, 2017 @ 23:59:59 UTC. The full schedule of the Autumn Elections 2017 is available on the Elections wiki page [1] and on the detailed schedule for F27 [2]. [1] https://fedoraproject.org/wiki/Elections [2] https://fedorapeople.org/groups/schedule/f-27/f-27-elections.html Regards, Jan -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkyňova 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 December 2017