LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender: Mailing list for the LaTeX3 project <[log in to unmask]>
Date: Fri, 22 Jun 2018 11:29:22 +0200
Reply-To: Mailing list for the LaTeX3 project <[log in to unmask]>
Message-ID: <[log in to unmask]>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
In-Reply-To: <[log in to unmask]>
Content-Type: text/plain; charset=utf-8; format=flowed
From: Frank Mittelbach <[log in to unmask]>
Parts/Attachments: text/plain (36 lines)
Am 22.06.18 um 10:59 schrieb Joseph Wright:
> We discussed this when I first raised the idea of a list. Unlike some 
> other areas (e.g. Python code and CPAN), there are no formal 
> requirements for distributing (La)TeX packages. More importantly, CTAN 
> set their own approach independent of the LaTeX team.
> Thus the aim of a prefix database is necessarily more 'for information' 
> than anything 'stronger'. I think if something was requested which 
> looked extremely problematic, a registration request would be a good 
> opportunity for discussion. Ultimately, however, the prefix is down to 
> the package author: it's no good saying 'no we won't log it', only for 
> the package to go to CTAN anyway but ending up that bit harder for other 
> developers to see.

I haven't said that we should say "we don't log it" not normally anyway, 
though, for something like "stats", I would think we should add that to 
the list of reserved ones.

My point was more that guidance helps, and of course, in case of 
problematical requests (in our opinion) a discussion with the author at 
that point.

At least at the time of initial development it is fairly easy to change 
a prefix (if you are lucky than basically by <@@=prefix> + 2-3 interface 

> In the case in hand, whilst 'statistics' is quite general, it's also 
> pretty long and there are a number of alternatives ('stats' or 'stat' 
> the two most obvious).

As I said I would veto something like "stats", as for "statistics" it is 
long and it might be the package name so it is probably ok.