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
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.
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
actions such as cloning. There is a workaround to open pull requests
from other git repos:
As I understand it, RHEL QE has a setup with a "tests" namespace 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" namespace.
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,
- For the PR testing case, how will the shared tests be included in
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).
- Will there be some delay in test/build kickoff on dist-git repo
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.
I realize that there are plans to handle situations like this with
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 release?
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.
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!