Package naming rant

classic Classic list List threaded Threaded
34 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Package naming rant

Enrico Zini
Hello,

a couple of days ago I wrote some code that, following the established
naming practices of the project I was working on, ended up looking quite
surreal:

   /// Format a db::Format value to a string
   std::string format_format(Format format);
   ...
   fprintf(out, "Format: %s\n", format_format(format()).c_str());

As soon as that was written I contacted some of my coworkers asking for
a review and their opinion, because although it all seemed to make
sense, I could understand those code lines could weird someone out.

I couple of days later (this morning), I looked at the recent packages
that entered testing, and I got weirded out.

Seriously, people?

   Package: substance-flamingo
   Description: Substance Flamingo plugin
    The goal of this project is to provide a consistent apperance for
    Flamingo components (see libflamingo-java) under the substance
    Substance (see substance) look-and-feel. This requires a JDK version
    5.0+.

I heard you like flamingo substance, so I put Flamingo flamingoes in
your substance Substance so you can substance-flamingo while you
flamingo your Substance!

Then, OpenStack packages. Which of these are actual openstack things?

   Oslo, Tataouine, Magnum, Rump, Keystone, Mistral, Glance, Sahara,
   Schinkenzwiebelmettwurst, Ceilometer, Fuel, Shade, Antani, Congress,
   Barbican, Taskflow, Tosca, Shaft, Trove, Brazier, Mellanox, Manila,
   Tripleo, Castellan, Murano, Hoverboard, Ironic, Swift, Tuskar,
   Capacitor, Ember, Perth, Nova, Inculo, Arista, Neutron, Rally,
   Designate, Cinder, Shotgun, Kulfi, Kofte, Senlin, Braciola, Mocha,
   Lido, Horizon, Zaqar, Heat, Calippo.

That wins the second place in my personal "let's spam the package
namespace with meaningless names" rank. The first is the research
community, who at least have the excuse that they can synthetize all
sorts of substances:

   asdftool - Command line tool to manipulate ASDF scientific data files
   circlator - circularize genome assemblies
   seer - genomic sequence element (kmer) enrichment analysis
   dindel - determines indel calls from short-read data
   spaced - alignment-free sequence comparison using spaced words
   stacks - pipeline for building loci from short-read DNA sequences
   surankco - Supervised Ranking of Contigs in de novo Assemblies

These are some new entries. I like the name asdftool, it gives me the
idea of someone going "we have so many nonsense names that we could just
as well name this one by bashing randomly on the keyboard". Circlator
I'm sure means something in Plukanian[1]. "seer" is yet another step on
the slippery slope that will one day give us a package called "doer".
"dindel" sounds like a Bavarian localisation package. "spaced" is how I
feel going through those names. "Stacks" feels like a tease towards the
OpenStack people, like sticking the middle finger and yelling "you are
NEVER going to catch up!". Surankco sounds to me like some character out
of One Punch Man,

Actually, if you are looking for a name for a new videogame or comic
book character, just run:

   grep -E 'field::(biology|chemistry|medicine)' /var/lib/debtags/package-tags|sed -re 's/:.+//'|sort -u|less

   "And in the next match at the Circos Martial Arts Tournament, we have
   Biosquid, who just won the match against Epigrass, facing Muscle, the
   most promising disciple of Abyss and Clustal"

Let's take this package:

   python-shotgun/testing,testing 0.1.0+2016.12.30.git.0682f20c42-1 all
     Create and save Fuel diagnostic snapshots

I thought it was about shooting yourself in the foot, by connecting an
untested tool you just saw on Hacker News to the OBD-II port of your
car.

Nope: it's some openstack thing with a description made of 11 lines of
enterprise nonsense and two lines of "it reads yaml, collects log files
and stuff, and helps diagnose stuff".

Please at least make sure that all the openstack packages have
suite::openstack tags assigned, and then let's figure out how to have
apt run some recipes to make some tags available in the package short
descriptions, so that it can show like this on "apt search":

   python-shotgun/testing,testing 0.1.0+2016.12.30.git.0682f20c42-1 all
     [openstack] Create and save Fuel diagnostic snapshots


Enrico in a "you're all evidently gone mad and probably dangerous"
       sunday morning mood

[1] https://en.wikipedia.org/wiki/Kin-dza-dza!#Plukanian_language
--
GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini <[hidden email]>

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Package naming rant

Thomas Harding-5
The Monthy Pythons could sing that and never be wrong.


Le 17 avril 2016 15:43:07 GMT+02:00, Enrico Zini <[hidden email]> a écrit :
Hello,

a couple of days ago I wrote some code that, following the established
naming practices of the project I was working on, ended up looking quite
surreal:

/// Format a db::Format value to a string
std::string format_format(Format format);
...
fprintf(out, "Format: %s\n", format_format(format()).c_str());

As soon as that was written I contacted some of my coworkers asking for
a review and their opinion, because although it all seemed to make
sense, I could understand those code lines could weird someone out.

I couple of days later (this morning), I looked at the recent packages
that entered testing, and I got weirded out.

Seriously, people?

Package: substance-flamingo
Description: Substance Flamingo plugin
The goal of this project is to provide a consistent apperance for
Flamingo components (see libflamingo-java) under the substance
Substance (see substance) look-and-feel. This requires a JDK version
5.0+.

