Christopher <ctubbsii@xxxxxxxxxxxxxxxxx> 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.
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
