Re: New "tests" namespace to share test code

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

 



>> To sum up what I've heard so far from the developer side:
>>
>> * I would like to enable tests for my component (yes, I want)
>> * I will take care of them (really, I see the benefit in CI)
>> * I want to easily collaborate on tests with qe (direct commits)
>> * I don't want to give qe commit access to the rpms dist git
> This is quite likely the crux of the problem.
>
> Personally, I'm perfectly happy to give write access to any repo
> to people who have shown that they know what they are doing.
> We have pull requests in dist-git pagure now, and I think this is
> a better approach:
> 1. ask QE contributors to submit PRs
> 2. if enough cooperation happens and trust is established, give
>   privileges to write to the repo directly, possibly with an agreement
>   that this specific person should only touch tests, and not the
>   packaging.
>
> I think it's perfectly fine to never get to point 2.: many many
> upstream projects require a review from a second person, or sometimes
> even two reviews before a PR is merged, which means that one _never_
> merges their own PR, and another contributor is always involved. We
> usually don't do this in dist-git, but I'm quite sure that requiring
> reviews for dist-git changes would raise quality and catch many silly
> mistakes. Either way, it's nowadays possible to cooperate using a
> single repo without fully trusting the other person, frictionlessly.

Good point. However, if there is a qe/devel team which prefers to
collaborate on tests in a separate repo because this is the most
efficient way they found so far, why should we stop them and try
to enforce a less efficient workflow? (Which they can workaround
by a different git repo.)

>> * I want to efficiently maintain tests long-term
>> * I want to have just a single place for my tests (no duplication)
>> * I don't want to backport new tests to old branches (enable once)
>> * I want to easily enable testing for all supported branches
> Those four items depend strongly on the package. My thinking is
> biased by some specific usecases (mainly systemd), but I'm sure many
> other packages are like that: a lot of tests would be for new
> functionality, and then the tests _are_ tied to the branch being
> tested.
>
> While I agree that keeping tests separate avoids a bit of effort
> required to update multiple branches, this effort isn't very big. If
> the tests indeed apply cleanly to all branches, then it's just a
> matter of doing 'git merge' or 'git cherry-pick' once per branch.
>
>> * I want to keep rpms dist git clean (just metadata & patches)
> Meh.
>
>> * I want to run all available relevant tests (not to list them)
>> * I want to execute set of tests based on a tag (e.g. Tier1)
> Those two sound like stuff that should be solved in the tooling,
> whatever is used to run tests.
>
>> * I want an easy way to clone tests (fedpkg clone tests/pkg)
> Tests alone make no sense, you need something to test, and
> cloning one repo is easier than cloning two repos, so there's no
> advantage to the split here.

But "fedpkg clone tests" is easier than cloning from a "random"
git repository where I was forced to save my tests because I was
not allowed to save them in Fedora tests namespace.

>> I believe the tests namespace resolves them all.
> None of those arguments convince me that separate repos for tests are
> a good default. Sure, there are specific packages where this will make
> sense, or specific packagers with idiosyncratic workflows, but I'd
> rather "start small", with the simple configuration, and only move
> specific packages to the more complicated setup once that proves to
> be required.

Why default? Test namespace should be an option. Not the default.
Storing tests directly in dist git is and will be possible.
Anybody who finds this as a better way can do so. But why
enforcing this approach to all?

psss...
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [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