Re: Package naming rant

[Arnt Karlsen]

On Fri, 22 Apr 2016 10:47:03 +0200, Enrico wrote in message 
<20160422084703.ga24...@enricozini.org>:

> I'm all for technical solutions to social problems.

..easy now, drones and gas chambers=$(technical solutions) 
to solve nazi etc hatred=$(social problems)? ;o)

-- 
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.

Re: Package naming rant

[Thomas Harding]

Just  think of that list is non-technical. Curiosa is fun-only :-)

Le 23 avril 2016 12:04:13 GMT+02:00, Jakub Wilk  a écrit :
>* Holger Levsen , 2016-04-23, 09:53:
>>>On a more general way, I'm really disappointed by this thread.
>
>Me too! Most of the messages were scandalously serious!
>
>>same here. "passive aggressive disguised as funny" is a bit too harsh 
>>as summary, but not much, IMO.
>
>We badly need new mailing list: debian-rants@l.d.o
>
>-- 
>Jakub Wilk

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

Re: Package naming rant

[Mehdi Dogguy]

Thomas,

On 23/04/2016 01:42, Thomas Goirand wrote:
> On 04/21/2016 10:47 PM, Aigars Mahinovs wrote:
>> 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.
> 
> As I wrote in another reply, Fuel could be used in another context than
> just OpenStack. It's not the case now, but maybe it will happen one day.
> 
> On a more general way, I'm really disappointed by this thread.
> 

Your packages are very fine. There is nothing you can do about their names
and adding "openstack" in them will not serve any serious goal.

You should not take this thread personally and let people rant. People have
different point of views (to be taken seriously or not). You cannot convince
everyone. At most, the initial message in this thread should make you smile.
:-) You should ignore the rest if it affects you personally.

Keep up your good work on OpenStack!

-- 
Mehdi

Re: Package naming rant

[Jakub Wilk]

* Holger Levsen , 2016-04-23, 09:53:

On a more general way, I'm really disappointed by this thread.


Me too! Most of the messages were scandalously serious!

same here. "passive aggressive disguised as funny" is a bit too harsh 
as summary, but not much, IMO.


We badly need new mailing list: debian-rants@l.d.o

--
Jakub Wilk

Re: Package naming rant

[Holger Levsen]

On Sat, Apr 23, 2016 at 01:42:53AM +0200, Thomas Goirand wrote:
> On a more general way, I'm really disappointed by this thread.

same here. "passive aggressive disguised as funny" is a bit too harsh as
summary, but not much, IMO.

> Guys, I don't appreciate this joke at all. Probably I should stop caring
> for all of this, just let upstream do all sorts of nasty things, package
> and upload that to Debian. Why should I care, if anyway, I get this type
> of thread in return?

understood.

Thomas, I applaud your impressive work on openstack, even though I'm not
even using it! :-) (and if there are bugs, be it unclear descriptions or
whatever, they should be filed as actionable bugs.)


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: Package naming rant

[Aigars Mahinovs]

Thomas, please don't take this personally. We appreciate your work. That is
not in doubt. This more about making sure that we all take a step back when
writing package names, short and long descriptions and think for a moment
how to make this understandable for people that are new to the package, new
to Debian and new to Linux. Even if it is just enough to make it clear that
they do not need this package unless they already know that they do.
Sometimes a longer description with more context is better for such a
purpose.

Upstream might not get that or care about it, but this what we do - make
their work accessible to others.

On Sat, 23 Apr 2016, 01:43 Thomas Goirand,  wrote:

> On 04/21/2016 10:47 PM, Aigars Mahinovs wrote:
> > 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.
>
> As I wrote in another reply, Fuel could be used in another context than
> just OpenStack. It's not the case now, but maybe it will happen one day.
>
> On a more general way, I'm really disappointed by this thread.
>
> In general, I take a great care of having consistent naming. I have
> mostly correct short and long descriptions which I care for, and for
> which I often discuss with some upstream who mostly don't care (so it's
> often hard to ask for a good description). Once or twice, I asked
> packaged to be renamed upstream. I also cared for the /usr/bin
> namespace. This is done over a *very* large amount of packages (which
> took me as far as being the DD with the biggest amount of Python module
> packaged in Debian).
>
> Instead of recognizing this efforts, or even checking if I do this kind
> of work or not, I'm getting rants over a very long thread about how
> silly the upstream name is, that the packages I maintain probably are
> polluting the /usr/bin namespace (without even checking for the fact),
> and all this type of crap.
>
> Guys, I don't appreciate this joke at all. Probably I should stop caring
> for all of this, just let upstream do all sorts of nasty things, package
> and upload that to Debian. Why should I care, if anyway, I get this type
> of thread in return?
>
> If you don't mind, please take someone else as a target. I'm leaving for
> the OpenStack summit in 24 hours, I'd like to have something better,
> more positive, things to think about in the plane.
>
> Cheers,
>
> Thomas Goirand (zigo)
>
>

