On Tue, Feb 23, 2021 at 10:35 AM Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote: > > 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 > This is also how openSUSE's package process works too with the openSUSE Build Service. Pierre-Yves and I had discussed the idea of supporting an extension to Pagure to offer this workflow right in the application. As for the legal review aspect that Ben brought up, I think bringing in openSUSE's Cavil[1] application into Fedora and leveraging that as part of this pipeline would be a much better way to handle this. I have been slowly working on packaging this so that we can run it for this purpose. Pagure + new package review extension + cavil would allow us to finally get rid of fedora-review and all the other weird things we use and unify our new package workflow with our ongoing maintenance workflow. Pagure's ability to take PRs sourced from other Git servers also means that we don't need to figure out how to deal with storing code before it's been accepted into Fedora, too. [1]: https://github.com/openSUSE/cavil -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