I heard you like flamingo substance, so I put Flamingo flamingoes in
your substance Substance so you can substance-flamingo while you
flamingo your Substance!

Then, OpenStack packages. Which of these are actual openstack things?

Oslo, Tataouine, Magnum, Rump, Keystone, Mistral, Glance, Sahara,
Schinkenzwiebelmettwurst, Ceilometer, Fuel, Shade, Antani, Congress,
Barbican, Taskflow, Tosca, Shaft, Trove, Brazier, Mellanox, Manila,
Tripleo, Castellan, Murano, Hoverboard, Ironic, Swift, Tuskar,
Capacitor, Ember, Perth, Nova, Inculo, Arista, Neutron, Rally,
Designate, Cinder, Shotgun, Kulfi, Kofte, Senlin, Braciola, Mocha,
Lido, Horizon, Zaqar, Heat, Calippo.

That wins the second place in my personal "let's spam the package
namespace with meaningless names" rank. The first is the research
community, who at least have the excuse that they can synthetize all
sorts of substances:

asdftool - Command line tool to manipulate ASDF scientific data files
circlator - circularize genome assemblies
seer - genomic sequence element (kmer) enrichment analysis
dindel - determines indel calls from short-read data
spaced - alignment-free sequence comparison using spaced words
stacks - pipeline for building loci from short-read DNA sequences
surankco - Supervised Ranking of Contigs in de novo Assemblies

These are some new entries. I like the name asdftool, it gives me the
idea of someone going "we have so many nonsense names that we could just
as well name this one by bashing randomly on the keyboard". Circlator
I'm sure means something in Plukanian[1]. "seer" is yet another step on
the slippery slope that will one day give us a package called "doer".
"dindel" sounds like a Bavarian localisation package. "spaced" is how I
feel going through those names. "Stacks" feels like a tease towards the
OpenStack people, like sticking the middle finger and yelling "you are
NEVER going to catch up!". Surankco sounds to me like some character out
of One Punch Man,

Actually, if you are looking for a name for a new videogame or comic
book character, just run:

grep -E 'field::(biology|chemistry|medicine)' /var/lib/debtags/package-tags|sed -re 's/:.+//'|sort -u|less

"And in the next match at the Circos Martial Arts Tournament, we have
Biosquid, who just won the match against Epigrass, facing Muscle, the
most promising disciple of Abyss and Clustal"

Let's take this package:

python-shotgun/testing,testing 0.1.0+2016.12.30.git.0682f20c42-1 all
Create and save Fuel diagnostic snapshots

I thought it was about shooting yourself in the foot, by connecting an
untested tool you just saw on Hacker News to the OBD-II port of your
car.

Nope: it's some openstack thing with a description made of 11 lines of
enterprise nonsense and two lines of "it reads yaml, collects log files
and stuff, and helps diagnose stuff".

Please at least make sure that all the openstack packages have
suite::openstack tags assigned, and then let's figure out how to have
apt run some recipes to make some tags available in the package short
descriptions, so that it can show like this on "apt search":

python-shotgun/testing,testing 0.1.0+2016.12.30.git.0682f20c42-1 all
[openstack] Create and save Fuel diagnostic snapshots


Enrico in a "you're all evidently gone mad and probably dangerous"
sunday morning mood

[1] https://en.wikipedia.org/wiki/Kin-dza-dza!#Plukanian_language

--
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.
Reply | Threaded
Open this post in threaded view
|

Re: Package naming rant

Thomas Goirand-3
In reply to this post by Enrico Zini
Hi Enrico,

Thanks for, via IRC, pointing me to your post, and for your message itself.

On 04/17/2016 03:43 PM, Enrico Zini wrote:
> Then, OpenStack packages. Which of these are actual openstack things?
>
>    Oslo, Tataouine, Magnum, Rump, Keystone, Mistral, Glance, Sahara,
>    Schinkenzwiebelmettwurst, Ceilometer, Fuel, Shade, Antani, Congress,
>    Barbican, Taskflow, Tosca, Shaft, Trove, Brazier, Mellanox, Manila,
>    Tripleo, Castellan, Murano, Hoverboard, Ironic, Swift, Tuskar,
>    Capacitor, Ember, Perth, Nova, Inculo, Arista, Neutron, Rally,
>    Designate, Cinder, Shotgun, Kulfi, Kofte, Senlin, Braciola, Mocha,
>    Lido, Horizon, Zaqar, Heat, Calippo.

I'm not sure where you got that list, but a number of these packages
aren't from OpenStack. Or at least, I never heard of such projects, and
they aren't packaged. On your list, here's what I've uploaded on Sid:

>    Oslo, Magnum, Rump, Keystone, Mistral, Glance, Sahara,
>    Ceilometer, Fuel, Shade, Antani, Congress,
>    Barbican, Taskflow, Trove, Mellanox, Manila,
>    Tripleo, Castellan, Murano, Ironic, Swift,
>    Nova, Arista, Neutron, Rally,
>    Designate, Cinder, Shotgun, Senlin,
>    Horizon, Zaqar, Heat

Now, about the naming itself, let me give my opinion.

I could have pre-fixed all packages with "openstack-" like they did in
RDO/Red Hat, but this has proven to be really not convenient at all for
OpenStack users, with for example, names like this one:

