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.
> Is the Fedora dist-git instance set up to enable ACL lists made
> 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?
> As I understand it, RHEL QE has a setup with a "tests"
> which stores all the tests for a package whose name matches the
> name of that repo from the tests namespace. If we use "tests" as
> the namespace here, I fear that we will be adding to confusion from
> the people who are used to the RHEL version of a "tests"
I believe all tests should be linked from the package's dist-git -
wherever that path may lead (in the dist-git itself or another repo,
I don't understand how this relates. There is a similarly named
system/setup used by many of the same folks who will be contributing
tests and working on tests in this new CI paradigm. I'm concerned that
the similar name and function will lead to confusion and a steeper
learning curve. Specifically, I'm talking about the tests/ namespace
used inside Red Hat by QE folk to store tests and test-related data
outside of the package's repo.
> - For the PR testing case, how will the shared tests be
> that PR set for testing purposes?
All relevant tests should be linked to the repo where they will gate
changes (e.g. changing shell tests will gate on those passing on bash,
ksh, et cetera).
That's fair enough but my question was more around situations where you
need both changes to land at the same time so that the test doesn't
fail. Having a modified workflow in Pagure to support multiple repos in
the same PR is one solution to one problem - what about tests which are
stored in upstream projects or just outside of dist-git? Is it going to
be possible to change both the tests and the packages at the same time
without seeing what are effectively false positives from the various CI
systems? If so, what is the planned workflow for dealing with
> - Will there be some delay in test/build kickoff on dist-git
> change to allow for tests to be pushed around the same time that
> there are code changes? Otherwise are we planning to expect some
> transitory failures if both the tests and packages need to
> change at the same time? Are there plans to verify that things are
> properly re-run if those transitory errors happen?
The best way here is to reference the exact version of the tests you
want, by git repo and revision. Then you don't depend on chance and
you can safely change the tests first, then the dist-git repo.
Does that mean that test runs won't be triggered on test change? Unless
I'm missing something, how will we be dealing with the eventual issues
where the git commit is out of date and propagates incorrect data
through the pipeline?
For example, say that the tests for the package foo point to more tests
in a foo-tests.git repo. If I change those tests and don't change the
package - a triggered test run would likely indicate that my change
continues to pass without issue.
> I realize that there are plans to handle situations like this
> automatic reversion but to the best of my knowledge, that system
> doesn't exist yet (an admin could back stuff out before the
> automation exists, too). If we demand that packagers go through a
> vetting and mentoring process even if they're a co-maintainer, why
> shouldn't we have a similar requirement for the folks who can
> change the tests which are responsible for gating the bits we
The starting point of test execution is the dist-git repo itself,
which underlies the known restrictions. It is up to the packager to
decide which other repo to link to, if at all. The tests could
feasibly be in the dist-git repo itself or any other repo the
packager trusts (and that is publicly accessible). If we should limit
that choice somehow, we need to discuss it.
I'm not sure I understand your response here. Does that mean that
contributions from non-packagers is not deemed important enough to
worry about at this time? If so, how do we plan to get ported tests
from downstream RHEL into Fedora if QEs are currently doing much of
the porting work?
> It makes sense, just some concerns about the specifics of this
> proposal. Thanks for putting so much time into this.
Thank you for your feedback!
Not a problem. Thanks for your quick response.