On Tue, Feb 23, 2021 at 09:28:34AM -0500, Matthew Miller wrote: > On Mon, Feb 22, 2021 at 10:09:54AM -0800, Kevin Fenzi wrote: > > > - Get rid of manually open and manage Bugzilla tickets. Have the ticket > > > filed in a web form (or maybe by CLI), and have the ticket workflow > > > managed automatically. > > > > Could we do away with using bugzilla entirely and just keep info in app? > > I have mixed feelings here... on the one hand, bugzilla is awkward, > intimidating, and creaky. But, it's nice to have all that review history in > a consistent archive. If we move to a dedicated app, maybe it could at least > do a one-way sync to bugzilla for the record? I tend to thing Fedora's new package process needs something more radical to bring it into the modern age. Lack of automation in the review process is an issue, but I think the problems are much broader and more fundamental than that. Fedora has always had rather a split personality where the workflow and tools for new packages process is completely distinct from the workflow and tools for ongoing package maint. Both new package process and ongoing maint look quite dated by modern development standards but we have slowly been pulling dist-git into a slightly more modern world with the ability to have merge requests. I think we need todo the same with new package review process and make it align with the way ongoing package maint works, using the same set of tools and modern processes. Creating a new standalone review app IMHO re-inforces the division between initial review work and post-acceptance maint work. Automation is good of course, but most of the automation tasks done at package review and also things that should be done on an ongoing basis for existing packages and their merge requests. IOW, any new automation ought to tackle both use cases, rather than re-inforcing our historical mistake of having new package review be completely distinct from everything else. IOW, I would like to see us bring package review process into the modern world, such that the first step is the user creating their own personal repo containing the new package. Then opening a merge review to request it graduate into official dist-git. Any automated tools and processes (legal review blockers), should be associated with the merge request, so everything is tracked in one place, in the same way it does after acceptance. Using git lets reviewers see how the spec file gets changed by the contributor after each round of feedback. We can give comments on specific lines in the spec, instead of having to copy + paste quoted text into BZ or another tool to give context. There's so much more potential for creating a positive review experiance if we start with a modern foundation, than continuing to hack stuff onto our historic process. I can't take credit for the idea of this kind of approach. It is something I experienced when contributing applications to FlatHub, and was pleasantly surprised at how much slicker it is than Fedora's new package process. https://github.com/flathub/flathub/wiki/App-Submission Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
