fidzu : Fedora

After being a Fedora user for a while, you may have come to enjoy it. And in fact you might want to encourage others to try Fedora. You don't need any special privileges or to become a Fedora Ambassador to do that. As it turns out, anyone can help others get started with Fedora just by sharing information about it.

Having the conversation

For example, if you go out to lunch with a group of colleagues periodically, you might find it natural to talk about Fedora with them. If someone shows interest, you can suggest to get together with them for a Fedora show and tell. There isn't any need for formal presentations or prepared talks. This is just having lunch and sharing information with people you know.

When you're with friends, relatives, colleagues, or neighbors, conversation often turns to things computer related, and you can bring up Fedora. There are usually opportunities to point out how Fedora would partially if not completely address their concerns or provide something they want.

These are people you know so talking with them is easy and natural. You probably know the kind of things they use PCs for, so you know the features of Fedora that will be attractive to them. Such conversations can start anytime you see someone you know. You don't need to steer conversations toward Fedora - that might be impolite, depending on the situation. But if they bring up computer related issues, you might find an opportunity to talk about Fedora.

Taking action

If a friend or colleague has an unused laptop, you could offer to show them how easy it is to load Fedora. You can also point out that there's no charge and that the licenses are friendly to users. Sharing a USB key or a DVD is almost always helpful.

When you have someone setup to use Fedora, make sure they have the URLs for discussions, questions, and other related websites. Also, from time to time, let them know if you've seen an application they might find useful. (Hint: You might want to point them at a certain online magazine, too!)

The next time you're with someone you know and they start talking about a computer related issue, tell them about Fedora and how it works for you. If they seem interested, give them some ideas on how Fedora could be helpful for them.

Open source may be big business nowadays, but it also remains a strong grassroots movement. You too can help grow open source through awareness and sharing!

Photo by Sharon McCutcheon from Unsplash.

22 Nov 2019 8:00am GMT

RPMs of PHP version 7.3.12 are available in remi repository for Fedora 30-31 and remi-php73 repository for Fedora 29 and Enterprise Linux ≥ 6 (RHEL, CentOS).

RPMs of PHP version 7.2.25 are available in remi repository for Fedora 29 and remi-php72 repository for Enterprise Linux ≥ 6 (RHEL, CentOS).

No security fix this month, so no update for version 7.1.33.

PHP version 5.6 and version 7.0 have reached their end of life and are no longer maintained by the PHP project.

These versions are also available as Software Collections in the remi-safe repository and as module for Fedora 29-31 and EL-8.

Version 7.1 is close to its end of life, in December 2019, an upgrade to a higher version is recommended.

Version announcements:

• PHP 7.3.12 Release Announcement
• PHP 7.2.25 Release Announcement

Installation: use the Configuration Wizard and choose your version and installation mode.

Replacement of default PHP by version 7.3 installation (simplest):

yum-config-manager --enable remi-php73
yum update php\*

or, the modular way (Fedora and EL 8):

dnf module enable php:remi-7.3
dnf update php\*

Parallel installation of version 7.3 as Software Collection

yum install php73

Replacement of default PHP by version 7.2 installation (simplest):

yum-config-manager --enable remi-php72
yum update

or, the modular way (Fedora and EL 8):

dnf module enable php:remi-7.2
dnf update php\*

Parallel installation of version 7.2 as Software Collection

yum install php72

And soon in the official updates:

• Fedora rawhide now have PHP 7.4.0RC6
• Fedora 31 - PHP 7.3.12
• Fedora 30 - PHP 7.3.12

To be noticed :

• EL-8 RPMs are build using RHEL-8.0
• EL-7 RPMs are build using RHEL-7.7
• EL-6 RPMs are build using RHEL-6.10
• EL-7 builds now use libicu62 (version 62.1)
• EL builds now uses oniguruma5 (version 6.9.3, instead of bundled copy)
• oci8 extension now uses Oracle Client version 19.3 (excepted on EL-6)
• a lot of new extensions are also available, see the PECL extension RPM status page

Information:

• Migrating from PHP 7.1.x to PHP 7.2.x
• Migrating from PHP 7.2.x to PHP 7.3.x

Base packages (php)

Software Collections (php71 / php72 / php73)

22 Nov 2019 6:40am GMT

