On Fri, Oct 4, 2019 at 5:54 PM Pierre-Yves Chibon <pingou@xxxxxxxxxxxx> wrote: > > On Wed, Oct 02, 2019 at 08:17:37PM +0200, Ben Rosser wrote: > > Thanks for your words, I appreciate the support on the idea. > > > 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! > > So I've been wondering a little bit how we could solve this and I've been > wondering if we couldn't leverage the PR workflow for this. > Imagine: > - You request a new repo to be created > - The new repo is automatically created from your request > - You fork it > - Push your spec file and patches to your fork > - Open a PR against the empty repo > > The package review becomes then a basic PR. We could leverage the tools we are > working on for regular PRs. > If the PR is approved, you get access granted to it. > If the PR is denied, both repo are deleted. This is an interesting idea. And it would definitely be better than doing the bugzilla dance every time ... It would be great if the initial commit could then be squashed when it's finally approved and merged :) > > 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? > > So there are a few works in the pipes for this. > Dist-git in staging already offers a better integration between dist-git and > anitya, you can see it for example at: > https://src.stg.fedoraproject.org/rpms/guake on the left hand side column. > the-new-hotness is being adjusted so that it opens a pull-request rather than a > bugzilla ticket. This doesn't quite solve the issue of "there is no-one to > review the ticket/PR" though. I have never looked at the patches that the-new-hotness generates, but automatically filed PRs would actually be helpful, and easily actionable. This sounds awesome, and would make simple "bump + build" updates pretty much automatic and painless \o/ Thanks for working on all this, Fabio > Packit ( https://github.com/packit-service/packit/ ) is also aimed at helping > with speeding up the flow from upstream to downstream. > > > 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. > > Trying to improve the package review process is something that has been in my > radar for a while now but not high enough in the priority list. > > > Looking forward to hear your thoughts, > Pierre > _______________________________________________ > 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 _______________________________________________ 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
