trash-cli : Looking for a reviewer

[Ralf Corsepius]

On Mon, 2008-10-06 at 12:48 +0200, Patrice Dumas wrote:
> On Mon, Oct 06, 2008 at 11:39:52AM +0200, Tim Niemueller wrote:
> > 
> > That has been discussed during the review and the reasoning was that the
> > project chose that name and renaming it would only cause unexpected
> > hassles for people who install this software. Upstream chose that name,
> > so if we want that package we should stick to it, if only to allow users
> > to reproduce commands given in documentation, wikis, blogs etc.
> > Additionally your very repoquery shows that there are in fact no
> > conflicts, so why bother?
> > 
> > I also don't see a problem why binary in the package for which this
> > thread was initiated should be renamed. There is no trash command, it
> > provides functionality which clearly fits the name, so why the heck
> > should it be renamed? Just because someone might as well add such a
> > command later? It's like not using your roller skates to keep them in a
> > nice new condition, until you have grown out of them...
> 
> The issue is that many upstream don't care about using names that are
> not prone to future conflicts, and use generic names. In my opinion,
> generic names should be reserved to standardized programs (like
> sendmail, ls, ...). 

ACK.

> Upstream don't care and selfishly choose the name
> that suits them most, but at the distro level, and for the long-term, 
> I think that we should try to regulate a bit those namings such
> that projects don't take these precious names carelessly.
Right. In particular in cases where packages can easily be modified to
better suite into distribution (Think --program-prefix).

>  To put it otherwise, the generic names (like trash, player, record,
> convert, ...) and the short names (like ls, qpd, fjk, tgn...) are
> scarce and a first come first serve is certainly a bad way of choosing
> them.

ACK. Also consider there may exist applicable standards, which may
interfere on such common names and may force/overrule such upstream
choices.

>  In theory, upstream should think about those issues when choosing a
> name and avoid misusing these scarce words, but this is not what
> happens.
Well, we are having a review quality problem.

Ralf