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@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.
- 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:
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