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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

The evening wind was cold, but I protected myself by the fire spell. It was nice to sit outside and look at the whole release-monitoring.org realm in the sunset. One could see the beauty behind all this hard work and it’s ignites a nice feeling inside one’s heart. Lately I didn’t have much time to appreciate this beauty. To be honest I didn’t have much time to work on this realm in the last few months. But still some work was done even here.

I heard the footsteps behind me. “Traveler, it’s nice to see you again. Do you want to join me?” Footsteps stopped beside me and my companion was looking at the sunset with me. “I suppose you are here to hear about the news from this world. I assure you there are many things I want to share with you. Just listen…”

Wizard’s journey to OpenAlt

At the beginning of this month I visited the symposium of mages OpenAlt in ancient city of Brno (Czech Republic). It was a nice place with interesting people, I learnt plenty of new things and as every mage knows, magic is about knowledge. If you want to see how it was, there are already some pictures (Saturday and Sunday gallery) painted by the talented artist. If you look at the gallery more closely, you can see that I represented this realm with my pointy hat.

Saturday on OpenAlt

On Saturday I visited few interesting talks from different realms. First was about the realm of Bootloader from wizard Jan Hlaváč. He talked about history and current state of Bootloader realm in Fedora Universe. It was interesting to hear about the various solutions introduced in the Bootloader realm. Like MBR, GPT, Grub and SecureBoot to name a few.

The second really interesting talk was Freedom and openness of internet in Europe. This talk was presented by Marcel Kolaja, who is vice-president of European Parliament. I think the mage of release-monitoring.org still sounds better, but it is pretty impressive title nonetheless. This talk was introducing legislations that are serious threat to the freedom and openness of the internet. One is the Digital Copyright Law, which was unfortunately already accepted by European Parliament and the second is trying to solve the terrorist content on the internet, which is now in phase of trialog (which is discussion between three parties). This talk showed much about the processes in European Parliament and it was interesting even for wizard from completely different realm.

I spent rest of the day talking with other mages about various topics from different realms, it was nicely spent time and I learnt a few new spells.

Sunday on OpenAlt

On Sunday I was more busy, there were so many interesting talks I didn’t know where to go first. But there was one talk I couldn’t miss. My own. But let’s go through the talks one by one.

First one was from Jiří Konečný about Anaconda world. This world is part of the Fedora universe and it’s the first thing you will get in touch if you want to become a part of Fedora Universe (Anaconda is OS installer, not only for Fedora). This talk was about the various other realms that were created thanks to Anaconda. It was nice to see how many things could develop from the world like Anaconda.

Than it was time for my own talk. On this symposium I talked about something different then release-monitoring.org. I started by introducing myself and why I have a wizard hat. Than I started talking about the world of Silverblue and LibreELEC and how you could use those to create a vision impairing spell (Home Theater PC). I even had some nice performance with tricks (demos) prepared, but one of them didn’t worked. But in the end we spent most of the time discussing various topics about these worlds. I think the talk went well and it was interesting for everyone who attended.

Next talk was again from Jiří Konečný, but this time he talked about the Python universe and it’s history and current state. This was funny presentation with plenty of Monty Python’s humour (Python is named after Monty Python). I learnt few new things I didn’t knew and in the second part of the talk I also saw what is wrong with some new things in this universe. I think this was interesting talk to anyone, who is visiting the Python universe.

Next talk was from Pavel Baksy and it was a little darker talk about security and privacy. Security is pretty important topic for number of mages. It is interesting to see how some organizations are trying to invade privacy of people. He recommended to join the world of NextCloud and use it to keep all your magical books and manuscripts safely hidden in there. It was interesting talk for anyone who wants to take security and privacy seriously.

The last talk on Sunday for me was Gaming on Linux from Jiří Folta. This was a pretty nostalgic talk for me, because I played most of the games he talked about in his gaming history. I was and still am an active Linux gamer by myself, although my wizard responsibilities are taking much more time these days. He also talked about the current state of Linux gaming world and it’s a pretty happy world to live in right now. I should take a vacation and travel there for some time.

I also spent some time with mages from the world of Mozzila and Fedora Silverblue, both of them talked about very interesting topics like flatpaks and what we could expect from them in the future. To summarize all this, it was really nice weekend although it was really tiring.

