Create qemu-project/py-qemu.qmp repo

Create qemu-project/py-qemu.qmp repo

[John Snow]

Hi Alex: do you have the ability to create a blank/empty "py-qemu.qmp"
repo under the qemu-project grouping, and add me and Cleber as
maintainers for it? There weren't any objections when I floated the
idea [1].

(Though I suggested "py-qemu.qmp" and Dan suggested "python-qemu.qmp".
I don't think we explicitly reconciled the difference. I like the
shorter one.)

After my most recent Python PR is merged [2], I'll be just about ready
to go on pushing a fork of this library into its own repo [3], so I
think it's time to actually create the repo. I intend to re-spin that
fork patchset [3] (updating the URLs involved) and see if there are
any final comments, then push to the new repository.

[1] https://lists.gnu.org/archive/html/qemu-devel/2022-02/msg00979.html
[2] https://patchew.org/QEMU/20220421151600.984189-1-jsnow@redhat.com/
[3] https://lists.gnu.org/archive/html/qemu-devel/2022-03/msg07176.html

Thanks,
--js

Re: Create qemu-project/py-qemu.qmp repo

[Andrea Bolognani]

On Thu, Apr 21, 2022 at 12:46:48PM -0400, John Snow wrote:
> Hi Alex: do you have the ability to create a blank/empty "py-qemu.qmp"
> repo under the qemu-project grouping, and add me and Cleber as
> maintainers for it? There weren't any objections when I floated the
> idea [1].
>
> (Though I suggested "py-qemu.qmp" and Dan suggested "python-qemu.qmp".
> I don't think we explicitly reconciled the difference. I like the
> shorter one.)

Since you CC'd me to this message, I'm going to assume you're
explicitly welcoming my input on what specific shade this bikeshed
should be painted ;)

I think I would go with "python-qemu-qmp". Having a dot in the name
of a git repo is not very common AFAICT, and I wouldn't rule out the
possibility of some GitLab feature or other tooling breaking or
misbehaving because of it.

If you're really keen on saving those few extra keystrokes, maybe
"pyqemu" is a better prefix than "py-qemu"? I don't know, it just
looks more natural to me.

-- 
Andrea Bolognani / Red Hat / Virtualization

Re: Create qemu-project/py-qemu.qmp repo

[John Snow]

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

On Thu, Apr 21, 2022, 2:00 PM Andrea Bolognani <abologna@redhat.com> wrote:

> On Thu, Apr 21, 2022 at 12:46:48PM -0400, John Snow wrote:
> > Hi Alex: do you have the ability to create a blank/empty "py-qemu.qmp"
> > repo under the qemu-project grouping, and add me and Cleber as
> > maintainers for it? There weren't any objections when I floated the
> > idea [1].
> >
> > (Though I suggested "py-qemu.qmp" and Dan suggested "python-qemu.qmp".
> > I don't think we explicitly reconciled the difference. I like the
> > shorter one.)
>
> Since you CC'd me to this message, I'm going to assume you're
> explicitly welcoming my input on what specific shade this bikeshed
> should be painted ;)
>

More of a "Speak now or forever hold your peace" 😅

I think I would go with "python-qemu-qmp". Having a dot in the name
>
of a git repo is not very common AFAICT, and I wouldn't rule out the
> possibility of some GitLab feature or other tooling breaking or
> misbehaving because of it.
>
> If you're really keen on saving those few extra keystrokes, maybe
> "pyqemu" is a better prefix than "py-qemu"? I don't know, it just
> looks more natural to me.
>

The idea is to have the repo name resemble the Python package name, which
is "qemu.qmp". For Python, it's customary to have the package name match
the import name. The import name is "qemu.qmp".

I tested this name on GitLab and it appears to work just fine.

I'd add "py:" as a prefix, but the colon doesn't work as a filename in many
places, so I suggested "py-".

Thus, all together, "py-qemu.qmp".

(I could spell out "python", I just prefer the shorter prefix because it's
explanatory enough as-is and I like keeping git checkout names short. My
favorite color of bike shed is blue.)


> --
> Andrea Bolognani / Red Hat / Virtualization
>
>

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

