On Wed, Dec 15, 2021 at 04:06:10PM -0500, John Snow wrote:
> Hi, this series is part of an effort to publish the qemu.qmp package on
> PyPI. It is the second of three series to complete this work:
>
> (1) Switch the new Async QMP library in to python/qemu/qmp
> --> (2) Fork python/qemu/qmp out into its own repository,
> with updated GitLab CI/CD targets to build packages.
> (3) Update qemu.git to install qemu.qmp from PyPI,
> and then delete python/qemu/qmp.
>
> This series is not meant to apply to qemu.git, rather -- it's the series
> that performs the split and would apply to a brand new repository.
>
> I am submitting it to the QEMU mailing list for these reasons:
>
> (1) To more broadly announce my intentions, and as reference alongside
> series #1 and #3 detailed above.
>
> (2) To ask for permission to become the maintainer of a
> 'qemu-project/qemu.qmp' repository, where I would like to host this
> subproject.
I'd say we need 3 designated maintainers as a minimum for redundancy.
Fine by me -- I'd like to nominate Cleber as my current co-maintainer of python/, but that leaves a third spot open. Cleber may decide to nominate someone else who is working on Avocado, too -- that'd be good too. If there was a third person who wasn't @
redhat.com, that'd be nice, but nobody comes to mind right away. Any volunteers?
Also, I can hand over control of the PyPI project(s) to the conservancy and use revocable auth tokens to perform releases. We'll cross that bridge when we get there, but I've looked into it.
> (3) To ask for review on the README.rst file which details my intended
> contribution guidelines for this subproject.
>
> (4) To ask for review on the .gitlab-ci.d/ files and other repo-level
> CI/CD ephemera, including and especially the docs-building process. I
> think the generated docs are still ugly, and I'd like to upload them to
> readthedocs, among other things -- hence the RFC quality of this series.
> Some review/RFC notes:
>
> - I use jsnow/qemu.qmp as the repo name throughout the series; that will
> have to be changed eventually, but for the purposes of prototyping, it
> was nicer to have a fully working series.
>
> - I'm planning on using gitlab issues and MRs for the subproject.
Great !
It's just easier for me, and I suspect it would be easier for non-QEMU contributors to use. I'm starting to try and target people that sit a little further out from our core project, so it seemed like it'd make the most sense.
I'll have to work out how to announce changes to the list, though ... maybe I'll have a bot announce merge requests to the mailing list, I'm not sure.
> - I plan to version this lib independently, starting at 0.0.1 for the
> initial public release and bumping only the micro version for every
> last release. I plan to bump the minor version once it hits a "beta"
> state. There will be no cross-versioning against QEMU. I don't plan to
> publish new releases during QEMU freezes.
IMHO if we're saying that QEMU is going to use this library straight
from PyPI from the start, then we're defacto considering it staable
from the start too. We can't accept changes published to PyPI that
are going to be incompatible with existing QEMU.
If that isn't acceptable, then QEMU is going to have to be pinned to
a very specific version from PyPi, and explicitly not pull the
latest.
Right, I was thinking of pinning against a specific version. I want to retain the freedom to change the API for a little while. I was worried that if I tried to make it perfect before publishing it, that I'd never actually make it perfect OR publish it.
My plan is something like this:
- Increment the micro version for any change during the "alpha" period
- Once I remove legacy.py and add a proper sync layer (Which may involve some rework of how the event listeners are factored) I want to version at 0.1.0 and call it "beta". From there, compatible changes and extensions will bump the micro and incompatible changes will bump the minor.
- After a QEMU release or two with the beta version and no major problems, I'll probably bump it to 1.0.0, call it stable, and then use semver "as normal" for all future releases.
> - Docs are not yet uploaded anywhere (GitLab pages, readthedocs?)
Since we're already using gitlab, personally I'd just setup a 'pages'
job and assign a qemu.org sub-domain to gitlab pages service.
I'll work on a pages job at least, then. I'll look at what you've written for qemu and qemu-web and do some copy-pasting.
> - Tags on a commit trigger two pipelines; this causes one of the package
> builds to fail as the version number will be duplicated in this
> case. Not entirely sure how I want to fix this yet ...
If you dont have any 'rules:' stanza gitlab creates a pipeline
for any 'push' event - this means pushes of branch commits or
pushes of tags.
To remove the duplicates we need to filter based on certain
standard variables - CI_COMMIT_BRANCH or CI_COMMIT_TAG
rules:
- if '$CI_PIPELINE_SOURCE != "push"'
when: never
- if '$CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_BRANCH'
when: never
- if '$CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_BRANCH'
when: on_success
- when: never
will cull jobs for pushes of branch commit, leaving pipelines
for tag pushes. It can get arbitrarily more complicated depending
on what you need to achieve.
OK, I'll play around with it -- thanks
Since we're going to use merge requests, we should be aiming to
*NOT* run pipelines on branch commit pushes for forks. We only
want pipelines attached to the merge request.
You'll need pipelines on pushes of tags for the post-merge publishing
jobs potentially, unless you want todo that on a nightly schedule
Regards,
Daniel
Thanks for taking a peek!
(looks at email inbox ... well, this is gonna take a second to unpack ...!)