TODO to fix in the documentation
Todo
Document (and possibly fix) what happens when workers are restarted while running a task.
Todo
We should have a simpler way to manage signing keys: perhaps they should be stored in artifacts and referenced using lookups.
Todo
Add new explanation pages to cover:
architecture (server, worker, client)
Todo
Add new reference pages to cover:
debusine-server configuration file
debusine-worker configuration file
Todo
The definition of this category is not yet fully agreed. We’ll revisit it when we’re closer to being able to try out an implementation so that we can see how the lookup mechanisms will work.
Todo
The whole expiration point needs some redesign, tracked in issue #346
Todo
Include here documentation about the various configuration files.
Todo
Check whether it’s feasible to implement this in Debusine itself as a server-side task. If not, we’ll need to make it a worker task and consider what environment it should run in.
Todo
Define the output. It should probably be a new artifact category, produced only if the task fails, containing the list of newly-uninstallable packages.
Todo
In future, we might also provide the ability to map particular repositories onto different URLs.
Todo
Add a Snapshots field to
generated Release files, pointing to the corresponding URL format.
Todo
Once we’ve defined how repository signing works, we should also publish each repository’s public keys in some standard location.
Todo
Design a way to set up a system of best-effort redirects.
Todo
Document a header in API calls used to select scope.
When the header is missing, use the fallback scope.
Make sure we have a scope-aware client in testing and stable-backports before we drop support for unscoped API calls.
Todo
Decide whether we want to support multiple configuration contexts? A task could return multiple contexts and typically the sbuild task could usefully have parameters related to the host_architecture and to the target suite, on top of parameters related to the source package.
It could be achieved with context values like suite=jessie and
architecture=arm64.
Todo
Specify how to configure keys to be used with a YubiKey.
Todo
Add more precise details of how this is recorded.
Todo
architectures should be optional, but discovering the available
architectures without having to implement delicate GPG verification code
ourselves is hard; see message #49 in #848194.
Todo
Document exactly how transactional updates of collections work in general: tasks need to see a coherent state, and simple updates to collections can be done in a database transaction, but some longer update tasks where using a single database transaction is impractical may need more careful handling. See discussion in !517.
Todo
Debian uses Extra-Source-Only: yes
to indicate that a source package is only present in an index due to
being referenced by a binary package in the suite (via Built-Using
or Source). Debusine has all the necessary information about which
source and binary packages are in the suite and how they relate to each
other, so it can add this field when generating Sources files. (We
may find that checking the relationships efficiently requires some
additional database indexes.)
Todo
This will need additional parameters once we start supporting HSMs.
Todo
It would be useful to have a mechanism to control multiarch tests, such as testing i386 packages on an amd64 testbed.
Todo
Not implemented: enable_debdiff, enable_check_installability,
check_installability_suite and enable_confirmation.
See the relevant blueprints for task installability,
reverse dependencies autopkgtest or
enable confirmation.
Todo
There should also be an option to add the results to a debian:suite collection rather than uploading it to an external queue. However, this isn’t very useful until Debusine has its own repository hosting, and once it does, we’ll need to be able to apply consistency checks to uploads rather than just adding them to suites in an unconstrained way. This will probably involve a new workflow yet to be designed.
Todo
The pipeline should also include the ability to schedule a debdiff against a baseline suite (either directly or in a sub-workflow).
Todo
We may need to use different keys for different architectures. For example, a UEFI signing key is only useful on architectures that use UEFI, and some architectures have other firmware signing arrangements.
Todo
Permission checks for this workflow are not yet implemented.
Todo
It would be useful to have a mechanism to control multiarch tests, such as testing i386 packages on an amd64 testbed.
Todo
It would be useful to be able to set base_tgz separately from
environment.
Todo
Not implemented: enable_check_installability and
check_installability_suite.
Todo
We will probably need the ability to control parameters such as
fail_on in sub-workflows, but these are often quite
package-specific.
Todo
This workflow does not currently handle checking for regressions against a base reference.
Todo
Reverse-dependencies are not currently restricted by version (e.g. due
to versioned dependencies) or architecture (e.g. due to
architecture-restricted dependencies, or the architectures field in
task data).
Todo
Future work is
needed to sign Release files, and will need to be integrated into
this task. That will probably involve creating a new sub-workflow that
can deal with generating and signing indexes for a single suite. Once
archives have been implemented, we may also
want to group all the updates for suites in a given archive under a
single sub-workflow.
Todo
Valid-Until can be supported by adding a field to the suite collection specifying the validity period. This workflow would then additionally include all those whose validity period is nearly up in its search criteria.