Re: Defining the future of the packager workflow in Fedora

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux