On Wed, Oct 2, 2019 at 8:17 PM Ben Rosser <rosser.bjr(a)gmail.com> wrote:
On Wed, Oct 2, 2019 at 1:59 PM Pierre-Yves Chibon <pingou(a)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:
Whoops, I meant to write here:
"things I was proposing to help fix, before I realized that I didn't
have the time"
>
> 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
> better.
>
> 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