FPF's openqa-tests-qubesos fork

[deeplow]

We're now running automated tests in the Qubes team's OpenQA. To edit tests we do so at the repo openqa-tests-qubesos.

What we're currently doing

We've been upstreaming all our changes to the original repo. Occasionally, when we want to test something or override a certain behavior we've also created personal forks, which we can easily set for specific builds.

What is the issue?

There are a couple of issues we're running into:

• Hard to keep track of pending changes: replying on personal forks is not best practice because it's hard to keep track of the pending changes.
• Synchonization in merging PRs - sometimes we need a quick fix in the OpenQA code before merging a PR. We could coordinate with upstream to having these merged. Even though these are usally promptly merged, it's an unecessary round-trip and cross-org synchornization, especially we want to get something in quickly or divide the work in small fixes
• Where to report securedrop-specific OpenQA issues? We've been filing these in the workstation repo, but eventually we'll also want the client to run OpenQA tests. At this point it's probably best if we could just report these in a fork.

What's being proposed?

• fork openqa-tests-qubes
• set up a period upstream rebase job (or equivalent), so we don't let it go stale
• periodically open a PR against upstream

[deeplow]

@legoktm any thoughts? There are quite a few things in-flight for OpenQA and keeping track of them simply in branches has been a bit challenging to deal with. On the other hand, some are only drafts and I don't think like I should open them against the upstream repo in their current stage, just for them to sit there for a while.

[legoktm]

Yeah, let's create a fork with all our patches, and we can send PRs from it to the Qubes OS repo. I think for now we can rebase it manually and figure out automation later on.