[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Review request for apt-listbugs template po file



Francesco Poli wrote:
>> Then the next problem is that the user isn't asking to see statuses;
>> the user wants to see bugs filtered by status.  Things would be
>> simpler if it was -F for filters... maybe you could say:
>> 
>>  Bug-status filters you want to see matches for, separated by commas. [...]
>>
> 
> Let's try and find a solution that does not break back-compatibility,
> unless it's absolutely necessary to do so.
> 
> I think it would be better if the option short and long names were not
> changed, so I would like to keep them as they are now (-S and --stats).
> I acknowledge that --stats is the wrong abbreviation, but I would
> rather avoid gratuitously breaking scripts that the users may have
> written to invoke apt-listbugs. Especially during a freeze.

The trouble is, it's not just that --stats is the wrong abbreviation
for "statuses"; "statuses" also makes me slightly uncomfortable for
reasons I'm having trouble putting my finger on.  Would I be happier
with the word if I spent my time worrying about Facebook statuses?

> We can hopefully compensate the unfortunate misleading nature of the
> --stats long option name with better documentation.
> 
> The man page could say something like:
> 
> * -S <statuses> | --stats <statuses>
> 
>   Statuses of the bugs you want to see, separated by commas. Default: [forwarded,done,pending,pending-fixed]
> 
> The output of "apt-listbugs -h" could say something like:
> 
>  -S <statuses>    : Statuses of the bugs you want to see
>                     [forwarded,done,pending,pending-fixed,].
> 
> 
> Would this be more understandable?

It has taken me a long, long time to work out what it meant, so on the
whole I'd have to say no.  I was assuming apt-listbugs was offering to
filter "the bugs you want to see" by status; but that would make the
default a very strange filter!  No, it's offering to include these
status-flags in the output; in other words, they're the "Statuses (of
the bugs) that you want to see".  Is that right?

If so, that would be something along the general lines of:

  * -S <statuses> | --stats <statuses>
  
    Bug-status categories that should be marked, separated by commas. [...]


> However, it seems to me that the same "problem" is present in the -T
> and -s options... The man page currently says:
> 
> * -s <severities> | --severity <severities>
> 
>   Severities you want to see, separated by commas; possible values are critical, grave, serious, important, normal, minor and wishlist. Default: [critical,grave,serious]
>   You can specify '--severity all' to specify all severities.

Er, this one *is* a filter, isn't it?  If I say "-s critical" it'll
leave out the lesser ones (not just show all of them and explicitly
flag which ones are critical).  So maybe I don't understand any of
this at all yet.
 
> * -T <tags> | --tag <tags>
> 
>   Tags you want to see, separated by commas. 

Does it show the tags, or show the bugs with these tags?
 
> and the output of "apt-listbugs -h" currently prints:
> 
>  -s <severities>  : Severities you want to see [critical,grave,serious], or [all].
>  -T <tags>        : Tags you want to see.

(Floaty colons strike again.)
 
> Should these be changed as well (as in, e.g., "Tags of the bugs you
> want to see")?

Can I sleep on it?  Or maybe hibernate?
-- 
JBR	with qualifications in linguistics, experience as a Debian
	sysadmin, and probably no clue about this particular package


Reply to: