This is a part of the FESCo Elections Interviews series. Voting is open to all Fedora contributors. The voting period starts on Thursday, December 6th and closes promptly at 23:59:59 UTC on Thursday, December 20th, 2018.
Interview with Zbigniew Jędrzejewski-Szmek (zbyszek)
- Fedora Account: zbyszek
- IRC: zbyszek (found in #fedora-devel, #systemd, #fedora-python)
- Fedora User Wiki Page
Describe some of the important technical issues you foresee affecting the Fedora community. What insight do you bring to these issues?
The biggest problem I see currently is the introduction of Modularity and the related changes causing a slowdown of development in other areas. There are three important aspects: first, it is a complicated topic that brings a whole set of new concepts, tools, techniques, and bugs, and packagers and users both have to get acquainted with modules, which takes time and effort. Second, the roll-out of modularity, e.g. integration in dnf and other package managers, is still far from great. Third, many smart people at the core of the distribution are diverting from other activities to work on this. I hope that with F30 most of those issues will be figured out and we can reap the benefits.
What objectives or goals should FESCo focus on to help keep Fedora on the cutting edge of open source development?
The way we do packaging is evolving all the time. We have Modularity, and we are right now facing questions how to make it generally usable, without abandoning external users and redistributors of our packages. There are various proposals how to evolve packaging to cater to go and rust and modern python packaging, to allow maintainers to manage packages semi-automatically, more in line with native package management in those languages. I hope FESCo can coordinate these efforts to allow things to “happen”, but in a way that the needs of all stakeholders are taken into account.
I’m not convinced by the recent proposals to delay F31 to work out the releng and pipeline and tooling challenges. I do see many things that need to be improved, but most of them are independent of the release cycle, and can be worked at any time. It seems that currently too much depends on the core releng team, and I hope we some of those responsibilities can be devolved, and others automatized. In this and other areas, I would love to see more freedom for “fly-by” contributions, like proven packagers do for spec file maintenance and anyone can get involved in the freeze testing and bug zapping process.
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”?
Communication between different teams is, as always, an issue. I think all our teams are doing an excellent job, but there’s always more need for transparency and exchange of information. I hope FESCo can improve it’s procedures to invite stakeholders earlier and more consistently.
There’s a number of processes that don’t seem to be happening or are only happening through manual efforts, without automatization. Cleanup of FTBFS, orphaned, and insecure packages, package ownership reassignments, notifications about missing dependencies. We are still recovering from pkgdb removal. We need to automatize those things again to make everything run a little smoother, and to avoid burnout from releng members.