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

["Daniel P. Berrangé" <berrange@redhat.com>]

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.

> (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 !

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

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

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


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
-- 
|: 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 :|