Bug#864622: RFS: rich-minority/1.0.1-1 [ITP]

[Sean Whitton]

Dear Nicholas,

On Mon, Aug 21 2017, Nicholas D Steeves wrote:

> Would you like me to add this to the documentation?  Of course I'll
> also submit a patch upstream.

Would be nice.

> Also, please let me know if you're currently too busy to sponsor this
> one.  I can find an off-team sponsor if necessary.

I won't be sponsoring this, I'm afaid.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#864622: RFS: rich-minority/1.0.1-1 [ITP]

[Nicholas D Steeves]

Hi,

On Fri, Jul 07, 2017 at 09:20:03PM -0400, Nicholas D Steeves wrote:
> On Tue, Jun 13, 2017 at 06:42:28PM +0100, Sean Whitton wrote:
> > Hello Nicholas,
> > 
> > On Mon, Jun 12, 2017 at 07:33:12PM -0400, Nicholas D Steeves wrote:
> > > Would it be better to ship README.org and file a bug against the
> > > package myself?
> > 
> > Yes.  Why not ship README.org in the interim?
> 
> Let's discuss .org documentation at DebConf.  I've converted the
> README to plaintext for now.

At DebConf consensus was reached that emacs users prefer READMEs as
org files ;-) Commit 393e81b and the package on mentors now reflects
this.

> > > 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.
> > 
> > diminish.el works like this:
> > 
> > (diminish 'auto-fill-function)
> > 
> > That's it.  Clearly simpler.
> 
> I think this is probably the simplest rich-minority-mode equivalent,
> assuming that subsequent (diminish 'minor-mode-function) adds items
> to-be-hidden:
> 
> (push " Fill" rm-blacklist)
> 
> I haven't investigated corner cases, but it would seem that
> rich-minority-mode might also be simple :-)

Would you like me to add this to the documentation?  Of course I'll
also submit a patch upstream.

Also, please let me know if you're currently too busy to sponsor this
one.  I can find an off-team sponsor if necessary.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#864622: RFS: rich-minority/1.0.1-1 [ITP]

[Nicholas D Steeves]

Hi Sean,

On Tue, Jun 13, 2017 at 06:42:28PM +0100, Sean Whitton wrote:
> Hello Nicholas,
> 
> On Mon, Jun 12, 2017 at 07:33:12PM -0400, Nicholas D Steeves wrote:
> > Would it be better to ship README.org and file a bug against the
> > package myself?
> 
> Yes.  Why not ship README.org in the interim?

Let's discuss .org documentation at DebConf.  I've converted the
README to plaintext for now.

> > 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]".
> 
> Where are you getting this line limit from?

In the same way that lines must be hard-wrapped to fit a 80 column
terminal I inferred that long description should also fit in a 24 line
terminal, and that README should used for anything longer.  Maybe it's
not a hard rule, but this has always struck me as a sort of standard.
At any rate, I've updated the description.

> > 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.
> 
> diminish.el works like this:
> 
> (diminish 'auto-fill-function)
> 
> That's it.  Clearly simpler.

I think this is probably the simplest rich-minority-mode equivalent,
assuming that subsequent (diminish 'minor-mode-function) adds items
to-be-hidden:

(push " Fill" rm-blacklist)

I haven't investigated corner cases, but it would seem that
rich-minority-mode might also be simple :-)

All of your comments should be addressed by 419b8ca which I believe is
ready to upload.  I would be very appreciative if you would also grand
DM permissions for it :-)

Thank you,
Nicholas


signature.asc
Description: Digital signature

Bug#864622: RFS: rich-minority/1.0.1-1 [ITP]

[Sean Whitton]

Hello Nicholas,

On Tue, Jun 13, 2017 at 09:39:43PM -0400, Nicholas D Steeves wrote:
> Phase four: Do you think that it would be useful to have
> d/package.convert-to-info, d/package.convert-to-text, etc?  This would
> allow a plain d/rules.

This probably wouldn't work because each conversion will probably need
particular options and fixups.  I also doubt the debhelper maintainers
would want to add those files.

