All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Thomas Huth <thuth@redhat.com>
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
	"Daniel P . Berrangé" <berrange@redhat.com>,
	qemu-devel@nongnu.org,
	"Samuel Thibault" <samuel.thibault@ens-lyon.org>,
	"Gerd Hoffmann" <kraxel@redhat.com>
Subject: Re: [PATCH 3/4] usb: Un-deprecate -usbdevice (except for -usbdevice audio which gets removed)
Date: Thu, 11 Mar 2021 09:38:20 +0100	[thread overview]
Message-ID: <87y2euqe4j.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <20210310173323.1422754-4-thuth@redhat.com> (Thomas Huth's message of "Wed, 10 Mar 2021 18:33:22 +0100")

Thomas Huth <thuth@redhat.com> writes:

> When trying to remove the -usbdevice option, there were complaints that
> "-usbdevice braille" is still a very useful shortcut for some people.
> Thus we never remove this option. Since it's not such a big burden to
> keep it around, and it's also convenient in the sense that you don't
> have to worry to enable a host controller explicitly with this option,
> we should remove it from he deprecation list again.
>
> However, there is one exception: "-usbdevice audio" should go away, since
> audio devices without "audiodev=..." parameter are also on the deprecation
> list and you cannot use "-usbdevice audio" with "audiodev".
>
> Signed-off-by: Thomas Huth <thuth@redhat.com>

I accept the complaint that the replacement of "-usbdevice braille" is
less convenient.  This is not the case for the -usbdevice tablet, mouse,
keyboard, ccid, and wacom-tablet.  It is arguably the case for disk,
serial, net, and host, yet we removed those anyway, to make the regular
and more expressive interface the only one.

Perhaps braille is special enough to justify sugar.  Paolo wrote:

    Braille is worth a special case because a subset of our user base
    (blind people) will use it 100% of the time, plus it is not
    supported by libvirt and hence virt-manager

I'm not against extending the grace period to give libvirt (and hence
virt-manager) more time to transition to the regular interface.  For
libvirt, the regular (and often more expressive) interface is almost
always preferable to sugared interfaces.

I'm not even against braille sugar if our human users of braille truly
need it, as long as it's reasonably unobtrusive.  Straightforward macro
expansion is.

However, "braille is special" is only an argument for *braille* sugar.
It doesn't extend to -usbdevice tablet, mouse etc.  I am against
undeprecating these.

If we decide we want braille sugar, we then need to decide whether it
should be -usbdevice braille or something else, like -braille.

If we decide we want something else, keep -usbdevice braille deprecated
until something else is ready, then keep it deprecated for a sensible
grace period, then remove it.  Flip-flopping deprecation in between is
not helpful.

If we can't make up our minds, keep it deprecated until we do.

Only if we decide the sugar should remain -usbdevice braille, we should
undeprecate it now.

The road to the CLI hell we're in is paved with "convenience".



  reply	other threads:[~2021-03-11  8:40 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-10 17:33 [PATCH 0/4] Clean up the -usbdevice mess Thomas Huth
2021-03-10 17:33 ` [PATCH 1/4] usb: remove support for -usbdevice parameters Thomas Huth
2021-03-10 18:19   ` Eric Blake
2021-03-10 17:33 ` [PATCH 2/4] usb: remove '-usbdevice u2f-key' Thomas Huth
2021-03-10 17:33 ` [PATCH 3/4] usb: Un-deprecate -usbdevice (except for -usbdevice audio which gets removed) Thomas Huth
2021-03-11  8:38   ` Markus Armbruster [this message]
2021-03-11  9:14     ` Thomas Huth
2021-03-11 11:37       ` Gerd Hoffmann
2021-03-11 11:45         ` Samuel Thibault
2021-03-11 10:29     ` Paolo Bonzini
2021-03-10 17:33 ` [PATCH 4/4] usb: Document the missing -usbdevice options Thomas Huth
2021-03-11  8:41 ` [PATCH 0/4] Clean up the -usbdevice mess Gerd Hoffmann
2021-03-11  9:28 ` [PATCH 5/4] usb: Remove "-usbdevice ccid" Thomas Huth
2021-03-17  6:04   ` Thomas Huth
2021-03-17  6:40     ` Gerd Hoffmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y2euqe4j.fsf@dusky.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=samuel.thibault@ens-lyon.org \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.