On Wed, Oct 2, 2019 at 8:17 PM Ben Rosser <rosser....@gmail.com> wrote:
> 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:

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
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