On Fri, Oct 04, 2019 at 06:57:55PM +0200, Vít Ondruch wrote: > > Dne 04. 10. 19 v 18:10 Fabio Valentini napsal(a): > > 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. > > It is, but I am afraid that then we will have Foo, foo, FOO and fOo > repositories and we won't be able to get rid of them for similar reasons > we are not allowed to delete branches in current dist-git. You are allowed to force-push/delete branches in your fork. So if the issue is found before the review is approved this should be fine, no? > Also this ignores possible issues with patented or inappropriately > licensed code. If the code is patented or with an inappropriate license, this should be caught by the review no? If so, then once the fork and its destination project are deleted we should be fine again, no? Note: I'm not proposing that we allow/encourage uploading to the lookaside cache with this workflow, this would indeed create more work for infra/releng to clean things up if the PR is rejected (but I'd point out that nothing prevents early uploads of sources to the lookaside already today). 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