> Alternatively, it might be a better use of time to just write a
> Makefile to generate the docs for each package, and then submit those
> to upstreams.  What do you think?
> [...]
> What do you think?  Does this sound like a good proposal?  When should
> I email pkg-emacsen?  After Stretch is released?

As a rule of thumb it's better to have things merged upstream.

I don't think we need any kind of team policy on this.  It's not an
Emacs-specific issue.  Packagers can handle the documentation as they
would for any other package.  And for elpa-* packages, it's almost
always just a README, which can remain in Org/Markdown/plain text.

> Hmm, so the question comes down to how committed and able I am to get
> rich-minority (and smart-mode-line for that matter) to work with a
> potential default of emacs26 for Buster?

Chances are it will Just Work.  New releases of Emacs do not break very
many things.  So I would upload it to unstable once you've run it
locally for a week or so.

> Most packages have a fairly short "long description" so I've been
> operating under the assumption that it is supposed to be less than 25
> lines long, with 24 lines preferred.

You wouldn't want it to be pages and pages.  But feel free to go over 25
lines.

> > diminish.el works like this:
> > 
> > (diminish 'auto-fill-function)
> > 
> > That's it.  Clearly simpler.
> 
> Does this hide "Fill" from the modeline?  Does a subsequent
> 
> (diminish 'flyspell-mode)
> 
> concatenate Fly|Flyspell to the list of minor modes that will be
> hidden?

Yes.

> For now, do you think I should create a README.Debian with these
> examples or wait for upstream to merge them?

I don't think you need to do either.  Just mention that it's meant to be
a more flexible/improved version of diminish.el.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#864622: RFS: rich-minority/1.0.1-1 [ITP]

[Nicholas D Steeves]

Hi Sean,

On Tue, Jun 13, 2017 at 06:42:28PM +0100, Sean Whitton wrote:
> Hello Nicholas,
> 
> On Mon, Jun 12, 2017 at 07:33:12PM -0400, Nicholas D Steeves wrote:
> > Would it be better to ship README.org and file a bug against the
> > package myself?
> 
> Yes.  Why not ship README.org in the interim?
> 
> > 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.
> 
> I don't think Policy 12.4 really applies to READMEs.  It says "extensive
> documentation", and a README is not extensive documentation.
> 
> Policy 12.4 is basically saying "ship HTML instead of PDF".

Ok, I'll default to shipping *.orgs for now as I learn more about
pandoc and how it should be used.  This won't be necessary for
rich-minority, because I discovered pandoc supports plaintext output
(see commit f0e90360 of rich-minority).

I think for phase two I should probably add pandoc to overrides in
d/rules for my other packages, paying attention to where fixups are
required (eg: those sed rules in rich-minority, which are needed for
pandoc-1.12.4.2~dfsg-1+b14).  Before doing this I ought to upgrade to
Stretch, because otherwise all this might be "make-work-project" that
potentially only reveals the shortcomings of
pandoc-1.12.4.2~dfsg-1+b14.

Phase three seems like it should be contacting the Debian pandoc
maintainers with an inquiry to whether pandoc could detect and
work-around these issues on its own.  This will eliminate the sed
fixups.

Phase four: Do you think that it would be useful to have
d/package.convert-to-info, d/package.convert-to-text, etc?  This would
allow a plain d/rules.

Alternatively, it might be a better use of time to just write a
Makefile to generate the docs for each package, and then submit those
to upstreams.  What do you think?  If ELPA/MELPA are already taking
care of this without Makefiles I'm not sure how useful this would be
for the overall emacs-elpa ecosystem...  If we go the Makefile route
then we should put the Makefile example/template somewhere that is
accessible the the pkg-emacsen team.

What do you think?  Does this sound like a good proposal?  When should
I email pkg-emacsen?  After Stretch is released?

> > > - 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 would depend on whether a user of buster gets emacs25 or emacs26 if
> they type "apt-get install emacs".

Hmm, so the question comes down to how committed and able I am to get
rich-minority (and smart-mode-line for that matter) to work with a
potential default of emacs26 for Buster?  Worst case scenario, if I'm
not able to get it to work, would probably be that the package gets
dropped during the freeze, and then having to use buster-backports
with a new upstream release.  Is this worst-case scenario preferable
to keeping a package in experimental where users have to explicitly
opt-in?  Of course, I'm going to do whatever I can to make it work,
despite my limited abilities...

> > 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]".
> 
> Where are you getting this line limit from?

Most packages have a fairly short "long description" so I've been
operating under the assumption that it is supposed to be less than 25
lines long, with 24 lines preferred.  I've also assumed that if the
description grows longer than this then it needs to be more
aggressively ellipsed and summarised--possibly with references to
other documentation such as the README, man, and info pages. 

> > 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.
> 
> diminish.el works like this:
> 
> (diminish 'auto-fill-function)
> 
> That's it.  Clearly simpler.

Does this hide "Fill" from the modeline?  Does a subsequent

Bug#864622: RFS: rich-minority/1.0.1-1 [ITP]

[Sean Whitton]

Hello Nicholas,

On Mon, Jun 12, 2017 at 07:33:12PM -0400, Nicholas D Steeves wrote:
> Would it be better to ship README.org and file a bug against the
> package myself?

Yes.  Why not ship README.org in the interim?

> 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.

I don't think Policy 12.4 really applies to READMEs.  It says "extensive
documentation", and a README is not extensive documentation.

Policy 12.4 is basically saying "ship HTML instead of PDF".

> So this?:
> 
> - Copyright: 2014, 2015 Free Software Foundation, Inc.
> -2014-2016 Artur Malabarba 
> 
> +Copyright: 2014-2016 Free Software Foundation, Inc.
> + 

Yes.

> > - 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 would depend on whether a user of buster gets emacs25 or emacs26 if
they type "apt-get install emacs".

> 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]".

Where are you getting this line limit from?

> 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.

diminish.el works like this:

(diminish 'auto-fill-function)

That's it.  Clearly simpler.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#864622: RFS: rich-minority/1.0.1-1 [ITP]

[Nicholas D Steeves]

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 

+Copyright: 2014-2016 Free Software Foundation, Inc.
+ 

> - 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


signature.asc
Description: Digital signature

Bug#864622: RFS: rich-minority/1.0.1-1 [ITP]

[Sean Whitton]

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?

- the file is not copyright Artur Malabarba.  It looks like he assigned
  copyright to the FSF

- 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.

- it might be a good idea to mention diminish.el in the description

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#864622: RFS: rich-minority/1.0.1-1 [ITP]

[Nicholas D Steeves]

I decided to change this one to experimental rather than unstable and
have pushed the changes and reuploaded to mentors.  Rationale: I
haven't tested smart-mode-line extensively enough with emacs25.


signature.asc
Description: Digital signature

Bug#864622: RFS: rich-minority/1.0.1-1 [ITP]

[Nicholas D Steeves]

Package: sponsorship-requests
Severity: wishlist
Control: block 864393 by -1

Dear mentors,

I am looking for a sponsor for my package "rich-minority"

Package name: rich-minority
Version : 1.0.1-1
Upstream Author : Artur Malabarba 
URL : https://github.com/Malabarba/rich-minority
License : GPL-2+

"rich-minority" is a dependency of "smart-mode-line" (see chain of blocks).

It builds these binary packages:

elpa-rich-minority - Clean-up and beautify the list of minor-modes in 
Emacs' mode-line

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/rich-minority

Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/r/rich-minority/rich-minority_1.0.1-1.dsc

The project git remote is here:

  git+ssh://git.debian.org/git/pkg-emacsen/pkg/rich-minority.git

Changes since the last upload:

rich-minority (1.0.1-1) unstable; urgency=medium

  * Initial release. (Closes: #864393)

 -- Nicholas D Steeves   Sun, 11 Jun 2017 15:18:12 -0400

Regards,
Nicholas D Steeves


signature.asc
Description: Digital signature