Dne 07. 10. 19 v 12:00 Pierre-Yves Chibon napsal(a): > 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. To be able to have the fork, you have to have the repository to fork from. So I can imagine there will be process like "open ticket for releng and fill this template". But I can't imagine it will be reviewed by relengs, when they currently don't review the repo names and therefore we have issues like: https://pagure.io/releng/issue/7523 > 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, But where will you get the sources to build the package then? Yes, for simple cases, you can use the source URL to fetch the tarball, but I assume that this will work approx just for 50 % packages. Vít > 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
