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. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