neutron-openvswitch-agent

Add OpenStack and it becomes:

openstack-neutron-openvswitch-agent

This IMO is a way too long.

The OpenStack PKG group on Alioth contains currently 371 source
packages, out of which a bit more than 100 are general purpose Python
libs (so it'd be fair to say we have more than 200 source packages).
Adding an "openstack-" prefix would be really a lot of additional
typing, both for package maintainers and final users, and it wouldn't
help our final users so much.

More over, I don't believe the OpenStack packages are in any way
"polluting the namespace", as these names are carefully crafted so that
what is chosen doesn't exist anywhere else. It's been proven to be wrong
a few times though, but that's mostly the case.

> That wins the second place in my personal "let's spam the package
> namespace with meaningless names" rank.

None of the names are meaningless. I could provide explanations for each
and every one of them (though probably nobody in this list cares about it).

> Let's take this package:
>
>    python-shotgun/testing,testing 0.1.0+2016.12.30.git.0682f20c42-1 all
>      Create and save Fuel diagnostic snapshots
>
> I thought it was about shooting yourself in the foot, by connecting an
> untested tool you just saw on Hacker News to the OBD-II port of your
> car.
>
> Nope: it's some openstack thing with a description made of 11 lines of
> enterprise nonsense and two lines of "it reads yaml, collects log files
> and stuff, and helps diagnose stuff".

One of the things shotgun does is actually destroying a node who failed
to deployed, so that it reboots and can be re-provisioned, which
explains the name. Over time, its main mission changed to what it is
right now: a diagnostic utility who collects deployment logs. Shotgun is
part of Fuel, and it makes no sense to describe Shotgun without
explaining what Fuel is, as it is pretty much useless without Fuel.

I'm sorry if you feel like the description of Fuel is looking like
"enterprise nonsense". I don't really like it so much either, and
probably I should rewrite what's from upstream. Please feel free to
provide something better, and I'll propagate it to all Fuel packages.

Also, for many packages, upstream is providing either a very small, or
even an non-existent description of the package. That's also the case
for shotgun: have a look at the README.rst from upstream:

https://github.com/openstack/shotgun

I'm often taking a lot of time to make sure that the short and long
descriptions are good enough for Debian. Sometimes, I even have to
investigate to understand what the packages does, as it comes just as a
mandatory dependency, and upstream didn't care at all to write a
description. Of course, I always accept contributions, and mostly,
upstream too.

> Please at least make sure that all the openstack packages have
> suite::openstack tags assigned, and then let's figure out how to have
> apt run some recipes to make some tags available in the package short
> descriptions, so that it can show like this on "apt search":
>
>    python-shotgun/testing,testing 0.1.0+2016.12.30.git.0682f20c42-1 all
>      [openstack] Create and save Fuel diagnostic snapshots

I once took the time to manually edit tags of all OpenStack packages.
However, I gave up, because it took too long to use the web interface,
which didn't propose to do multi-edit (ie: add a group of tags to
multiple packages at once). After I asked you, you then explained to me
how I could script it, but that was too complicated, and then I finally
gave up.

Moving forward, what I would like to see is an easy to use shell tool to
do what's needed. For example, something like this:

debtags -kAC6B43FE -p python-shotgun \
  -t implemented-in::python,role::program,suite::openstack,system::cloud

