On Sat, 28 Dec 2019 10:35:09 +0100 Fabian Groffen wrote: > Hmmm, interested to hear what kind of things you're thinking about here. A lot of the "Work" of filing a keyword request is modelling all the consequential keywordings that have to take place. If there was say, a web based UI, that: - Automatically determined which packages are ready for stabilization due to all their dependencies already being stable (and maybe with automatic cooldown-from-testing detection ) - Automatically determined which packages can be keyworded without additional work due to all their dependencies being keyworded - When requesting keywording/stabilization, automatically determined what all the consequences are and what else needs to be keyworded to satisfy it - Allowed a simple "Add keyword(s) for package " interface, that intelligently created an issue and a target list, and then once the list was built, constantly ensured the list to be valid, or determined automatically when sub-work was completed and reducing the published list automatically, and then responded to potential issues based on changes in git, ( as opposed to being only triggered when the bug was touched ) Most of the "pain" and legwork required by maintainers would go away. As it is, I feel a lot of us are reproducing a lot of logic that is rather routine and could be automated. But the overall idea here is to orient the point of keyword-requests in some way to focus on the primary objective, where the developer indicates their intent, and the system's job is to facilitate that intent coming to fruition, pointing out problems on its own. ( I have somewhat hacked together some perl scripts for myself for some of these tasks, but the command-line interface is not ideal for this workflow, and the code is not in a condition I can share it, and I don't think perl is the right language to address this problem with )