Organizing a "packager experience" objective and working group


We had a recent discussion on this list last month about (among other
things) the current state of Pagure as a replacement for pkgdb [1].

I mentioned in that discussion that there are various issues which
have arisen from the deprecation of pkgdb that have made the packager
workflow ever so slightly worse. But it's not just pkgdb-- there are
lots of places where the packager workflow could use improvement.
There are parts of the process that are tedious and manual which could
be replaced with (partial) automation, or parts where automation
exists but is in need of improvement.

For example, there are tools (namely, the "fedora-review" script) to
automate parts of the package review process. But fedora-review has
been lagging behind the packaging guidelines for some time, and has to
be manually ran by packagers over review requests. But, there's no
reason we couldn't run fedora-review automatically over every package
submission-- which might save both reviewers and submitters a lot of

Or, as another example, there's currently a lot of work going on in
the distribution to support new packaging formats-- like containers
and modules. New workflows for making containers or modules out of
existing packages are being created, and I think it's vital we make
sure these workflows and processes are designed in such a way to make
things as easy as possible for packagers.

Anyway, as part of that discussion, I was encouraged to propose a new
Fedora Community Objective focused on improving the packaging
experience and workflow in Fedora. Community Objectives are approved
by the Fedora Council and intended to be 12-18 month goals for the
entire project. The goal of this Objective would be to identify
problems with the current packager workflow(s), put together a group
of packagers interested in fixing things, and then fix them!

If this sounds like something you'd be interested in helping out with,
great! The Objective will need two things, if it's to succeed:

1. People who are interested in helping! Some people did express
interest in the other thread, but I thought I would put out a general
call for interested packagers and volunteers. Anyone who is interested
and thinks they'll have some available time is more than welcome.

2. A concrete list of goals to accomplish. What glitches are there in
the current workflow, and how can they be fixed? What do you wish was
simpler, or better, or easier to do? What, basically, would make your
life easier a packager?

I've written an initial draft proposal [2] on the wiki here, though
the list of tasks to focus on is pretty sparse at present. If you are
interested in helping out, please feel free to add your own thoughts
as well.

Ben Rosser

[1] <a href=" ... at lists dot" title=" ... at lists dot"> ... at lists dot fedoraproject....</a>
[2] <a href="" title=""></a>


Re: Organizing a "packager experience" objective and working gro

By Artur Iwicki at 01/10/2019 - 14:47

Thanks for bringing some attention to this, Ben. I don't do a whole lot of packaging, but I admit there are some places where the workflow could be improved. I'd be willing to join the group and help where I can.

Some notes off the top of my head that I ran into recently:

- fedpkg hides quite a few tools underneath, and it's not always clear which tool is running. This becomes a nuisance when a tool requests a password, since quite often you just get a "Password: " prompt. I think bodhi does exactly that, and every time it does I scratch my head trying to remember if I should provide the GPG passphrase, FAS account password, or something else.

- Related to the previous one, error messages could be improved. Recently I had to renew my Pagure token so I could request a new repo. I renewed my token, found the config file, updated it... and nothing changed. Turned out it was the wrong config file - old, legacy location maybe? Don't know. My point is, it'd be helpful if every error that says something like "value X in config is wrong" would also specify which config file it's talking about.

- fedpkg clone performs the clone over ssh, instead of HTTPS, so if you're not logged into your FAS account, you get an "access denied" error, which is as amusing as it's irritating, given that the package repos are public.

- Now that I've mentioned it, maybe we should add something like "fedpkg fas-login"? Personally I've put "alias koji-init='kinit'" in my .bashrc, because looking up how to solve the "koji says I'm unauthenticated" error got boring after the third time.