https://bugzilla.redhat.com/show_bug.cgi?id=2112474 --- Comment #27 from John Snow <jsnow@xxxxxxxxxx> --- (In reply to Maxwell G from comment #25) > (In reply to Cole Robinson from comment #22) > > FWIW offthread I've also offered to sponsor jsnow, > > If you want to do the sponsoring in the end, that's fine with me, but I > already started this review, so I might as well finish it :). Thanks for your time, again. I didn't want to *tell* Cole he was going to do it, and I just hadn't heard back from him when I started this process. > > > Keep in mind that you won't be able to push incompatible updates to this > > > package in stable updates, either. Given that this is an alpha package, > > > you'll have to take that into consideration. > > > > Understood! > > (You called it an alpha package -- is that because you read my readme?) > > Yes, I did :). > No better feeling than when someone reads your README :D The package is quite "stable" in the sense that a vendored version of this library has been in-use for the qemu.git test suite for over a year now (And is now being used aggressively in our third testing cycle -- it gets tested on many distros and BSDs and many versions thereof), but I wanted to leave myself ample room to make adjustments as I packaged it for PyPI, Fedora, etc. (I'm a coward: releasing a 1.0.0 out of the gate is too prideful that it begs for a fall.) The remaining GPL2 (only) code in legacy.py needs to be removed and replaced with a more intentionally designed synchronous interface, but the qemu.git test suite needs to be updated to use that new stuff first. So there are some "big" API changes planned for the near future, but mostly around legacy.py. (legacy.py implements a nearly identical API to the synchronous QMP library we had in-tree since 2010 or so. There are many projects on git that just copied it out of our tree verbatim, so I am fixing that.) The core of the library should be reasonably stable, but it's entirely possible that I'll want to shift things around a little to accommodate features needed for the sync interface -- to provide something that's more idiomatic and useful for synchronous paradigms instead of a glorified and hacky wrapper shim. That's the plan for 0.1.0. Once 0.1.z goes through a testing cycle or two for QEMU, I'll probably release the v1.0.0 -- so maybe another year or so. In practice, it usually takes about two releases for more esoteric platforms to phone home and inform us of problems. > > > Ah, I see. OK, I've mostly implemented your suggestion, but I did spell out > > "python-qemu-qmp-doc" explicitly instead. > > (No strong reason, I guess I liked the visual parity? Will change if > > desired.) > > I'd prefer `%package doc` and `%files doc`. > OK, no problem -- I'll do that on my local copy and have it ready when the dust has settled for avocado-framework. (I admit I tried it this way first, but goofed something else, so spelling it out was a debugging step that I just didn't... change.) > > > Is it common to reproduce the same description for the doc package? I picked > > a few at random and it didn't seem that way, but I did it anyway. > > I'm not really sure what's more common, but yes, that's what I'd recommend. > Fair enough! > > I then found this blurb concerning pypi_source on the packaging guidelines: > > "For backward compatibility, the first argument is technically optional as > > well, but omitting it is deprecated. (It defaults to %srcname if defined, or > > to %pypi_name if defined, or to %name.)" > > Yes, that's a good point that I sometimes forget. `%{pypi_source qemu.qmp}` > would be best here. > > > > > > rm %{buildroot}%{_bindir}/qmp-tui > > > > > > I'm not a fan of this. Fedora packages should try to stay close to upstream > > > projects[1], and this feels like a deviation from that. I'm happy to help > > > you split it out into a subpackage if needed. However, if you still maintain > > > that this shouldn't be packaged, I won't push hard on it. > > > > > > [1]: > > > https://docs.fedoraproject.org/en-US/package-maintainers/ > > > Staying_Close_to_Upstream_Projects/ > > > > Understood. Currently, the TUI requires some packages that Fedora does not > > yet package. > > What are the missing dependencies? At least looking at the tui extra, all > three of those packages exist in Fedora. ... Oh! *cough*. I won't say what version of Fedora I am running on my development machine, but I will inform you that urwid-readline does not exist there ;) ... I'll upgrade this weekend. Well. OK, I suppose I *could* make an RPM subpackage for it here and now, then, but it's *way* more actually-an-alpha than the rest of the library, so I admit to some reluctance to do it anyway ... I nervously want to clean house a little bit first upstream as I really didn't have plans on stuffing this half-finished TUI into Fedora yet. The problem might also resurface: my draft branches for improvements to the TUI involve an even more niche urwid plugin, and I am quite confident that's not in F36, at least. - Did you get a chance to look at the 2nd spec file I posted that includes the %check phase? I had a question on how best to set up the PYTHONPATH env var (et al). What I wrote appears to work so far as I have been able to test it, but it feels possibly brittle and/or overcomplicated. -- You are receiving this mail because: You are always notified about changes to this product and component You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2112474 _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-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/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
