Christopher <ctubbsii(a)fedoraproject.org> writes:
I just don't see this proposed workflow as solving the biggest
problems that packagers face. For me, I think the biggest problem that
packagers (particularly newer packagers) face is discovery of all the
services involved in the packaging workflow, and the need to visit
separate UIs to get answers.
Rather than try to automate the workflow through these separate
services, I'd rather work be done to create a central packager
interface that helps packagers track where a package is in the
workflow, and to facilitate moving from one phase to the next. For
example, an interface could show something like a list of branches for
a package, and whether there is a corresponding build from those
branches. A button to the right of each branch could be shown which
does the equivalent of `fedpkg build` on that branch (grayed out if
there exists a build already for that commit and branch), and then
another column with a similar button to create an update.
In addition to helping the packager move a package through the
workflow, such a centralized interface would also provide information
about dependencies, their orphan/retired status, whether they've
changed since the last build. It could also show a listing of bug
reports, help maintain co-maintainer privileges, and other similar
stuff. Basically, everything the packager needs in one place.
I think such an interface would be far more useful, just to document
the existing workflow, and help packagers know what to do, than trying
to change the workflow and automate it. We shouldn't be looking at
disruptive changes to the workflow... we should be looking at lowering
the bar to packaging by making it easier to manage the current
workflow. And then, if we find that there are changes to the workflow
itself, we do that later, with corresponding changes to the
centralized interface.
What you want is essentially the Open Build Service
(
https://build.opensuse.org/), just for Fedora.
And yes, having something like that would be *really* good, especially
having all the overviews, build states, updates, dependencies, etc. in
one single place.
The only danger in this is, that this overview app can grow into a huge
monolith, that becomes impossible to extend at some point because it
swallowed all the functionality of our individual infra and became too
complex... But that can be avoided, if it is "just" an overview and the
rest stays the way it is.