I don't think it'd be hard to implement, especially as you're a Python
guru yourself, and there's already an API. Maybe the only part that
would be a trouble would be the authentication (on the above I used a
PGP key, but maybe it'd be possible to re-use client certs?). Or maybe
such a client already exists and I missed it?

If I had such a tool available, I'd be tagging all of my packages very
shortly. Without it, I feel like I have to write the tool first,
otherwise, it will take too long.

Also, I was very disappointed to realize lots of the tags I edited a few
years ago for OpenStack seem to be completely gone (or at least, they
don't show on the web editor). What happened?

Hoping the above is giving you some insights, and will help improving
debtags too.

Cheers,

Thomas Goirand (zigo)

Reply | Threaded
Open this post in threaded view
|

Re: Package naming rant

Aigars Mahinovs

On Mon, Apr 18, 2016 at 11:27 AM Thomas Goirand <[hidden email]> wrote:
Now, about the naming itself, let me give my opinion.

I could have pre-fixed all packages with "openstack-" like they did in
RDO/Red Hat, but this has proven to be really not convenient at all for
OpenStack users, with for example, names like this one:

neutron-openvswitch-agent

Add OpenStack and it becomes:

openstack-neutron-openvswitch-agent

This IMO is a way too long.

There could be a simple rule of thumb - if the name of the package makes sense and is correctly understood without it being in the openstack context, then it can exist without the prefix.
 
> Let's take this package:
>
>    python-shotgun/testing,testing 0.1.0+2016.12.30.git.0682f20c42-1 all
>      Create and save Fuel diagnostic snapshots
>
> I thought it was about shooting yourself in the foot, by connecting an
> untested tool you just saw on Hacker News to the OBD-II port of your
> car.
>
> Nope: it's some openstack thing with a description made of 11 lines of
> enterprise nonsense and two lines of "it reads yaml, collects log files
> and stuff, and helps diagnose stuff".

One of the things shotgun does is actually destroying a node who failed
to deployed, so that it reboots and can be re-provisioned, which
explains the name. Over time, its main mission changed to what it is
right now: a diagnostic utility who collects deployment logs. Shotgun is
part of Fuel, and it makes no sense to describe Shotgun without
explaining what Fuel is, as it is pretty much useless without Fuel.

Word "Fuel" and word "Shotgun" have meanings outside the OpenStack context. Thus unless Fuel collects gas mileage data and shotgun destroys all kinds of stuff, then prefixing the name with OpenStack is essential for understanding. And not only in the package names. That description is meaningless unless you already know that "Fuel" is OpenStack, so that also should be replaced by "OpenStack Fuel project".

It does not matter that OpenStack Oslo makes sense in the OpenStack context unless you put the reader into the OpenStack context first. Out of that context that is a city name. And that is confusing. At least for me it is for sure.
 
Reply | Threaded
Open this post in threaded view
|

Re: Package naming rant

Justin B Rye-3
In reply to this post by Thomas Goirand-3
Thomas Goirand wrote:
> Enrico Zini wrote:
>> That wins the second place in my personal "let's spam the package
>> namespace with meaningless names" rank.
>
> None of the names are meaningless. I could provide explanations for each
> and every one of them (though probably nobody in this list cares about it).

Contributions welcome at https://wiki.debian.org/WhyTheName !
--
JBR with qualifications in linguistics, experience as a Debian
        sysadmin, and probably no clue about this particular package

Reply | Threaded
Open this post in threaded view
|

Re: Package naming rant

Elena ``of Valhalla''-2
In reply to this post by Thomas Goirand-3
On 2016-04-18 at 11:26:26 +0200, Thomas Goirand wrote:
> I could have pre-fixed all packages with "openstack-" like they did in
> RDO/Red Hat, but this has proven to be really not convenient at all for
> OpenStack users, with for example, names like this one:
> [...]
> Adding an "openstack-" prefix would be really a lot of additional
> typing, both for package maintainers and final users, and it wouldn't
> help our final users so much.

Wait, does this mean that there is actually some people out there who is
still typing package names?

I thought that everybody was just copypasting them from some web page /
running apt from a script that had been curled and piped to the shell!

(or — but this is getting a bit OT for this list — using tab to complete
the name, or some other sensible way not to type long lists of names
multiple times, including using orchestration tools etc.)
--
Elena ``of Valhalla''

Reply | Threaded
Open this post in threaded view
|

Re: Package naming rant

Thomas Goirand-3
In reply to this post by Aigars Mahinovs
On 04/18/2016 11:43 AM, Aigars Mahinovs wrote:

>
> On Mon, Apr 18, 2016 at 11:27 AM Thomas Goirand <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Now, about the naming itself, let me give my opinion.
>
>     I could have pre-fixed all packages with "openstack-" like they did in
>     RDO/Red Hat, but this has proven to be really not convenient at all for
>     OpenStack users, with for example, names like this one:
>
>     neutron-openvswitch-agent
>
>     Add OpenStack and it becomes:
>
>     openstack-neutron-openvswitch-agent
>
>     This IMO is a way too long.
>
>
> There could be a simple rule of thumb - if the name of the package makes
> sense and is correctly understood without it being in the openstack
> context, then it can exist without the prefix.

The point being that users of OpenStack at least know the names of the
services they install (ie: nova for Compute, Neutron for networking,
etc.). The fact that non-OpenStack users will probably not understand
what the package does without reading the description isn't really a
problem. As for the libs, even OpenStack users don't even need to bother
knowing what they are, as they will be installed thanks to dependencies,
so in fact, only the package maintainers care.

Now, the only thing there is to fix, is IMO the tags of the packages.
Hopefully, maybe Enrico can help me to fix that.

> Word "Fuel" and word "Shotgun" have meanings outside the OpenStack
> context.

This is the case of all programs which have a name that isn't explaining
what it does. We all have loads of them installed on our
workstation/laptops. Do you believe Firefox, Thunderbird, Gobby, Skype,
Steam (to just name a few) have names with more meaning? I don't think
so, it's just that they are more famous, and you know them because you
use them.

> Thus unless Fuel collects gas mileage data and shotgun destroys
> all kinds of stuff, then prefixing the name with OpenStack is essential
> for understanding. And not only in the package names. That description
> is meaningless unless you already know that "Fuel" is OpenStack, so that
> also should be replaced by "OpenStack Fuel project".
>
> It does not matter that OpenStack Oslo makes sense in the OpenStack
> context unless you put the reader into the OpenStack context first. Out
> of that context that is a city name. And that is confusing. At least for
> me it is for sure.

Oslo means: OpenStack Light Orchestra. If you guys think it's useful, I
can add this to the long description of all Oslo packages. However, I'm
convinced (but didn't check them all) that all Oslo packages have at
least one the word OpenStack in the short and/or long description, so
I'm not sure this will help anyone.

Cheers,

Thomas Goirand (zigo)

Reply | Threaded
Open this post in threaded view
|

Re: Package naming rant

Enrico Zini
In reply to this post by Thomas Goirand-3
On Mon, Apr 18, 2016 at 11:26:26AM +0200, Thomas Goirand wrote:

> Moving forward, what I would like to see is an easy to use shell tool to
> do what's needed. For example, something like this:
>
> debtags -kAC6B43FE -p python-shotgun \
>   -t implemented-in::python,role::program,suite::openstack,system::cloud
[...]
> If I had such a tool available, I'd be tagging all of my packages very
> shortly. Without it, I feel like I have to write the tool first,
> otherwise, it will take too long.

Fresh out of the oven, you can paste a tag patch here:
https://debtags.debian.org/api/patch

The format is described here: https://debtags.debian.org/api/

> Also, I was very disappointed to realize lots of the tags I edited a few
> years ago for OpenStack seem to be completely gone (or at least, they
> don't show on the web editor). What happened?

I looked through the backups of the site and traced their disappearance
to the time this commit was put into production:
http://anonscm.debian.org/cgit/debtags/debtagsd.git/commit/?id=610a80e268daeb4570be63791752276205091cd3

It could be that the change in the source of package information for
debtags temporarily gave the site a package database that didn't have
the packages you had just tagged.

I've regenerated the openstack-related patch for the data up to that
day: find it attached.


Enrico

--
GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini <[hidden email]>

openstack.patch (7K) Download Attachment
signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Package naming rant

Thomas Goirand-3
On 04/20/2016 07:54 PM, Enrico Zini wrote:

> On Mon, Apr 18, 2016 at 11:26:26AM +0200, Thomas Goirand wrote:
>
>> Moving forward, what I would like to see is an easy to use shell tool to
>> do what's needed. For example, something like this:
>>
>> debtags -kAC6B43FE -p python-shotgun \
>>   -t implemented-in::python,role::program,suite::openstack,system::cloud
> [...]
>> If I had such a tool available, I'd be tagging all of my packages very
>> shortly. Without it, I feel like I have to write the tool first,
>> otherwise, it will take too long.
>
> Fresh out of the oven, you can paste a tag patch here:
> https://debtags.debian.org/api/patch
>
> The format is described here: https://debtags.debian.org/api/

Whaaa! Exactly what was needed. I've added hundreds of tags within a few
minutes, doing a bit of echo / grep / awk on the shell to generate the
patches!

Thanks so much.
Cheers,

Thomas Goirand (zigo)

Reply | Threaded
Open this post in threaded view
|

Re: Package naming rant

Ian Jackson-2
In reply to this post by Thomas Goirand-3
Thomas Goirand writes ("Re: Package naming rant"):

> On 04/18/2016 11:43 AM, Aigars Mahinovs wrote:
> > There could be a simple rule of thumb - if the name of the package makes
> > sense and is correctly understood without it being in the openstack
> > context, then it can exist without the prefix.
>
> The point being that users of OpenStack at least know the names of the
> services they install (ie: nova for Compute, Neutron for networking,
> etc.). The fact that non-OpenStack users will probably not understand
> what the package does without reading the description isn't really a
> problem. As for the libs, even OpenStack users don't even need to bother
> knowing what they are, as they will be installed thanks to dependencies,
> so in fact, only the package maintainers care.

This argument seems to suppose that no-one unfamiliar with a package
ever reads its name.  This is an astonishing assumption.

There are numerous interfaces (including search interfaces) where the
output is a list of packages, with the package name being a principal
part of the output (or sometimes the only output).

So I agree with Aigars.

Also, *applause* to Enrico for the head article in this thread.

Thanks,
Ian.

Reply | Threaded
Open this post in threaded view
|

Re: Package naming rant

Thomas Goirand-3
On 04/21/2016 05:27 PM, Ian Jackson wrote:

> Thomas Goirand writes ("Re: Package naming rant"):
>> On 04/18/2016 11:43 AM, Aigars Mahinovs wrote:
>>> There could be a simple rule of thumb - if the name of the package makes
>>> sense and is correctly understood without it being in the openstack
>>> context, then it can exist without the prefix.
>>
>> The point being that users of OpenStack at least know the names of the
>> services they install (ie: nova for Compute, Neutron for networking,
>> etc.). The fact that non-OpenStack users will probably not understand
>> what the package does without reading the description isn't really a
>> problem. As for the libs, even OpenStack users don't even need to bother
>> knowing what they are, as they will be installed thanks to dependencies,
>> so in fact, only the package maintainers care.
>
> This argument seems to suppose that no-one unfamiliar with a package
> ever reads its name.  This is an astonishing assumption.

In the general case, I'd agree. But we're not talking about "a package"
here, but about a complete *suite* of a complex cloud system.

The argument is that you can't use OpenStack without at least learning
what the components are, which makes it pointless (and in fact very
annoying) to prefix them with openstack-. I'd say it take at least a
month to understand all the interactions.

Now that there's the suite::openstack on all of these packages, it will
be a lot easier to search anyway. Also, I take a great care about the
short descriptions.

Cheers,

Thomas Goirand (zigo)

Reply | Threaded
Open this post in threaded view
|

Re: Package naming rant

Aigars Mahinovs
On Thu, Apr 21, 2016 at 6:47 PM Thomas Goirand <[hidden email]> wrote:
On 04/21/2016 05:27 PM, Ian Jackson wrote:
> This argument seems to suppose that no-one unfamiliar with a package
> ever reads its name.  This is an astonishing assumption.

In the general case, I'd agree. But we're not talking about "a package"
here, but about a complete *suite* of a complex cloud system.

The argument is that you can't use OpenStack without at least learning
what the components are, which makes it pointless (and in fact very
annoying) to prefix them with openstack-. I'd say it take at least a
month to understand all the interactions.

I don't want to use OpenStack. I want to find a fuel logging application to keep track of the expenses in my car. I search packages for "fuel" and find Fuel. So I install it. At this point there is very little to tell me if those 50 packages it is now puling in are some libraries like boost or KDE or it is actually a network of support services that will be turning my laptop into an enterprise cluster service provider. The first would be fine, the second is rather obviously not what I wanted.

That is why use of a package is pointless without some kind of wider system, the name of that system must be at least in the short description if not in the name, but also a description of OpenStack must be in the long description so that I can figure out what that big system is and if I want it or not without having to google stuff from the description.
 
Reply | Threaded
Open this post in threaded view
|

Re: Package naming rant

Gunnar Wolf
In reply to this post by Thomas Goirand-3
Thomas Goirand dijo [Thu, Apr 21, 2016 at 06:46:47PM +0200]:

> In the general case, I'd agree. But we're not talking about "a package"
> here, but about a complete *suite* of a complex cloud system.
>
> The argument is that you can't use OpenStack without at least learning
> what the components are, which makes it pointless (and in fact very
> annoying) to prefix them with openstack-. I'd say it take at least a
> month to understand all the interactions.
>
> Now that there's the suite::openstack on all of these packages, it will
> be a lot easier to search anyway. Also, I take a great care about the
> short descriptions.

Supporting what I understand from Ian's, Aigars' and Enrico's points,
we have many aeas where the area of application for a package is
encoded in the package name itself. We have (according to "apt-cache
search") 1011 packages starting with "ruby-", 3566 conforming with
"lib.*-perl", 3173 starting with "python-", and even for newcomers,
451 starting with "golang-". And some of them do have quite deep names
(which have been argued against repeatedly for different reasons),
such as (five longest for each):


ruby-rails-assets-jeresig-jquery.hotkeys
ruby-rails-assets-jquery-fullscreen-plugin
ruby-rails-assets-jakobmattsson-jquery-elastic
ruby-rails-assets-markdown-it-diaspora-mention
ruby-rails-assets-markdown-it--markdown-it-for-inline

libbusiness-onlinepayment-transactioncentral-perl
libcatalyst-action-serialize-data-serializer-perl
libplack-middleware-fixmissingbodyinredirect-perl
libcatalyst-authentication-credential-authen-simple-perl
libcatalyst-plugin-authentication-credential-openid-perl

python-xstatic-jquery.bootstrap.wizard
python-sphinxcontrib.programoutput-doc
python-fedmsg-meta-fedora-infrastructure
python-zope.component-persistentregistry
python-djangorestframework-fsm-transitions

golang-github-hashicorp-go-immutable-radix-dev
golang-github-hashicorp-net-rpc-msgpackrpc-dev
golang-github-hydrogen18-stoppablelistener-dev
golang-github-cyberdelia-go-metrics-graphite-dev
golang-github-shurcool-sanitized-anchor-name-dev

Even more, querying from the 50665 my apt-cache knows about, without
discrimination of any kind, the ten longest are:

 $ apt-cache search .|cut -f 1 -d \ |perl -e '@data = sort {length($a)<=>length($b)} <>; print @data[-10..-1]'
 libbusiness-onlinepayment-transactioncentral-perl
 libcatalyst-action-serialize-data-serializer-perl
 libplack-middleware-fixmissingbodyinredirect-perl
 libmono-system-reactive-observable-aliases0.0-cil
 libmono-system-componentmodel-dataannotations4.0-cil
 ruby-rails-assets-markdown-it--markdown-it-for-inline
 libmono-system-windows-forms-datavisualization4.0a-cil
 libcatalyst-authentication-credential-authen-simple-perl
 libcatalyst-plugin-authentication-credential-openid-perl
 libmono-system-runtime-serialization-formatters-soap4.0-cil

So, in all fairness, looking at the longest-named packages mentioning
Openstack:

 $ apt-cache search openstack|cut -f 1 -d \ |perl -e '@data = sort {length($a)<=>length($b)} <>; print @data[-5..-1]'
 python-sphinxcontrib-docbookrestapi
 python-sphinxcontrib.docbookrestapi
 golang-github-rackspace-gophercloud-dev
 fusiondirectory-plugin-openstack-compute
 fusiondirectory-plugin-openstack-compute-schema

Adding 'openstack-' somewhere in their package name won't hurt users
too much.

Reply | Threaded
Open this post in threaded view
|

Re: Package naming rant

Hubert Chathi
In reply to this post by Aigars Mahinovs
On Thu, 21 Apr 2016 16:53:50 +0000, Aigars Mahinovs <[hidden email]> said:

> I don't want to use OpenStack. I want to find a fuel logging
> application to keep track of the expenses in my car. I search packages
> for "fuel" and find Fuel. So I install it. ...

First of all, I don't see a package that's simply named "fuel", but...

So you install packages without at least reading their short
descriptions?  If you want to get information about the 24th element of
the periodic table, would you install the chromium package?  If you want
to brew a hot beverage, would you install the tea package?  If you want
to work with stretchy materials, would you install the rubber package?
If you want advice on dealing with foolish people, would you install the
git package?  If you want to read the minds of mythical creatures, would
you install the telepathy-phoenix package?  If you want to manage your
collection of precious stones, would you install the ruby package?  If
you want to commit arson easily, would you install the simpleburn
package?  If you want to study light particles, would you install the
photon package?  If you want to put on a show with marionettes, would
you install the puppet package?  If you want to prepare food for your
restaurant, would you install the chef package?  If you want to count
your chickens before they hatch, would you install the egg package?

If you install a package without at least making a minimal effort at
finding out what it's about (i.e. reading the short description, if not
the long description), then I'd say it's your own fault if you don't get
what you expected.

--
Hubert Chathi <[hidden email]> -- Jabber: [hidden email]
PGP/GnuPG key: 4096R/113A1368         https://www.uhoreg.ca/
Fingerprint: F24C F749 6C73 DDB8 DCB8  72DE B2DE 88D3 113A 1368

Reply | Threaded
Open this post in threaded view
|

Re: Package naming rant

Aigars Mahinovs


On Thu, Apr 21, 2016 at 9:00 PM Hubert Chathi <[hidden email]> wrote:
On Thu, 21 Apr 2016 16:53:50 +0000, Aigars Mahinovs <[hidden email]> said:

> I don't want to use OpenStack. I want to find a fuel logging
> application to keep track of the expenses in my car. I search packages
> for "fuel" and find Fuel. So I install it. ...

First of all, I don't see a package that's simply named "fuel", but...

fuel-agent
fuel image based provisioning agent

Ok, so it lets me to take pictures of my fuel bills and then does somethinng to provision me with more fuel? Sure!

OpenStack is not in the long description even.
 
Reply | Threaded
Open this post in threaded view
|

Re: Package naming rant

Thomas Goirand-3
In reply to this post by Gunnar Wolf
On 04/21/2016 08:08 PM, Gunnar Wolf wrote:

> Thomas Goirand dijo [Thu, Apr 21, 2016 at 06:46:47PM +0200]:
>> In the general case, I'd agree. But we're not talking about "a package"
>> here, but about a complete *suite* of a complex cloud system.
>>
>> The argument is that you can't use OpenStack without at least learning
>> what the components are, which makes it pointless (and in fact very
>> annoying) to prefix them with openstack-. I'd say it take at least a
>> month to understand all the interactions.
>>
>> Now that there's the suite::openstack on all of these packages, it will
>> be a lot easier to search anyway. Also, I take a great care about the
>> short descriptions.
>
> Supporting what I understand from Ian's, Aigars' and Enrico's points,
> we have many aeas where the area of application for a package is
> encoded in the package name itself. We have (according to "apt-cache
> search") 1011 packages starting with "ruby-", 3566 conforming with
> "lib.*-perl", 3173 starting with "python-", and even for newcomers,
> 451 starting with "golang-". And some of them do have quite deep names
> (which have been argued against repeatedly for different reasons),
> such as (five longest for each):
>
>
> ruby-rails-assets-jeresig-jquery.hotkeys
> ruby-rails-assets-jquery-fullscreen-plugin
> ruby-rails-assets-jakobmattsson-jquery-elastic
> ruby-rails-assets-markdown-it-diaspora-mention
> ruby-rails-assets-markdown-it--markdown-it-for-inline
>
> libbusiness-onlinepayment-transactioncentral-perl
> libcatalyst-action-serialize-data-serializer-perl
> libplack-middleware-fixmissingbodyinredirect-perl
> libcatalyst-authentication-credential-authen-simple-perl
> libcatalyst-plugin-authentication-credential-openid-perl
>
> python-xstatic-jquery.bootstrap.wizard
> python-sphinxcontrib.programoutput-doc
> python-fedmsg-meta-fedora-infrastructure
> python-zope.component-persistentregistry
> python-djangorestframework-fsm-transitions
>
> golang-github-hashicorp-go-immutable-radix-dev
> golang-github-hashicorp-net-rpc-msgpackrpc-dev
> golang-github-hydrogen18-stoppablelistener-dev
> golang-github-cyberdelia-go-metrics-graphite-dev
> golang-github-shurcool-sanitized-anchor-name-dev
>
> Even more, querying from the 50665 my apt-cache knows about, without
> discrimination of any kind, the ten longest are:
>
>  $ apt-cache search .|cut -f 1 -d \ |perl -e '@data = sort {length($a)<=>length($b)} <>; print @data[-10..-1]'
>  libbusiness-onlinepayment-transactioncentral-perl
>  libcatalyst-action-serialize-data-serializer-perl
>  libplack-middleware-fixmissingbodyinredirect-perl
>  libmono-system-reactive-observable-aliases0.0-cil
>  libmono-system-componentmodel-dataannotations4.0-cil
>  ruby-rails-assets-markdown-it--markdown-it-for-inline
>  libmono-system-windows-forms-datavisualization4.0a-cil
>  libcatalyst-authentication-credential-authen-simple-perl
>  libcatalyst-plugin-authentication-credential-openid-perl
>  libmono-system-runtime-serialization-formatters-soap4.0-cil
>
> So, in all fairness, looking at the longest-named packages mentioning
> Openstack:
>
>  $ apt-cache search openstack|cut -f 1 -d \ |perl -e '@data = sort {length($a)<=>length($b)} <>; print @data[-5..-1]'
>  python-sphinxcontrib-docbookrestapi
>  python-sphinxcontrib.docbookrestapi
>  golang-github-rackspace-gophercloud-dev
>  fusiondirectory-plugin-openstack-compute
>  fusiondirectory-plugin-openstack-compute-schema
>
> Adding 'openstack-' somewhere in their package name won't hurt users
> too much.

You're comparing applications and libraries, IMO, that's not relevant.
It's natural to add "python" for python libs, you're even kind of forced
to do it by the way dh_python{2,3} are working. But for application,
it's best to just keep what upstream uses.

FYI, Red Hat decided to prefix everything with openstack-, so we have
things like: openstack-neutron-plugin-linuxbridge-agent. Users don't
like it at all.

Last, I'm not alone here. If we were to rename all OpenStack packages
for services, then this would break all the compatibility with the
puppet-openstack manifests, which are working for both Debian and
Ubuntu. I really don't want to do that, Quite the opposite: I'm making
efforts so that packages in Ubuntu and Debian are at least close, so
that there's not too many differences to handle. Already, there's
special cases for Neutron, Nova and Horizon, as they are slightly
different in Ubuntu and Debian.

Could we have this discussion in the OpenStack PKG list instead? It
doesn't feel like this list is the appropriate one. I also don't believe
that any of the people writing in this thread are OpenStack users, are
you guys?

Cheers,

Thomas Goirand (zigo)

Reply | Threaded
Open this post in threaded view
|

Re: Package naming rant

Aigars Mahinovs

On Thu, 21 Apr 2016, 21:58 Thomas Goirand, <[hidden email]> wrote:

Could we have this discussion in the OpenStack PKG list instead? It
doesn't feel like this list is the appropriate one. I also don't believe
that any of the people writing in this thread are OpenStack users, are
you guys?


That is the point - namespace pollution affects everyone and is especially annoying to people that do *not* use OpenStack or do not even know what that is.

openstack-neutron-plugin-linuxbridge-agent is a perfectly normal name that reasonably describes what is in it. Imagine every dash-separate part as a namespace. If you do not need Python things, then you do not look into python* packages.

You can make a openstack-fuel-agent package and it will be clear that it is useless to people that do not know what openstack is. By making a package in a general namespace you are basically saying that this package is useful to everyone, that people do not need to know or use openstack for it to be useful to them.

In the same vein packages that are only useful to people writing Python software are in python-* (for example python-virtualenv is not a library), but regular apps that happen to be written in Python are not.
Reply | Threaded
Open this post in threaded view
|

Re: Package naming rant

Hubert Chathi
On Thu, 21 Apr 2016 20:47:34 +0000, Aigars Mahinovs <[hidden email]> said:

> You can make a openstack-fuel-agent package and it will be clear that
> it is useless to people that do not know what openstack is. ...

Not necessarily: "openstack-fuel-agent" (by itself) can just as easily
be understood (by someone who has no idea what OpenStack is) as "a fuel
agent named openstack", just like the "chromium-browser" package is
(was) "a browser called Chromium", or "ninja-build" is "a build system
called ninja".  So someone who is looking for, say, a fuel tracker might
not be any less confused by "openstack-fuel-agent" than by just
"fuel-agent".

--
Hubert Chathi <[hidden email]> -- Jabber: [hidden email]
PGP/GnuPG key: 4096R/113A1368         https://www.uhoreg.ca/
Fingerprint: F24C F749 6C73 DDB8 DCB8  72DE B2DE 88D3 113A 1368

Reply | Threaded
Open this post in threaded view
|

Re: Package naming rant

Tollef Fog Heen
]] Hubert Chathi

> Not necessarily: "openstack-fuel-agent" (by itself) can just as easily
> be understood (by someone who has no idea what OpenStack is) as "a fuel
> agent named openstack", just like the "chromium-browser" package is
> (was) "a browser called Chromium", or "ninja-build" is "a build system
> called ninja".  So someone who is looking for, say, a fuel tracker might
> not be any less confused by "openstack-fuel-agent" than by just
> "fuel-agent".

The chance of somebody using Debian knowing what OpenStack is is much,
much higher than the chance of them knowing that fuel (or neutron or
nova or whatever) is an openstack component and making the connection
between those two.

--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Reply | Threaded
Open this post in threaded view
|

Re: Package naming rant

Thomas Harding-5
In reply to this post by Hubert Chathi


Le 21 avril 2016 23:23:49 GMT+02:00, Hubert Chathi <[hidden email]> a écrit :

>On Thu, 21 Apr 2016 20:47:34 +0000, Aigars Mahinovs
><[hidden email]> said:
>
>> You can make a openstack-fuel-agent package and it will be clear that
>> it is useless to people that do not know what openstack is. ...
>
>Not necessarily: "openstack-fuel-agent" (by itself) can just as easily
>be understood (by someone who has no idea what OpenStack is) as "a fuel
>agent named openstack", just like the "chromium-browser" package is
>(was) "a browser called Chromium", or "ninja-build" is "a build system
>called ninja".  So someone who is looking for, say, a fuel tracker
>might
>not be any less confused by "openstack-fuel-agent" than by just
>"fuel-agent".

"I must document system"
Or "anything to do with security review"

Contextual names are better.

Just  think of how Apache modules are named after.


--
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.

12