Re: Create qemu-project/py-qemu.qmp repo

[Andrea Bolognani]

On Thu, Apr 21, 2022 at 05:00:16PM -0400, John Snow wrote:
> On Thu, Apr 21, 2022, 2:00 PM Andrea Bolognani <abologna@redhat.com> wrote:
> > I think I would go with "python-qemu-qmp". Having a dot in the name
> > of a git repo is not very common AFAICT, and I wouldn't rule out the
> > possibility of some GitLab feature or other tooling breaking or
> > misbehaving because of it.
>
> The idea is to have the repo name resemble the Python package name, which
> is "qemu.qmp". For Python, it's customary to have the package name match
> the import name. The import name is "qemu.qmp".
>
> I tested this name on GitLab and it appears to work just fine.

I'm concerned about issues that you'd only trigger when using
certain, perhaps less common, features.

Here's an example of such an issue from just a year ago:

  https://gitlab.com/gitlab-org/gitlab/-/issues/224669

There's an epic tracking more issues of the same kind, though
admittedly most were addressed four years ago:

  https://gitlab.com/groups/gitlab-org/-/epics/3740

Up to you whether you feel confident enough that you're not going to
run into issues later.

> > If you're really keen on saving those few extra keystrokes, maybe
> > "pyqemu" is a better prefix than "py-qemu"? I don't know, it just
> > looks more natural to me.
>
> I'd add "py:" as a prefix, but the colon doesn't work as a filename in many
> places, so I suggested "py-".
>
> Thus, all together, "py-qemu.qmp".
>
> (I could spell out "python", I just prefer the shorter prefix because it's
> explanatory enough as-is and I like keeping git checkout names short. My
> favorite color of bike shed is blue.)

You can absolutely have short names locally even when things are
spelled out in GitLab.

Anyway, in this case my taste in names is clearly simply different
from yours and you should absolutely feel free to ignore my opinion
on the matter :)

-- 
Andrea Bolognani / Red Hat / Virtualization

Re: Create qemu-project/py-qemu.qmp repo

[John Snow]

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

On Fri, Apr 22, 2022, 4:37 AM Andrea Bolognani <abologna@redhat.com> wrote:

> On Thu, Apr 21, 2022 at 05:00:16PM -0400, John Snow wrote:
> > On Thu, Apr 21, 2022, 2:00 PM Andrea Bolognani <abologna@redhat.com>
> wrote:
> > > I think I would go with "python-qemu-qmp". Having a dot in the name
> > > of a git repo is not very common AFAICT, and I wouldn't rule out the
> > > possibility of some GitLab feature or other tooling breaking or
> > > misbehaving because of it.
> >
> > The idea is to have the repo name resemble the Python package name, which
> > is "qemu.qmp". For Python, it's customary to have the package name match
> > the import name. The import name is "qemu.qmp".
> >
> > I tested this name on GitLab and it appears to work just fine.
>
> I'm concerned about issues that you'd only trigger when using
> certain, perhaps less common, features.
>
> Here's an example of such an issue from just a year ago:
>
>   https://gitlab.com/gitlab-org/gitlab/-/issues/224669


For mailing list context, this bug appears to concern label names with a
dot; due to bad URL generation that can be fixed manually using %2e.


> There's an epic tracking more issues of the same kind, though
> admittedly most were addressed four years ago:
>
>   https://gitlab.com/groups/gitlab-org/-/epics/3740
>
> Up to you whether you feel confident enough that you're not going to
> run into issues later.
>

There's always the chance for bugs, right? I'm not too concerned - I didn't
run into anything by now, and I've been working on this stuff for a while.

Can't promise it won't ever happen, but I value consistency with the
package name more than I value avoiding possible bugs.

Valid to wonder, but I think the tradeoff is appropriate here.


