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
<pingou(a)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