Bug 6569 - [PATCH r1088422 2011-04-03] spamd.1 -- Order items alphabetically
Summary: [PATCH r1088422 2011-04-03] spamd.1 -- Order items alphabetically
Status: RESOLVED WONTFIX
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: spamc/spamd (show other bugs)
Version: SVN Trunk (Latest Devel Version)
Hardware: PC Linux
: P2 enhancement
Target Milestone: Undefined
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-04-03 19:07 UTC by jari.aalto
Modified: 2011-11-05 22:41 UTC (History)
2 users (show)


Attachment Type Modified Status Actions Submitter/CLA Status
Oder alphabetically patch None jari.aalto@cante.net [NoCLA]
Order alphabetically (POD::OPTIONS) patch None jari.aalto@cante.net [NoCLA]
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description jari.aalto 2011-04-03 19:07:52 UTC 
Created attachment 4862 [details]
Oder alphabetically

Cf. http://bugs.debian.org/620762

The following patch:

    - Orders items alphabetically
    - Removes extra EOL whitespaces from the moved items.

This helps searching in natural A-Z order. Compare to book indexes
where one reads from top to bottom; and programs like cp(1), mv(1),
ssh(1) etc.
Comment 1 jari.aalto 2011-04-03 19:08:44 UTC 
Created attachment 4863 [details]
Order alphabetically (POD::OPTIONS)

2nd part
Comment 2 Kevin A. McGrail 2011-11-03 20:34:42 UTC 
Jari,

I appreciate the idea and the effort you put into this but the risk to reward is so low for a documentation change.  Double-checking that this patch isn't losing data seems really hard.

Additionally, most, if not all programs I'm familiar with try and group options more so than go for alphabetical ordering.

In the end, especially for an administrator level tool such as spamd, this seems unnecessary.

But don't let me discourage you.  Would love to have you work on other items with more of an impact.  I would very much like to commit this.  I just can't justify the hour+ of work to verify it.

Regards,
KAM
Comment 3 jari.aalto 2011-11-05 08:01:05 UTC 
If you could reconsider it a little. I'm 100% sure that everything has been preserved and no information has been lost. Many times when reading commands in the Internet:

  command -a -x -u -z -y ....

It appears that the easiest way to find the information from manpage is the alphabetical listing where options appear in predictable manner, like a book index. Manpages are most of the time used for a reference material.

Jari
Comment 4 Karsten Bräckelmann 2011-11-05 22:19:52 UTC 
In line with comment 2, I am also strongly in favor of (logically) grouping the options available.

In cases like mentioned in comment 3, what I find much more helpful than alphabetical order is to search the man page. This depends on your 'man' command's pager setting, but usually should be 'less'. Searching for a word or option also will quickly show related options referring to the switch in question.
Comment 5 Karsten Bräckelmann 2011-11-05 22:41:16 UTC 
FWIW, some CLI magic reveals at least one documentation issue fixed in patch attachment 4862 [details].

- -r pidfile, --pidfile             Write the process id to pidfile
+ -r file, --pidfile=file           Write the process id to pidfile

The long option is missing the argument. Though the patch also missed to adjust the description and use 'file' instead of 'pidfile'.

The second patch is just too scary to review without spending quite some time manually verifying. And it borks the shebang in line 1.