> > > If you're really keen on saving those few extra keystrokes, maybe
> > > "pyqemu" is a better prefix than "py-qemu"? I don't know, it just
> > > looks more natural to me.
> >
> > I'd add "py:" as a prefix, but the colon doesn't work as a filename in
> many
> > places, so I suggested "py-".
> >
> > Thus, all together, "py-qemu.qmp".
> >
> > (I could spell out "python", I just prefer the shorter prefix because
> it's
> > explanatory enough as-is and I like keeping git checkout names short. My
> > favorite color of bike shed is blue.)
>
> You can absolutely have short names locally even when things are
> spelled out in GitLab.
>

Sure, but it's more steps and I personally never change the name when
copy-pasting the "git clone" snippet. I assume most don't either.


> Anyway, in this case my taste in names is clearly simply different
> from yours and you should absolutely feel free to ignore my opinion
> on the matter :)
>

Thanks for weighing in. I'm not ignoring your feedback, but I think I'm
still happiest with "py-qemu.qmp" for now.


> --
> Andrea Bolognani / Red Hat / Virtualization
>

--js

>

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

Re: Create qemu-project/py-qemu.qmp repo

[John Snow]

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

On Fri, Apr 22, 2022, 10:28 AM John Snow <jsnow@redhat.com> wrote:

>
>
> On Fri, Apr 22, 2022, 4:37 AM Andrea Bolognani <abologna@redhat.com>
> wrote:
>
>> On Thu, Apr 21, 2022 at 05:00:16PM -0400, John Snow wrote:
>> > On Thu, Apr 21, 2022, 2:00 PM Andrea Bolognani <abologna@redhat.com>
>> wrote:
>> > > I think I would go with "python-qemu-qmp". Having a dot in the name
>> > > of a git repo is not very common AFAICT, and I wouldn't rule out the
>> > > possibility of some GitLab feature or other tooling breaking or
>> > > misbehaving because of it.
>> >
>> > The idea is to have the repo name resemble the Python package name,
>> which
>> > is "qemu.qmp". For Python, it's customary to have the package name match
>> > the import name. The import name is "qemu.qmp".
>> >
>> > I tested this name on GitLab and it appears to work just fine.
>>
>> I'm concerned about issues that you'd only trigger when using
>> certain, perhaps less common, features.
>>
>> Here's an example of such an issue from just a year ago:
>>
>>   https://gitlab.com/gitlab-org/gitlab/-/issues/224669
>
>
> For mailing list context, this bug appears to concern label names with a
> dot; due to bad URL generation that can be fixed manually using %2e.
>
>
>> There's an epic tracking more issues of the same kind, though
>> admittedly most were addressed four years ago:
>>
>>   https://gitlab.com/groups/gitlab-org/-/epics/3740
>>
>> Up to you whether you feel confident enough that you're not going to
>> run into issues later.
>>
>
> There's always the chance for bugs, right? I'm not too concerned - I
> didn't run into anything by now, and I've been working on this stuff for a
> while.
>
> Can't promise it won't ever happen, but I value consistency with the
> package name more than I value avoiding possible bugs.
>
> Valid to wonder, but I think the tradeoff is appropriate here.
>
>
>> > > If you're really keen on saving those few extra keystrokes, maybe
>> > > "pyqemu" is a better prefix than "py-qemu"? I don't know, it just
>> > > looks more natural to me.
>> >
>> > I'd add "py:" as a prefix, but the colon doesn't work as a filename in
>> many
>> > places, so I suggested "py-".
>> >
>> > Thus, all together, "py-qemu.qmp".
>> >
>> > (I could spell out "python", I just prefer the shorter prefix because
>> it's
>> > explanatory enough as-is and I like keeping git checkout names short. My
>> > favorite color of bike shed is blue.)
>>
>> You can absolutely have short names locally even when things are
>> spelled out in GitLab.
>>
>
> Sure, but it's more steps and I personally never change the name when
> copy-pasting the "git clone" snippet. I assume most don't either.
>
>
>> Anyway, in this case my taste in names is clearly simply different
>> from yours and you should absolutely feel free to ignore my opinion
>> on the matter :)
>>
>
> Thanks for weighing in. I'm not ignoring your feedback, but I think I'm
> still happiest with "py-qemu.qmp" for now.
>

Hah. Except Paolo decided on "python-qemu-qmp" and he has the keys and I
don't, so I guess that settles that :p

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