Anitya 0.17.2 released

Anitya 0.17.0 was released on 3rd September and after some time in the purgatory (staging) a few issues were identified, which were fixed in 0.17.1 and 0.17.2. This version is now live and available for entities (users), who want to use the latest features, like:

• Teach new languages to Anitya scribes (Add semantic and calendar version scheme). This will allow us to better understand the news we are receiving (sorting other than by RPM version scheme).
• Don’t bother projects, we are watching, too often (Use If-modified-since HTTP header when checking for new versions)
• Add new worker for libraries.io (Libraries.io consumer is now part of the Anitya)
• Lifting curses (Fixing bugs)

the-new-hotness 0.12.0 released

Version 0.12.0 of the-new-hotness was released on 26th September and it’s currently in purgatory. We need to synchronize with my collegue from world of Pagure to be able to make it available for everyone. Both of these contains changes which are dependent on each other. Otherwise the purgatory trial seems good and no issues were seen so far. The new version has two main changes:

• Collaboration with world of Pagure, which will now replace the Great Oraculum (scm-requests pagure repository) (Retrieve the monitoring status from dist-git instead of fedora-scm-requests)
• Preventive solutions against letting the same messenger go to world of Bugzilla again and again (Handle the Bugzilla error by not acknowledging the Fedora messaging message)

What awaits us?

Now to a serious question, why I’m not that active on release-monitoring.org anymore? Some time ago our conclave of mages started to change and these changes are good, because there is a more collaboration between mages and different worlds we are taking care of. But as this is progressing I’m having much less time to actively work on the release-monitoring.org. Right now I’m helping other mages finish the work on Bodhi’s Rawhide Gating initiative and it’s nice to work with others, finding solutions to problems together and having some discussion in the meantime. But as I said this is taking time away from the realm of release-monitoring.org.

What this means for you? This means that releases will not be that often and the same will be true for this blog as you could see the gap between this post and the previous one. I’m still working on the release-monitoring.org, so no worry, there will still be something new.

Post scriptum

