Control: severity -1 minor Hi Sean! Sean Whitton <spwhitton@spwhitton.name> writes: > Package: emacs-ivy > Version: 0.13.0-1 > > Hello, > > On Fri 24 Jul 2020 at 11:49PM GMT, Debian FTP Masters wrote: > >> Changes: >> emacs-ivy (0.13.0-1) unstable; urgency=medium >> . >> [...] >> * Add elpa-smex to elpa-counsel's Recommends. The way it presents one's >> recently and most frequently used commands at the top of the >> candidates list is a wonderful productivity-enhancing feature. See >> the docs to learn how to use Counsel to enable this for the M-x >> interface. > > Based on your description here, should probably be Suggests: not > Recommends:, given that Recommends: is for packages where it would be > highly unusual not to use ivy with them. Please note that changelog entry says "Add…to elpa-counsel's Recommends". Strictly speaking I upgraded it from an Enhances to a Recommends. I agree that it would be an incorrect interpretation of Policy to add it to elpa-ivy's Recommends. Elpa-counsel is an "everything and the kitchen sink" type package; it exists specifically to add a bundle of productivity-enhancing functionality to Ivy, and it's unlikely that any one user would use more than ~30% of it. By far, Counsel's most useful feature is its Smex-to-Ivy integration via counsel-M-x, and Smex is automatically enabled for counsel-M-x when it is found. Without it, counsel-M-x offers negligible advantages to the built-in `execute-extended-command`. Counsel-M-x is also the only function that is useful to the majority of Counsel users; however, the user must opt-in by rebinding "M-x" to `counsel-M-x`. This fact is documented upstream and in Debian-provided docs. See also how few users install Counsel vs Ivy: https://qa.debian.org/popcon.php?package=emacs-ivy While I agree that dependency bloat should be avoided, I do not believe that this is an example of such bloat, and I'm sad that by now you don't trust me to make carefully reasoned decisions. Given that Policy states "should" and not "must", I am asserting my prerogative as maintainer of the package: that this Recommends is justified and Policy-compliant, and that this action benefits the majority of Counsel users. Users who detest Smex can uninstall it and 'apt-mark hold smex'; meanwhile, the vast majority of Ivy users do not install Counsel. My deduction, hope, and belief is that users who rebind "M-x" will be pleasantly surprised, will tell their friends/colleagues about it, and that this will manifest in the popcon stats in the same way that that most of my user-friendliness, discoverability, and documentation enhancements seem to have correlated to an increased rate of growth in other packages. On a related topic, do you think that users would be better served by documenting this feature in elpa-counsel's long description, or by leaving it as something to be discovered in /usr/share/docs? I confess that I'm biased towards the latter, because my experience was "wow, it's like it read my mind! <huge smile>". It's an interesting question, you know? eg: Is perfect documentation 100% comprehensive, or should it leave room for the joy of discovery? P.S. Thank you for maintaining Smex; it has become one of my favourite elpa-packages. That said, the only reason I learned of it was because I read an Ivy-related thread somewhere (along the lines of "getting the full abo-abo experience"). Frankly, I'm shocked that it's not more well known, and believe that part of the value that Debian provides (vs MELPA) is the following function: we can boost the visibility of genuinely novel and useful packages that have not yet gained a foothold in the general consciousness, thus encouraging upstream development and fostering motivation in the more general FLOSS community. Cheers, Nicholas
Attachment:
signature.asc
Description: PGP signature