On Wed, Oct 02, 2019 at 08:17:37PM +0200, Ben Rosser wrote:
> 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:
I very much agree with what Ben says. We need to improve the
integration between different components of the packaging infra.
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?
Yep. Not every package is the same. For stuff like simple
python/nodejs/rust/ruby/perl/… packages, I know that the only thing
I do is mechanically bump the version and rebuild. I don't take a careful
look at the changes in the package, I don't do any non-automated checks;
if it builds, it gets shipped. For such packages, there really would be
no difference if a bot was doing all the steps I'm doing now.
But I don't think creating things from scratch is the answer. I think
we need to find ways to extend and integrate what we already have.
In particular, if we want to keep support for existing workflows
that people use, we cannot just add new services and deprecate
an old one. We need to grow new functionality in the existing ones.
Zbyszek
> 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.