This is all for now from the world of release-monitoring.org. Do you like this world and want to join our conclave of mages? Seek me (mkonecny) in the magical yellow pages (IRC freenode #fedora-apps) and ask how can you help. Or visit the Bugcronomicon (GitHub issues on Anitya or the-new-hotness) directly and pick something to work on.

The post Stories from the amazing world of release-monitoring.org #8 appeared first on Fedora Community Blog.

Here’s your report of what has happened in Fedora Program Management this week. Fedora 29 will reach end of life on 26 November. Elections voting begins next week. Candidates must submit their interviews before the deadline or they will not be on the ballot.

• Announcements
• Help wanted
• Upcoming meetings
• Releases
• CPE update

Announcements

• Orphaned packages seeking maintainers
• Python 2 packages without a granted FESCo exception are being removed this weekend.
• The Fedora Council approved an extension to the Minimization Objective
• An update to the fonts packaging policy has been submitted to the Fedora Packaging Committee.
• Fedora’s pastebin will be retired on 1 December. The fpaste package is updated to use a new server in all supported Fedora releases.

CfPs

Help wanted

• Volunteers needed for the Fedora booth at FOSDEM

Upcoming meetings

• Friday with Infra — Friday

Releases

Fedora 31

Schedule

• 21 November — Elections voting begins
• 26 November — Fedora 29 EOL

Fedora 32

Changes

Announced

• Build Python 3 to statically link with libpython3.8.a for better performance
• Freeze after branching until compose is ready

Submitted to FESCo

• Annobin used by Bodhi (FESCo ticket #2268)
• iptables-nft-default (FESCo ticket #2269)
• Translation platform migratration to Weblate (FESCo ticket #2270)

Approved by FESCo

• Modules In Non-Modular Buildroot

Withdrawn by owner

• On-demand side tags

CPE update

Rawhide Gating

• Bodhi 5.0 has been deployed in production
  • We received some feedback about the changes in the UI and are looking at how we can address them.
  • We are working on documenting on how packagers will use Bodhi for multi-builds updates in rawhide: https://github.com/fedora-infra/bodhi/issues/2322 https://fedoraproject.org/w/index.php?title=User:Nphilipp/Package_update_HOWTO#Rawhide_and_early_Branched
• A 5.1 release is scheduled, likely some time next week, to address some of the issues encountered and fixed in the 5.0 release.

repoSpanner

• Our team came across some test reliability issues last week & these are impeding progress on the 83x patch.
• Some more debugging/discussions around RCMs pushes that seem to be either very slow or hanging but the team is looking into some solutions
• Some progress was also made on the 83x patch however and we managed to fix one unreliable test.

Community Application Handover & Retirement Updates

• Elections — Blocking issue was fixed (https://pagure.io/fedora-infrastructure/issue/8253)
• Fedocal — jlanda hitting permission error in communishift https://pagure.io/fedora-infrastructure/issue/8274
• Nuancier — Benson Muite is now working on OIDC authentication. We are emailing him to check the progress and if he needs any help
• fpaste — Published an article in Fedora Magazine. Sunset date: 1 December 2019.
• Badges — GDPR query under investigation

The post FPgM report: 2019-46 appeared first on Fedora Community Blog.

I held a Fedora Birds-of-a-Feather (BoF) session at Ohio LinuxFest in Columbus, Ohio on November 1. Ohio LinuxFest is a regional conference for free and open source software professionals and enthusiasts. Since it’s just a few hours drive from my house, it seemed like an obvious event for me to attend. We had a great turnout and a lively conversation of the course of an hour.

The session started a little slowly as many people were still in the keynote. But a few minutes later, the room was nearly full. I didn’t take a count, but at the peak, we probably had about two dozen attendees. Some were existing Fedora users and some were there to learn more about Fedora.

I didn’t plan any particular content, since I wanted to let the group drive the discussion based on what was interesting to them. We ended up talking about documentation a fair amount. Two of the attendees created a FAS account that weekend so they can start contributing to the docs! Several more claimed the OLF BoF badge, and I sent them all a follow-up email directing them to the Join SIG’s Welcome page.

In addition to docs, we talked about the general Fedora release process—how we determine our schedule and how we decide when to release. I brought some USB sticks with Fedora 31 Workstation for people to try. And of course I had stickers, pens, and pins to give away.

It can be hard to judge the value of events like this, but I’m encouraged by the fact that we got at least six new people to create FAS accounts. I’m looking forward to seeing contributions from those new contributors as they work with the Join SIG to get started.

One of the attendees sent me an email a few days later that read in part:

The encouragement I got at OLF pushed me to make my first pull request last night that was already accepted. I am still struggling with git but I got some wonderful help from a community member yesterday in IRC that lead to my first pull request.

I’d like to have a Fedora booth at this event next year—it represents a great opportunity to grow our contributor community.

The post Fedora BoF at Ohio LinuxFest 2019 appeared first on Fedora Community Blog.

Welcome to the monthly set of updates on key areas within Fedora. This update includes Fedora Council representatives, Fedora Editions, and Fedora Objectives. The content here is based on the weekly updates submitted to the Fedora Council, published to the project dashboard.

Minimization objective

The Minimization objective submitted an updated proposal to the Fedora Council. Objective lead Adam Šamalík developed a logic model to help define the future work of the Minimization objective.

Silverblue

The Fedora Silverblue team was not able to get the necessary changes into Fedora 31 to support having Flatpak pre-installed. They are looking at the possibility of re-spinning the Silverblue ISO to incorporate the changes. But they did update the Fedora 31 Flatpak runtime. The team updated the Flatpak’ed GNOME applications to GNOME 3.34 and built them against the Fedora 31 runtime.

The team is planning for Fedora 32. See the Kanban board for more information.

Workstation WG

The Workstation WG is looking at how to increase membership and participation in the working group. Discussion is ongoing in issue #106. But the WG has started a subgroup investigating the possibility of encrypting user home directories by default. Meeting agendas and notes are available on the GNOME etherpad. Discussion is also occurring on the desktop mailing list.

Of course, Fedora 31 released at the end of the month. Fedora 31 Workstation included better support for non-English users, improved H.264 support, and many other enhancements. The working group hopes to support Wayland by default on Nvidia GPUs in Fedora 32.

The post Fedora status updates: November 2019 appeared first on Fedora Community Blog.