Re: [RFC qemu.qmp PATCH 00/24] Python: Fork qemu.qmp Python lib into independent repo

[John Snow <jsnow@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 6307 bytes --]

On Thu, Dec 16, 2021 at 5:41 AM Daniel P. Berrangé <berrange@redhat.com>
wrote:

> 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 ...!)

[-- Attachment #2: Type: text/html, Size: 8331 bytes --]