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