Bug#966504: emacs-ivy: should suggest not recommend elpa-smex
Hello, On Tue 04 Aug 2020 at 08:04AM -04, Nicholas D Steeves wrote: > By the way, I concede that choosing not to censure the > human element of my changelog entry makes it appear that the decision > was possibly an "emotional" rather than "rational" one. Given the > prevalence of negative and degrading changelog entries (eg: "useless", > "good for nothing", "garbage", etc) there is precedent for > rational+emotional in Debian culture, and I think we can agree that > rational+positive_emotion entries are more congruent with the project's > ideals. I don't think this was what happened. It was simply that you did not make reference to our shared definition of the fields you were modifying. > I understand this is a qualitative and philosophical thing, and probably > outside the scope of Policy, but if I interpret what you've written > correctly, would it be this: Perfect documentation would be 100% > comprehensive, but most users won't read it, and were they to spend the > time reading it this would count as discovery? ...albeit probably not > joyful, because I've never heard anyone describe the process of reading > docs as such (except An Introduction to Programming in Emacs LISP. That > one is a joy!) Otherwise, the quick-start guide might ideally omit > certain details not only in the interests of brevity, but also to allow > for the joy of discovery? I've had plenty of enjoyable experiences with the Emacs manuals :) A quick start guide is not a manual however. So it could omit stuff in the way that you describe. >> Hard for me to say, to be honest, as I don't use smex or ivy or >> counsel. >> > > On this topic, would you like me to adopt smex? I've noticed that it's > your package and is in need of some work. If so, please grant me DM for > it. That would be great, thank you. Please remove me from Uploaders:. -- Sean Whitton signature.asc Description: PGP signature
Bug#966504: emacs-ivy: should suggest not recommend elpa-smex
Hi Sean! Sean Whitton writes: > On Sat 01 Aug 2020 at 01:58PM -04, Nicholas D Steeves wrote: > [snip my rationale] > > Okay, looks like I misunderstood. Specifically: almost no-one would > want to bother with elpa-counsel unless they were going to use its > features which enhance M-x, but without elpa-smex elpa-counsel barely > enhances M-x, and thus almost no-one would want to bother with > elpa-counsel without elpa-smex, so Recommends is correct. > > Closing the bug. > Thank you :-) >> 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. > > I'm sorry that my opening this bug inadvertedly suggested to you that I > don't trust your decision-making as a package maintainer. I do trust > your decision-making as a package maintainer. Thank you, I'm relieved to hear that that all the work since you initially mentored me for muse-el was not in vain :-) > I was just responding to what you wrote in the changelog, which does > not mention how enhanced M-x is a fundamental feature of elpa-counsel. > > Perhaps I could have predicted this and written my bug report in a way > less likely to suggest anything about your abilities, so please accept > my apologies for that. > Fair point. By the way, I concede that choosing not to censure the human element of my changelog entry makes it appear that the decision was possibly an "emotional" rather than "rational" one. Given the prevalence of negative and degrading changelog entries (eg: "useless", "good for nothing", "garbage", etc) there is precedent for rational+emotional in Debian culture, and I think we can agree that rational+positive_emotion entries are more congruent with the project's ideals. > By the way, I'm not really motivated here by concerns about installation > size, but just by a general desire for the metadata published in our > archive to be correct. > Thank you for this, always appreciated! :-) P.S. a number of our team packages are not yet Policy ≥ 4.1.3 compliant (§7.8 "Built-Using"). >> 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? > > An interesting question.Probably best served by some sort of quick > start guide in upstream docs? Confirmed; Some info is already there "Ivy re-uses [automatically] the following packages if they are installed: avy, amx or smex, flx, and wgrep", plus documentation on how to activate counsel-M-x but it doesn't detail what is activated where. >> eg: Is perfect documentation 100% comprehensive, or should it leave >> room for the joy of discovery? I understand this is a qualitative and philosophical thing, and probably outside the scope of Policy, but if I interpret what you've written correctly, would it be this: Perfect documentation would be 100% comprehensive, but most users won't read it, and were they to spend the time reading it this would count as discovery? ...albeit probably not joyful, because I've never heard anyone describe the process of reading docs as such (except An Introduction to Programming in Emacs LISP. That one is a joy!) Otherwise, the quick-start guide might ideally omit certain details not only in the interests of brevity, but also to allow for the joy of discovery? > Hard for me to say, to be honest, as I don't use smex or ivy or > counsel. > On this topic, would you like me to adopt smex? I've noticed that it's your package and is in need of some work. If so, please grant me DM for it. Regards, Nicholas signature.asc Description: PGP signature
Bug#966504: emacs-ivy: should suggest not recommend elpa-smex
Control: severity -1 minor Hi Sean! Sean Whitton 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! ". 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 signature.asc Description: PGP signature
Bug#966504: emacs-ivy: should suggest not recommend elpa-smex
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. -- Sean Whitton signature.asc Description: PGP signature
