On Mon, Jun 12, 2017 at 02:13:02PM +0100, Sean Whitton wrote: > Hello, > > On Sun, Jun 11 2017, Nicholas D Steeves wrote: > > > I am looking for a sponsor for my package "rich-minority" > > > > Package name : rich-minority Version : 1.0.1-1 > > Here's a review of bc58ab0a49df6002e4e034cea8c1398fd7407322: > > - why not just install README.org as it is? My rationale is that in a worst-case scenario where I forget to implement Policy 12.4 someone will file a bug like "Where is the upstream README?" Would it be better to ship README.org and file a bug against the package myself? I still don't have a plan for Policy 12.4, and am currently wondering if further conversion of README.html to README using html2txt (if pandoc cannot do this) would be best, because the expectation is that the upstream README found in /usr/share/doc is a plain text file. > - the file is not copyright Artur Malabarba. It looks like he assigned > copyright to the FSF So this?: - Copyright: 2014, 2015 Free Software Foundation, Inc. - 2014-2016 Artur Malabarba <emacs@endlessparentheses.com> +Copyright: 2014-2016 Free Software Foundation, Inc. + <this line actually gets deleted> > - your rationale for uploading to experimental applies to > smart-mode-line, but why not upload rich-minority to unstable? Is it > similarly untested? Maybe we should just wait a few weeks. If you'd prefer I'd be happy to wait a few weeks. In terms of worst-case scenario planning: If for some reason smart-mode-line upstream didn't add emacs26 compatibility in time for Buster's freeze, and I (or someone from pkg-emacsen) didn't have time to add it, then should rich-minority still be part of Buster? > - it might be a good idea to mention diminish.el in the description How many lines can I dedicate to this? By my count I need to summarise the following in five lines, and the most salient additions are the mention of diminish.el, plus compare/contrast by adding what I suspect are the two most salient points. * "/missing/...quick and simple replacement functionality" * the addition of "It accepts *regexps* instead of [individual specifications]". These two points seem contradictory to me. Do you know how diminish.el is more quick and simple? Also, can I use your answer for a patch against the upstream description, because I might not be the only one who's not confused about this. Failing that, I can open an upstream issue/request for clarified description. ;; Comparison to Diminish ;; ────────────────────── ;; ;; Diminish is an established player in the mode-line world, who also ;; handles the minor-modes list. What can rich-minority /offer in ;; contrast/? ;; ;; • rich-minority is more versatile: ;; 1. It accepts *regexps*, instead of having to specify each ;; minor-mode individually; ;; 2. It also offers a *whitelist* behaviour, in addition to the ;; blacklist; ;; 3. It supports *highlighting* specific minor-modes with completely ;; arbitrary text properties. ;; • rich-minority takes a cleaner, functional approach. It doesn’t hack ;; into the `minor-mode-alist' variable. ;; ;; What is rich-minority /missing/? ;; ;; 1. It doesn’t have a quick and simple replacement functionality yet. ;; Although you can set the `display' property of a minor-mode to ;; whatever string you want and that will function as a replacement. ;; 2. Its source comments lack [Will Mengarini’s poetry]. :-) Thank you for the critique and pointers! Cheers, Nicholas
Attachment:
signature.asc
Description: Digital signature