On Wed, Oct 2, 2019 at 1:59 PM Pierre-Yves Chibon <pin...@pingoured.fr> wrote:
> There are regularly people complaining on this very list about how hard
> packaging has become. So here is a thread trying to see if you can come up 
> with
> a long term, ideal, vision of what the packager workflow should be so we can
> work towards it.

I'm such a person. I tried to put together an Objective on this topic
back in January before realizing I didn't have enough time to drive it
forwards due to real life commitments.

I may not have said it explicitly in my other replies on the thread,
but I _am_ glad to see people thinking seriously about ways to improve
the packager experience. So I appreciate your proposal, even if I
disagree with the proposed pull request workflow.

That being said...

> I'm going to ask again what was in my original email: What is your ideal
> workflow? How do you think things should work?
> Is what we have today the ideal state of things?
> If so, great!
> If not, what can we improve and are there things we can easily change that 
> will
> make it easier for a majority of packagers?

My feeling is that you've focused on the wrong part of the workflow.
My feeling is that the basic "commit, push, build, repeat" part of
packaging works reasonably well for most packages. Sure, it isn't
perfect, and it can be tedious to keep branches up to date across many
packages, and it'd be nice if there was more continuous integration
and running of a tests.

But as a packager, the things that frustrate _me_-- the things I was
proposing to help fix, before I realized tha are all the peripherals:
the bits of the infrastructure that don't feel like they interact as
well with the workflow as they could. At the moment, two of my biggest
complaints are:

1. Creating new packages has become (more of) a pain since the
retirement of pkgdb2. I know I keep complaining about needing to
manually fetch Pagure API keys, but it is actually extremely annoying
when I go to request a repo and realize I need to first request a new
API key before doing anything else. The problem isn't the workflow,
per se, but the infrastructure: reviews could really use a better
platform than bugzilla. If reviews were more integrated into the
tooling, automatic checks like fedora-review could maybe be ran
automatically. Maybe approving a new package could even automatically
create the repository, without the requestor having to do anything!

2. Release monitoring is a wonderful tool, but it's poorly integrated
with the rest of the project. As a packager maintaining probably more
packages than I should, getting release monitoring notifications to
tell me to pay attention to a particular package is incredibly useful.
But I feel like we could do more with the information. There are
nodejs packages out there, to take an ecosystem at random, that have
had open tickets created by release monitoring for four+ years, and
the only activity on those tickets is the release monitoring bot
detecting new versions. Eventually, maybe, a human comes across the
package and realizes it might be unmaintained, and proceeds with the
nonresponsive maintainer policy or manages to track down the
maintainer to find out why the package hasn't been updated. I don't
say this to criticize anyone in particular, but surely we could be
more proactive here?

Basically, I don't think we really need an entirely new packaging
workflow. (I would argue that attempts to impose an entirely new
packaging workflow-- like modularity-- are one of the reasons
packaging has gotten harder recently...). We need to improve the
contributor-facing _infrastructure_ to make the current workflow

I would personally advocate starting with a serious look at the review
process, and the tooling around it. If for no other reason than it is
the first thing most new contributors will interact with, so perhaps
it is in our interest to make it as pleasant as possible.

Ben Rosser
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 

Reply via email to