-----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-----
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
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
= 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
= 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
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
= 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
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