On Mon, Oct 07, 2019 at 12:54:56PM +0200, Vít Ondruch wrote: > > 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 <pin...@pingoured.fr> > >>> 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
Hm, that sounds plausible/likely but then it means we're not making it worst, just as bad. Any idea how we could improve on this? > > 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. We could include it in the PR description as we're doing with bugzilla tickets now. And fetching from the URL automatically and running some tests for it would still give us a 50% improvement then. Pierre _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