One of softwares I often use back then when using Windows and Linux are Zekr - Open Source Quran study tool. This software is based on Java SWT, it work fine and somehow it broken since three or four years ago (on Windows and Linux).

It work fine on Java 6 era but not anymore. You need to tweak, hack, compile you self or find package alternative.

I want to build this software as RPM package so it will be available for others but maybe it will take lot of effort.. plus there is issue about licensing, humm.. maybe next time?

Anyway, If you are looking for solution how to install Zekr on Fedora, just let me know. I will help.

Hint :

:x: Xulrunner package not available anymore (obsolute), you may download SDK manualy from here.

:heavy_check_mark: You cannot play audio (al-quran recitation) if your Java version above than version 6.

$ wget -qO tmp.zip http://www.java2s.com/Code/JarDownload/tritonus/tritonus-utils.jar.zip
$ unzip tmp.zip -d /file_location_to/zekr/lib/ && rm -f tmp.zip
$ sed -i 's_:lib/tritonus-jorbis-0.3.6.jar:lib/jorbis-0.0.17.jar_:lib/tritonus-jorbis-0.3.6.jar:lib/tritonus-utils.jar:lib/jorbis-0.0.17.jar_' /file_location_to/zekr.sh

:books: Download Quran translation on Tanzil website (choose Zekr pack)

Pssst… I do appreciate if someone package Zekr in RPM and build on Copr :thumbsup:

21 Nov 2019 6:33am GMT

Voting in the Fedora 31 elections is now open. Go to the Elections app to cast your vote. Voting closes at 23:59 UTC on Thursday 5 December. Don't forget to claim your "I Voted" badge when you cast your ballot. Links to candidate interviews are below.

Fedora Council

There is one seat open on the Fedora Council.

• Interview with Dennis Gilmore
• Interview with John M. Harris, Jr.
• Interview with Alberto Rodríguez Sánchez

Fedora Engineering Steering Committee (FESCo)

There are five seats open on FESCo.

• Kevin Fenzi
• David Cantrell
• Randy Barlow
• Fabio Valentini
• Miro Hrončok
• Zbigniew Jędrzejewski-Szmek
• Justin Forbes
• Pete Walter

Mindshare Committee

There is one seat open on the Mindshare Committee

• Héctor Louzao

The post Fedora 31 elections voting now open appeared first on Fedora Community Blog.

21 Nov 2019 12:00am GMT

