On Wed, Jan 31, 2018 at 02:21:45PM +0100, Tim Flink wrote:
On Tue, 30 Jan 2018 18:32:02 +0100 'Dominik Perpeet' dperpeet@redhat.com wrote:
I will try to address a few of the points.
On 01/30/2018 04:33 PM, Tim Flink wrote:
How are git repos in different namespaces of a larger repo ecosystem easier to link together than just urls that point to github or pagure.io ?
There has been some talk about pulling in tests that live in upstream repos which makes me think github. If this is true and we're going to be pulling other things in from github/pagure/gitlab/wherever, why not just have these shared repos in pagure.io?
There is no technical reason currently, other than the convenience of grouping. One of the possible options with grouped repos is the ease to add something in the future, such as modifying access control or even providing optimized Pagure workflows for common use cases.
This didn't make a lot of sense to me until we spoke in person earlier today.
The bit I was missing was that there's a chance that Pagure could be enhanced to have a workflow which covers multiple repos with the same PR which would solve some of the concerns I have.
I think the idea is to find a way to link multiple PRs together (something as simple as using: Requires <url to PR> in the commit message for example), rather than figuring out how to do 1 PR against multiple repos (which in the case of dist-git practically do not overlap in anyway).
Is the Fedora dist-git instance set up to enable ACL lists made up of users who are not already packagers and who don't otherwise have write access to the corresponding package repo? If not, how much extra work are we talking about? Are there available cycles to get the work done in short order?
Currently only fedora "packagers" have access to dist-git itself for actions such as cloning. There is a workaround to open pull requests from other git repos: https://fedoraproject.org/wiki/CI/Tests#Creating_pull_request
I thought that PRs were the main solution to allowing contributions from people who aren't already packagers. Has this changed or is the implementation of non-packager PRs still pending?
The situation is the latter. There is a will to allow PRs from non-packagers and the infrastructure team discussed it last week again, but this hasn't been implemented yet.
Pierre