Re: Package naming rant

[Thomas Goirand]

On 04/21/2016 10:47 PM, Aigars Mahinovs wrote:
> 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.

As I wrote in another reply, Fuel could be used in another context than
just OpenStack. It's not the case now, but maybe it will happen one day.

On a more general way, I'm really disappointed by this thread.

In general, I take a great care of having consistent naming. I have
mostly correct short and long descriptions which I care for, and for
which I often discuss with some upstream who mostly don't care (so it's
often hard to ask for a good description). Once or twice, I asked
packaged to be renamed upstream. I also cared for the /usr/bin
namespace. This is done over a *very* large amount of packages (which
took me as far as being the DD with the biggest amount of Python module
packaged in Debian).

Instead of recognizing this efforts, or even checking if I do this kind
of work or not, I'm getting rants over a very long thread about how
silly the upstream name is, that the packages I maintain probably are
polluting the /usr/bin namespace (without even checking for the fact),
and all this type of crap.

Guys, I don't appreciate this joke at all. Probably I should stop caring
for all of this, just let upstream do all sorts of nasty things, package
and upload that to Debian. Why should I care, if anyway, I get this type
of thread in return?

If you don't mind, please take someone else as a target. I'm leaving for
the OpenStack summit in 24 hours, I'd like to have something better,
more positive, things to think about in the plane.

Cheers,

Thomas Goirand (zigo)

Re: Package naming rant

[Ben Finney]

Thomas Goirand  writes:

> I'm ok with this discussion in principle, but it's going really too
> far in this way. Let's be serious for 5 minutes please.

Best to move it somewhere like ‘debian-devel’, then. IMO.

