On Wed, Oct 2, 2019 at 1:59 PM Pierre-Yves Chibon <pingou@xxxxxxxxxxxx> 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 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@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