cross posted with this Project Atomic blog post TL;DR Fedora 29 will be End Of Life soon. With it Fedora Atomic Host will have its last incremental release (based on the Fedora 29 stream). Please move to the Fedora CoreOS preview if you can. Last year we introduced the plans for Fedora CoreOS including that Fedora CoreOS would be the successor to Fedora Atomic Host and Container Linux (from CoreOS Inc.

21 Nov 2019 12:00am GMT

This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Thursday, 21 November and closes promptly at 23:59:59 UTC on Thursday, 5 December 2019.

Interview with Justin Forbes

• Fedora account: jforbes
• IRC nick: jforbes (found in #fedora-kernel #fedora-devel #fedora-qa #fedora-arm)
• Fedora user wiki page

Questions

Describe some of the important technical issues you foresee affecting the Fedora community. What insight do you bring to these issues?

There is no question that modularity is the biggest technical issue affecting the Fedora community at the moment, and probably over the next year. I believe my insight comes from a few places. I was involved with rPath quite some time ago, where we tackled some of the issues that modularity is trying to solve. And as a kernel maintainer by day to day job, I don't have any particular stake in modularity, so I can view it objectively, with an eye to what is best for Fedora over the long term. I have been involved with Fedora for a very long time, I do have a vested interest in the continued improvement of Fedora and the success and growth of the community.

What objectives or goals should FESCo focus on to help keep Fedora on the cutting edge of open source development?

Right now, I think working out the issues with modularity should be our top priority, as the current state has become a problem. Outside of that, there is really a long list of details, but it can be all be summarized with "ensure our processes for introducing new technologies are managed in such a way as to not alienate existing contributors, users, and use cases, while publishing stable releases with useful new features"

This includes things like:

• Improving our QA processes
• Taking the time improve our release process
• Ensuring new changes are ready before wedging them into a release
• Making sure changes are not too disruptive to existing workflows.

What are the areas of the distribution and our processes that, in your opinion, need improvement the most? Do you have any ideas how FESCo would be able to help in those "trouble spots"?

Modularity continues to be a trouble spot. It is a great feature in theory, adding capabilities to the distro as shipped, but even more so to people who are using or deploying the distro in their own environments. In practice, it has not been managed as well as it could be. There was always some backlash from the community members who just don't care about modularity, or understand what it brings, but now there is also justified backlash in how things are being currently deployed. FESCo can help to ensure that further features around modularity are properly planned and executed, though there are a few fires to be put out first.

I also believe we can work to bake more security process automation into our workflow, to ensure that good practices are used for package builds, and CVEs are addressed in a timely manner.

The post FESCo election: Interview with Justin Forbes (jforbes) appeared first on Fedora Community Blog.

20 Nov 2019 11:55pm GMT

This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Thursday, 21 November and closes promptly at 23:59:59 UTC on Thursday, 5 December 2019.

Interview with Peter Walter

• Fedora account: pwalter
• IRC nick: pwalter (found in #fedora-devel)
• Fedora user wiki page (none)

Questions

Describe some of the important technical issues you foresee affecting the Fedora community. What insight do you bring to these issues?

We have a lot of people being unhappy how Modularity was "forced" on them in Fedora. I'd like to be a voice of this community and advocate of going back to simple yum repos to ship the default package set, and leaving Modularity strictly as an add-on one can choose, but doesn't have to use.

What objectives or goals should FESCo focus on to help keep Fedora on the cutting edge of open source development?

Simplify Fedora packaging. Remove Modularity that makes everything more complicated. Help more people get involved in Fedora development by simplifying processes.

What are the areas of the distribution and our processes that, in your opinion, need improvement the most? Do you have any ideas how FESCo would be able to help in those "trouble spots"?

In my opinion, Modularity is a "trouble spot". It needs to go.

The post FESCo election: interview with Peter Walter (pwalter) appeared first on Fedora Community Blog.

20 Nov 2019 11:55pm GMT

This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Thursday, 21 November and closes promptly at 23:59:59 UTC on Thursday, 5 December 2019.

Interview with Kevin Fenzi

• Fedora account: kevin
• IRC nick: nirik (found in #fedora-noc, #fedora-apps, #fedora-admin, #fedora-devel, #fedora, many more…)
• Fedora user wiki page

Questions

Describe some of the important technical issues you foresee affecting the Fedora community. What insight do you bring to these issues?

I think that modularity and the issues around it are going to continue for a while. I hope I can provide some help in bringing the 'lets drop modularity and forget it happened' and the 'lets modularize everything' camps together on some solution that works not only for Fedora, but our downstream distros too.

What objectives or goals should FESCo focus on to help keep Fedora on the cutting edge of open source development?

I think we really should look at a rework of our packaging workflow. Many of the things we setup in the past don't make as much sense as they did then. Something like using signed tags to let the automation know what you want (build for X Y Z, or please run the CI on a build of this, or whatever). It's not going to be easy, but I think if we design things right it will be a lot less work on our packagers.

What are the areas of the distribution and our processes that, in your opinion, need improvement the most? Do you have any ideas how FESCo would be able to help in those "trouble spots"?

Well, the workflow as noted. I think we just need to come up with a good framework and let the community help fill in the blanks. We did gather some good info on the devel list recently.

The post FESCo election: Interview with Kevin Fenzi (kevin) appeared first on Fedora Community Blog.

20 Nov 2019 11:55pm GMT

This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors who are a member of at least one non-CLA group. The voting period starts on Thursday, 21 November and closes promptly at 23:59:59 UTC on Thursday, 5 December 2019.

Interview with Miro Hrončok

• Fedora account: churchyard
• IRC nick: mhroncok (found in #fedora-devel, #fedora-python, #fedora-ambassadors, #fedora-3dprinting, #fedora-meeting, #fedora-meeting-1)
• Fedora user wiki page

Questions

Describe some of the important technical issues you foresee affecting the Fedora community. What insight do you bring to these issues?

I think that the most important issue the Fedora community is facing at the moment, and will keep facing for the foreseeable future, is not really technical but instead a communication problem of how to talk about our technical changes and challenges. At FESCo level I will continue to work on:

• enforcing policies that aren't being followed, which leads to stagnation, fo example problems where nobody communicated failures and breakage in a timely manner;
• adjusting our policies to reflect community feedback, focusing on better notifications about relevant issues;
• encouraging Fedora contributors (e.g. change owners) to communicate their intent and impact properly and making sure that the plans are adjusted based on the feedback they get from the community;
• making it easier to contribute when blocked by nonresponsive maintainers;
• assuring that impactful changes are communicated through the Fedora Change Process (and, if needed, changing the process itself to make it easier);
• redirecting technical discussions from FESCo tickets to the appropriate mailing lists (most of the time the devel list), where there's a greater chance of engaging community members in the discussion.

One of the biggest things that is currently happening in Fedora is Modularity. It has high-impact technical challenges. In my opinion, FESCo must assure that the technical issues our community is experiencing are addressed, even if it means we decide not to deliver certain Modularity features until that happens. I'm quite concerned that alienating a big part the contributor community would be much harder to remedy than not delivering some features in the next Fedora release.

I'll end this answer in the same way I did in the previous interview, because I still stand by that opinion: The things in Fedora Engineering are moving forward at great speed towards progress. However, I think we should regularly take a moment to slow down and look back. How are the changes we made affect the life of an average Fedora packager? Tester? Translator? How does this affect our packaging standards? Is there buy-in from the community, or is it just for the ones involved?

What objectives or goals should FESCo focus on to help keep Fedora on the cutting edge of open source development?

I see two main concerns in this question:

First: to keep Fedora on the cutting edge of open source development. For Fedora contributors, we must make sure that they can contribute to Fedora as easily as possible. As an example, I believe we've managed to make it easier to unblock contributors when it comes to nonresponsive maintainers or packages that fail to build from sources. As FESCo, we can hardly go and fix all the ignored packages and build failures, but instead we have made the processes easier for individual contributors by adjusting the existing policies. We should continue in this and strive to make Fedora a more collaborative environment. One thing that I would like to see changed, is that packages or modules (components generally) are still pretty much owned by individuals. Most of them are awesome and open to collaboration, yet some of them are unfortunately acting like road blocks, rather than experts open to suggestions. We should make sure that nothing in Fedora is private property, but rather implement a collaborative workflow and environment.

Throughout my past year at FESCo, I've helped to change some of our policies to improve the situation and I'd like to continue to do so.

Secondly, to keep Fedora on the cutting edge of open source development for people using Fedora as their platform of choice, we must try to hear from them and model their use cases. When considering a change (or the status quo) in Fedora, we should ask how it impacts a Rust developer, a web designer, a Lua hacker, a Linux kernel engineer, a JavaScript student, a Python data analyst, a hardware specialist, a QA engineer, or any other kind of developer. For example, what happens if we deliberately delay a Fedora release for half a year? Will those people get the cutting edge tools they need? Will we provide the tools for them via regular updates or in some other way? How do we achieve it without telling everyone to use COPR or rawhide, without exhausting our contributors? And so on. We should figure such things out before making a tough decision.

During my past year at FESCo, I've asked myself such questions when approving or rejecting change proposals or other kinds of tickets. In several cases, I have even asked the change owners similar questions.

What are the areas of the distribution and our processes that, in your opinion, need improvement the most? Do you have any ideas how FESCo would be able to help in those "trouble spots"?

As for the distribution, I think it's the modularity/non-modularity gap between people. For our processes, the nonresponsive-maintainers and fail-to-build-from-source / fail-to-install policies have been recently adapted, as they needed improvement the most. But the job is never done, we need to keep looking at these polices and adapt them to make Fedora not only a healthier tech stack, but also a healthier community. FESCo should assess new Fedora changes not only on the basis of how they are making Fedora superior, but also on how do they affect current Fedora contributors and whether the tooling for them is ready (or at least planned as part of a Fedora change).

The post FESCo election: interview with Miro Hrončok (churchyard) appeared first on Fedora Community Blog.

20 Nov 2019 11:55pm GMT

This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors who are a member of at least one non-CLA group. The voting period starts on Thursday, 21 November and closes promptly at 23:59:59 UTC on Thursday, 5 December 2019.

Interview with Fabio Valentini

• Fedora account: decathorpe
• IRC nick: decathorpe (found in fedora-{golang,java,python,ruby,rust,stewardship,meeting*})
• Fedora user wiki page

Questions

Describe some of the important technical issues you foresee affecting the Fedora community. What insight do you bring to these issues?

One of the big issues I see today is the increasingly large number of packages that fail to build or install on fedora, which seems to have about doubled between Fedora 29 and rawhide, according to my data. I am trying to reintroduce a regular dependency check report for rawhide (and maybe stable/testing as well), which would at least make the problem more visible, and provide pointers to the most problematic missing dependencies.

There's also the fallout from the - currently incomplete (or broken, depending on who you ask) - implementation of Modularity, which has caused upgrade issues (the "libgit2 issue"), various issues around the Java stack, including the broken eclipse packages in fedora 31+ and the "forced move" to modules (or even the recommendation to use the flatpak version instead), and so on. I've been actively working to keep the non-modular Java stack maintained under the umbrella of the Stewardship SIG, so packagers who can't (or won't) move their packages into modules don't suffer from this current, broken situation.

What objectives or goals should FESCo focus on to help keep Fedora on the cutting edge of open source development?

With stagnating contributor numbers and an ever growing package base, I think the most important thing to tackle is making the packager workflow more streamlined. I already see progress being made into the right direction here (for example, making package un-orphaning a push-button action in pagure instead of having to go through a releng ticket manually). This both makes working on fedora packages easier for existing maintainers, and should make fedora a more attractive, modern project to contribute to for newcomers. The multi-build update workflow for rawhide with on-demand side-tags also seems like a good improvement, both for packagers, and for the stability of rawhide. I think a gating check that rejects packages which introduce broken dependencies into the repository would be a good addition, as well (and it might help reduce the number of broken dependencies over time).

Improvements in this area directly benefits the stability of fedora and the ability of packagers to deliver new features faster - which means fedora can continue to be the best platform for developers.

What are the areas of the distribution and our processes that, in your opinion, need improvement the most? Do you have any ideas how FESCo would be able to help in those "trouble spots"?

I see a lot of issues surrounding Modularity (both regarding policy and implementation), but that topic has already sparked more debates than any other change in fedora since I joined a few years ago, so let's not focus on that for now

Other than that, I see the large (and growing) number of packages with broken dependencies as a big issue, and a sign that the fedora repositories aren't in a great state - not even mentioning the fact that dependencies that aren't satisfiable from the official repos might pose a legal risk for fedora, as well.

I think the updated FTBFS and Non-responsive maintainer processes already help here, since they make the problem of broken packages more visible for dependent packagers, and introduce an automatic cleanup of packages that fail to build and that nobody cares about.

Another area that I sometimes find a bit lacking is documentation for some common tasks (like getting a package's dependency tree, or querying things that need to be rebuilt in case of ABI changes, …). While there is documentation and policy covering these tasks, it might be good to give concrete examples for correctly determining the impact of a change. This might also help to reduce the number of broken updates (and surprise SONAME bumps) in fedora, making development of rawhide more stable and predictable.

The post FESCo election: interview with Fabio Valentini (decathorpe) appeared first on Fedora Community Blog.

20 Nov 2019 11:55pm GMT

This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors who are a member of at least one non-CLA group. The voting period starts on Thursday, 21 November and closes promptly at 23:59:59 UTC on Thursday, 5 December 2019.

Interview with David Cantrell

• Fedora account: dcantrel
• IRC nick: dcantrell (found in #fedora-devel, #fedora-qa, and #fedora-ambassadors and other channels for projects I am involved in)
• Fedora user wiki page

Questions

Describe some of the important technical issues you foresee affecting the Fedora community. What insight do you bring to these issues?

• Developer controls for gating and CI. A lot of work has been happening in the context of continuous integration. We created new services, developed processes, and wrote tests. These are all beneficial. I think Fedora needs to ensure we implement developer tools that do not disrupt workflows and which are stable. In my project rpminspect, a Koji RPM and module build analysis tool, I think about developers who are running it to compare builds. A comparison of builds of zlib is very different than comparing two kernel builds, yet I still have a desire to make the tool work for both use cases, so I have added functionality to ensure it will. As we work on projects for gating and CI, we need to keep in mind the broad range and types of software that makeup Fedora.
• Modularity and the many ways we make software available to users. Modularity is a topic that continues to get a lot of attention on the mailing lists. I want to see modularity discussions focus on goals and technical requirements. We can look at modularity as something contributed by Red Hat, a Fedora Project community member. Red Hat had a set of use cases and a deadline. Now we have it in Fedora because Fedora serves as the upstream for RHEL. We should remember that Red Hat relies on Fedora for technical leadership upstream. We should view modularity as a new starting point for a technical discussion on how we deliver software to users. Remember that RHEL-5 shipped with Xen virtualization, and the migration to KVM was worked out in Fedora, so RHEL-6 shipped with KVM.
• Improve integration between our tools and services. I will use the Packit project as an example. Packit is an exciting project because it offers a bridge between upstream development and building for Fedora. And they are interested in improving that developer workflow and making it easier for software to be available in Fedora. Just like Packit, I see tools and infrastructure that we could focus on to improve the experience for package maintainers and other contributors. I would like to see the fedpkg command work for packages that pull their source archives from an upstream git repo. As a package maintainer, I would like to specify a git repo and a tag and then fedpkg take care of the rest. That reduces the work I need to do with dist-git and leaves me more time to focus on bug reports, tracking upstream changes, and submitting patches there. There are a lot of examples like this where small improvements can contribute to improving the developer experience. Fedora needs to treat these problems with a high enough priority to both keep developers interested in working on the project as well as avoiding process fatigue where we feel we have no time to improve things because there's so much work to do-because we have not improved our tools.

What objectives or goals should FESCo focus on to help keep Fedora on the cutting edge of open source development?

There is a lot I think FESCo can do here. FESCo should continue to communicate that it is a policy setting body and not a design body. Where a technical decision needs to be made that affects the project as a whole, FESCo should lead that process and get to a conclusion. They do that, but I think this is a definition that bears repeating.

Goals:

• Release policy. I think it is time to revisit how we define and make releases. There is no question that the release cycle is a significant stress factor for the community. I feel that with the introduction of automated testing services and gating tests, we can discuss redefining what a release means and make more of the development asynchronous. For example, if we were to define Fedora releases as coming from a stable tag in git, release engineering, and QA could trust that building a release from that tag would be usable. Releases could then be happening at any point in time that we see fit. They could be rollups of a dot zero release plus updates. This example is hypothetical, but I think the classic Linux distribution release model is something worth discussing and possibly redefining given our new workflow abilities.
• Contributing changes to upstream projects to help with the minimization effort. I have been at Red Hat for a while, and the topic of "minimizing the install" is a joint discussion for RHEL and Fedora. Nearly all talks end with it being an intractable problem because you have to agree on what minimal means. That goes beyond just defining the files. It also represents functionality. The minimization efforts underway look like good starts, but I would like to see us work with upstream projects to make more functionality conditional at build time if it is not required or contributing support for building with other libraries. For example, if a program includes HTTP download support, but we decide that it is not part of minimal, we should work to contribute patches that let us build it without libcurl (or whatever the library is).
  Another example is software with line editing capabilities using readline or libedit. A minimization effort should work to have one line editing library installed, so patches to use that other line editing library help. Too many discussions focus on the built RPMs when minimizing them, but we have made those to enable nearly all functionality and be interdependent. To truly get minimal, we need to think deeper.
• DNF integration with language package managers. I was toying around with this idea earlier in the year, but I think it would be neat to be able to do "dnf install -pip PIP_PACKAGE" or "dnf install -cpan CPAN_PACKAGE." Integrating these per-language package managers into our system-wide package management could be interesting.

I'm sure I can think of more here, but I have already written a lot of text.

What are the areas of the distribution and our processes that, in your opinion, need improvement the most? Do you have any ideas how FESCo would be able to help in those "trouble spots"?

Aside from everything I have already mentioned, I think Fedora should
be working to improve the contributor experience. Helping a new
community member get started in Fedora is confusing for me, and I have
been doing this for a long time. Having a getting started guide, and
current documentation is part of that, but our tools and services
should be more discoverable for new and existing contributors. I
think FESCo could help here by defining some minimum requirements for
developer tools and services. That could also help identify existing
tools and services we should prioritize to bring them up to a better
state.

The post FESCo election: interview with David Cantrell (dcantrel) appeared first on Fedora Community Blog.

20 Nov 2019 11:55pm GMT

This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors who are a member of at least one non-CLA group. The voting period starts on Thursday, 21 November and closes promptly at 23:59:59 UTC on Thursday, 5 December 2019.

Interview with Zbigniew Jędrzejewski-Szmek

• Fedora account: zbyszek
• IRC nick: zbyszek (found in fedora-devel, #systemd, #fedora-rust, #fedora-python, #fedora-neuro)
• Fedora user wiki page

Questions

Describe some of the important technical issues you foresee affecting the Fedora community. What insight do you bring to these issues?

We have plenty of new stuff happening in package creation and
delivery: automatic generation of build requirements and reuse of
upstream project metadata, new packaging macros, rawhide gating,
library ABI checks, packaging automation like Packit and Modularity,
more CI capabilities, rawhide side-tags and gating, new delivery
formats like Silverblue, containers, flatpaks, modules. The challenge
is how to integrate those technologies into existing workflows so that
the old approaches can coexist and be gradually replaced; how to allow
hawkish packagers who are ready to switch to the latest and greatest
to move forward quickly, without breaking workflows of more
conservative maintainers. We also need to keep in mind packaging
outside of the core distribution: copr users, spins, distributions
which rebuild our packages, people who maintain in-house packages.

We declare that allowing people to build solutions on top of Fedora is
our goal, and we need to weigh the changes that we introduce in this
light.

FESCo does not have the ability to tell people what to do. It is only
useful as a place where questions are asked, and voices of interested
parties are recorded. As a FESCo member my goal will be to ask
questions and gather feedback until any given issue is clear. We can't
achieve unanimity, and we can't always satisfy everyone, but we need
to anticipate problems and minimize disruption while still allowing
the technology to move forward.

What objectives or goals should FESCo focus on to help keep Fedora on the cutting edge of open source development?

In the next two release cycles:

• Make gating finally widely used, by concentrating of general tests
  that are applicable to a wide range of packages, to catch
  install/uninstall/upgrade issues, library ABI compatibility breaks,
  missing dependencies. This will make packaging more robust, and empower
  packagers to move on to more interesting tasks.
• Finish the transition to Python 3, keep only those Python 2 packages
  that we absolutely must.
• Transition to Java 11 and make the Java ecosystem healthy again.
• Figure out how to enable the good parts of Modularity, as implemented
  now or as equivalent functionality, without making things difficult for
  everyone else.

On slightly longer scale: automatize packaging of language-specific
stacks like Python or Rust by reusing upstream metadata and making the
package creation and update mechanism as simple as possible. Make the
flow from upstream releases to distro packages fully automatic.

What are the areas of the distribution and our processes that, in your opinion, need improvement the most? Do you have any ideas how FESCo would be able to help in those "trouble spots"?

No big surprises considering what I wrote above: we have a lot of
friction where new technologies are being introduced, and the new
conflicts with the old. Not every project that is brought forward is
ultimately worth integrating in Fedora, and FESCo should ask hard
questions and require contingency plans and coordinate reverts if need
be.

Another problem is the stagnation or even shrinking of the number of
contributors. I believe the technical problems discussed above are
significantly contributing to this: the "packaging story" is nowadays
much more complicated and uncertain and less documented than it used
to be; at the same time many experienced packagers are busy fighting
fires and fighting on the mailing lists, so we don't have time for
newcomers and docs and polish. This is a problem now, but the upside
is that once those pressing issues are be solved, the experience for
new packagers will improve and we can hope to grow the project again.

The post FESCo election interview: Zbigniew Jędrzejewski-Szmek (zbyszek) appeared first on Fedora Community Blog.

20 Nov 2019 11:55pm GMT

This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors who are a member of at least one non-CLA group. The voting period starts on Thursday, 21 November and closes promptly at 23:59:59 UTC on Thursday, 5 December 2019.

Interview with Randy Barlow

• Fedora account: bowlofeggs
• IRC nick: bowlofeggs (found in #fedora-apps, #fedora-admin, #fedora-noc, #fedora-devel, #redhat-cpe)
• Fedora user wiki page

Questions

Describe some of the important technical issues you foresee affecting the Fedora community. What insight do you bring to these issues?

There have been many regressions with ease of use for tooling that packagers need to use to deliver software to Fedora's users over the past few years. Quite a few things are manual now that used to be automatic. As a member of the infrastructure group, I have some first hand knowledge of how and why these changes happened, and I have ideas on how we can improve them.

There is also a project aimed at bringing the CentOS and Fedora dist-gits together in the horizon. I've been working on gathering requirements for this project with some other folks, and has potential to lead towards many technical changes being proposed.

What objectives or goals should FESCo focus on to help keep Fedora on the cutting edge of open source development?

I think Fedora is more difficult to contribute to than it needs to be. Some of this is due to the usability regressions I mentioned above, but I also think the barrier of entry is fairly high to join the package maintainers. There are some other distributions that allow contributors to simply open pull requests on GitHub, as an example of how low the barrier to entry could be. We, in comparison, require contributors to sign a CLA, submit a package review, perform several practice package reviews, and find a sponsor to join. I suspect that this limits our contributor pool significantly. I think it would be wise to rethink how we operate here, and find ways to lower the barrier of entry for new contributors. One example is to make it easier for contributors to send patches to the project without requiring them to be packagers.

What are the areas of the distribution and our processes that, in your opinion, need improvement the most? Do you have any ideas how FESCo would be able to help in those "trouble spots"?

As we've seen on the devel list recently, there is friction within the community around the modularity project. Some of the issues are technical, some of them are related to policy, and likely most of them are due to misunderstandings of communication and of the project itself. I think FESCo can help here by working to clarify these misunderstandings so that everybody can see the problem statements and proposed solutions more clearly.

The post FESCo election interview: Randy Barlow (bowlofeggs) appeared first on Fedora Community Blog.

20 Nov 2019 11:55pm GMT

This is a part of the Council Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Thursday, 21 November and closes promptly at 23:59:59 UTC on Thursday, 5 December 2019.

Interview with Alberto Rodríguez Sánchez

• Fedora account: bt0dotninja
• IRC nick: bt0 (found in #ffedora-commops, #fedora-Latam, #fedora-join, #fedora-neuro, #fedora-mindshare, and more)
• Fedora user wiki page

Questions

Why are you running for Council?

I know that it is a great responsibility and also know than the time of my fellow contributors is very valuable so I don't want to waste it. I will be in every meeting and commenting on every ticket doing always my best.

Why should people vote for you?

I think we can reproduce some ideas becoming from the experience of running the Monthly User/Contributors meetings in Mexico. Those experiences are helping me to grow as a contributor and my skills in teamwork. I'm feeling than I can do good work in the Council.

What do you want to accomplish as a member of the Fedora Council?

My goal is to propose actions that help us increase the number of active collaborators, particularly in packaging, design, and D&I; this will have an impact (at least in theory) on our user base.

The post Council election: Interview with Alberto Rodríguez Sánchez (bt0dotninja) appeared first on Fedora Community Blog.

20 Nov 2019 11:50pm GMT

This is a part of the Council Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Thursday, 21 November and closes promptly at 23:59:59 UTC on Thursday, 5 December 2019.

Interview with John M. Harris, Jr.

• Fedora account: johnmh
• IRC nick: johnmh (found in #fedora-commops, #fedora-games, #fedora-kde, #fedora-3dprinting, #fedora-security, #fedora-devel, #openblox)
• Fedora user wiki page

Questions

Why are you running for Council?

I believe that we've been rushing to make change where there is no call for it recently. We may be inadvertently ostracizing users and developers by moving from conventional tools, and moving away from our Four Foundations: Freedom, Friends, Features and First.

For example, recently users were provided with easy ways to install proprietary software on Fedora (NVIDIA proprietary drivers, Google Chrome browser), without being told why we don't have proprietary software (other than firmware) in the repositories to begin with. More and more, we often seem to be overlooking the first of the Four Foundations, Freedom.

Why should people vote for you?

I hope to represent the views of those who believe that Free Software is still important.

What do you want to accomplish as a member of the Fedora Council?

I want to work towards ensuring that Freedom is always considered when considering changes to Fedora, and that, when possible, Fedora is not used as a testing ground for projects like Modularity.

The post Council election: Interview with John M. Harris, Jr. (johnmh) appeared first on Fedora Community Blog.

20 Nov 2019 11:50pm GMT

Service 'The Koji Buildsystem' now has status: good: Everything seems to be working.

20 Nov 2019 10:39pm GMT