TODO to fix in the documentation
Todo
Another possible idea is to use collections for the output of each task, either automatically or via a parameter to the task.
Todo
Add new explanation pages to cover:
architecture (server, worker, client)
Todo
Add new reference pages to cover:
debusine-client configuration file
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
Document all the subcommands.
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
Consider some of the steps that we expect to implement and double check that they can be implemented in such a framework.
Todo
We also need to specify how the child task is told to update the derived collection. This will probably depend on actions, as specified in !630.