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)