-- 
 \   “It ain't so much the things we don't know that get us in |
  `\trouble. It's the things we know that ain't so.” —Artemus Ward |
_o__) (1834–1867), U.S. journalist |
Ben Finney

Re: Package naming rant

[Thomas Goirand]

On 04/21/2016 09:09 PM, Aigars Mahinovs wrote:
> 
> 
> On Thu, Apr 21, 2016 at 9:00 PM Hubert Chathi  > wrote:
> 
> On Thu, 21 Apr 2016 16:53:50 +, Aigars Mahinovs
> > 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.

Correct, because fuel-agent is only far related to OpenStack. It just
provision bare-metal machines with an operating system, so it could be
used for the deployment of another thing than just OpenStack, which by
the way, may happen one day with Fuel.

Now, with this in the long description:

 Fuel provides PXE booting to all of the bare metal servers it manages.

do you still believe it has something to do with gaz mileage?

I'm ok with this discussion in principle, but it's going really too far
in this way. Let's be serious for 5 minutes please.

On 04/22/2016 02:53 PM, Hubert Chathi wrote:
> For sure it would be an
> improvement to mention OpenStack at least in the long description

Not in this case, no.

Cheers,

Thomas Goirand (zigo)

Re: Package naming rant

[Thomas Goirand]

On 04/22/2016 10:47 AM, Enrico Zini wrote:
> I do not know where openstack components install themselves; if they
> install in /usr/bin stuff that is never meant to be run by the command
> line, I think it would be more approriate to jump at the throat of
> openstack upstreams rather than at that of the DDs who packaged it.

All of the things installed in /usr/bin may be run on the shell. Some
are daemons, but traditionally, we install daemons in /usr/bin, so I
don't see how OpenStack is different.

Currently, there's a lot of cli tools using /usr/bin. For example:
/usr/bin/{cinder,nova,neutron,swift}

These are the clients which the final user is using (to create volumes,
virtual machines, networks or object to store, just to take the examples
above).

Though slowly, this is being consolidated into a single "openstack"
command line. Hopefully, in a year or 2, we'll have all the individual
cli tools all migrated as Python plugins of python-openstackclient.

Now, there's loads of server packages which are dropping daemons within
/usr/bin, like nova-compute, neutron-server, cinder-volume (to stay with
the same examples). I don't believe that this will ever clash with
anything else.

> The package namespace, and the /usr/bin namespeace, are currently flat,
> and flat namespaces[2] work bettter when participants try to keep to
> some level of hygiene, and people who do not make an attempt to
> coordinate with others give a feeling like those who jump the queue at
> the bus stop.

I agree. And I often discussed with upstreams, to make sure we don't
have too generic names in /usr/bin. And upstream has always been
receptive to my recommendations.

> It may be that the right solution is not to have a single namespace, and
> to design things so that you cannot do videogames, openstack and
> biochemistry research on the same system, and if one is not interested
> in openstack/biochemistry/videogames, then one doesn't even get to see
> the openstack/biochemistry/videogames packages and get confused by them.

I'm hoping that the Bikesheds will solve that. It has always been my
intention to push all of OpenStack in there, since the first description
from Ganneff.

Though really, if one day we have a clash with an OpenStack package and
a video game (it's very unlikely, but let's pretend...), I don't think
anyone will care much if we add a Conflicts: and declare they can't be
installed at the same time. As a mater of principle, I'll still try to
solve it in a better way, but still, nobody will really care.

Cheers,

Thomas Goirand (zigo)

Re: Package naming rant

[Enrico Zini]

On Thu, Apr 21, 2016 at 09:57:45PM +0200, Thomas Goirand 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?

I guess many are trying to make the point that flooding the namespace
with various packages from the same ecosystem with very generic names,
makes life harder for all those people that are outside that ecosystem,
and that Debian is not only used by the people who are part of that
ecosystem.

In this openstack packages provided an example but it is in my opinion
something that does not only affect openstack. Take alien-hunter, with a
name that screams of video game and a description that would look like
white noise to anyone without a PhD in biochemistry.

If I was one of those who made an effort to come up with longer package
names, I would feel rather wronged by a flood of packages who did not
bother: it gives me a feeling like having worked hard to organise the
book in a library, then coming back from holidays to see that the
replacement librarian has just stashed all the returns in one single
formerly empty shelf close to their desk.

Some projects may have it harder than others to maintain a clean
namespace. Apache modules install themselves in /usr/lib/apache2/modules
and so can choose names in an apache-specific namespace, while
biochemistry packages install executables in /usr/bin and so even if
alien-hunter was called bio-alien-hunter, it would still not be
coinstallable with an alien-hunter videogame[1].

I do not know where openstack components install themselves; if they
install in /usr/bin stuff that is never meant to be run by the command
line, I think it would be more approriate to jump at the throat of
openstack upstreams rather than at that of the DDs who packaged it.

The package namespace, and the /usr/bin namespeace, are currently flat,
and flat namespaces[2] work bettter when participants try to keep to
some level of hygiene, and people who do not make an attempt to
coordinate with others give a feeling like those who jump the queue at
the bus stop.

It may be that the right solution is not to have a single namespace, and
to design things so that you cannot do videogames, openstack and
biochemistry research on the same system, and if one is not interested
in openstack/biochemistry/videogames, then one doesn't even get to see
the openstack/biochemistry/videogames packages and get confused by them.

I'm all for technical solutions to social problems.


Enrico

[1] this one specifc case probably would be coinstallable, because
alien-hunter installs an alien_hunter executable and so we would end
up with alien-hunter and alien_hunter, with the result that the
biochemist trying to identify horizontally acquired DNA by
predicting putative HGT events with IVOMs will find themselves
wondering where is the quit button and how to get that stupid game
out of full screen mode so it could be killed with -9 fire, and why
the hell did a game start in the first place.
[2] like the environment, and most shared spaces.
-- 
GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Re: Package naming rant

[Thomas Harding]

Le 21 avril 2016 23:23:49 GMT+02:00, Hubert Chathi  a écrit :
>On Thu, 21 Apr 2016 20:47:34 +, Aigars Mahinovs
> 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é.

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

Re: Package naming rant

[Hubert Chathi]

On Thu, 21 Apr 2016 20:47:34 +, Aigars Mahinovs  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  -- Jabber: hub...@uhoreg.ca
PGP/GnuPG key: 4096R/113A1368 https://www.uhoreg.ca/
Fingerprint: F24C F749 6C73 DDB8 DCB8  72DE B2DE 88D3 113A 1368

Re: Package naming rant

[Aigars Mahinovs]

On Thu, 21 Apr 2016, 21:58 Thomas Goirand,  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.

Re: Package naming rant

[Thomas Goirand]

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)

Re: Package naming rant

[Aigars Mahinovs]

On Thu, Apr 21, 2016 at 9:00 PM Hubert Chathi  wrote:

> On Thu, 21 Apr 2016 16:53:50 +, Aigars Mahinovs 
> 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.

Re: Package naming rant

[Hubert Chathi]

On Thu, 21 Apr 2016 16:53:50 +, Aigars Mahinovs  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  -- Jabber: hub...@uhoreg.ca
PGP/GnuPG key: 4096R/113A1368 https://www.uhoreg.ca/
Fingerprint: F24C F749 6C73 DDB8 DCB8  72DE B2DE 88D3 113A 1368

Re: Package naming rant

[Gunnar Wolf]

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.

Re: Package naming rant

[Aigars Mahinovs]

On Thu, Apr 21, 2016 at 6:47 PM Thomas Goirand  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.

Re: Package naming rant

[Thomas Goirand]

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)

Re: Package naming rant

[Ian Jackson]

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.

Re: Package naming rant

[Thomas Goirand]

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)

Re: Package naming rant

[Enrico Zini]

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 
glance: +admin::virtualization, +implemented-in::python, +interface::commandline, +role::program, +scope::suite, +suite::TODO, +suite::openstack, +use::storing, -special::not-yet-tagged
glance-api: +admin::virtualization, +implemented-in::python, +interface::daemon, +role::program, +scope::suite, +suite::TODO, +suite::openstack, -special::not-yet-tagged
glance-client: +implemented-in::python, +interface::commandline, +role::program, +suite::openstack, +system::cloud, -special::not-yet-tagged
glance-common: +devel::lang:python, +implemented-in::python, +role::shared-lib, +suite::openstack, -special::not-yet-tagged
glance-registry: +admin::virtualization, +hardware::storage, +implemented-in::python, +interface::daemon, +role::program, +suite::openstack, -special::not-yet-tagged
keystone: +admin::virtualization, +implemented-in::python, +interface::daemon, +network::server, +role::program, +suite::openstack, -special::not-yet-tagged
keystone-doc: +admin::virtualization, +hardware::storage, +suite::openstack, -special::not-yet-tagged
melange: +admin::virtualization, +implemented-in::python, +interface::daemon, +network::server, +role::program, +suite::openstack, -special::not-yet-tagged
nova-ajax-console-proxy: +admin::virtualization, +implemented-in::python, +role::program, +suite::openstack, -special::not-yet-tagged
nova-api: +admin::virtualization, +implemented-in::python, +interface::daemon, +network::server, +role::program, +suite::openstack, -special::not-yet-tagged
nova-common: +devel::lang:python, +implemented-in::python, +role::shared-lib, +suite::openstack, -special::not-yet-tagged
nova-compute: +admin::virtualization, +implemented-in::python, +interface::daemon, +network::server, +role::program, +suite::openstack, -special::not-yet-tagged
nova-compute-kvm: +admin::virtualization, +implemented-in::python, +interface::daemon, +network::server, +role::program, +suite::openstack, -special::not-yet-tagged
nova-compute-lxc: +admin::virtualization, +implemented-in::python, +interface::daemon, +network::server, +role::program, +suite::openstack, -special::not-yet-tagged
nova-compute-uml: +admin::virtualization, +implemented-in::python, +network::server, +role::program, +suite::openstack, -special::not-yet-tagged
nova-compute-xen: +admin::virtualization, +implemented-in::python, +interface::daemon, +network::server, +role::program, +suite::openstack, -special::not-yet-tagged
nova-console: +admin::virtualization, +implemented-in::python, +interface::daemon, +network::server, +role::program, +suite::openstack, -special::not-yet-tagged
nova-doc: +admin::virtualization, +hardware::storage, +suite::openstack, -special::not-yet-tagged
nova-network: +admin::virtualization, +implemented-in::python, +interface::daemon, +network::configuration, +network::server, +role::program, +suite::openstack, -special::not-yet-tagged
nova-objectstore: +admin::virtualization, +hardware::storage, +implemented-in::python, +interface::daemon, +network::server, +role::program, +suite::openstack, -special::not-yet-tagged
nova-scheduler: +admin::virtualization, +implemented-in::python, +interface::daemon, +network::server, +role::program, +suite::openstack, -special::not-yet-tagged
nova-vncproxy: +admin::virtualization, +implemented-in::python, +interface::daemon, +network::server, +role::program, +suite::openstack, -special::not-yet-tagged
nova-volume: +admin::virtualization, +hardware::storage, +implemented-in::python, +interface::daemon, +network::server, +role::program, +suite::openstack, -special::not-yet-tagged
nova-xcp-network: 

Re: Package naming rant

[Thomas Goirand]

On 04/18/2016 11:43 AM, Aigars Mahinovs wrote:
> 
> On Mon, Apr 18, 2016 at 11:27 AM Thomas Goirand  > 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)

Re: Package naming rant

[Elena ``of Valhalla'']

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''

Re: Package naming rant

[Justin B Rye]

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

Re: Package naming rant

[Aigars Mahinovs]

On Mon, Apr 18, 2016 at 11:27 AM Thomas Goirand  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.

Re: Package naming rant

[Thomas Goirand]

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