On 05/11/2013 08:58 PM, Anne Gentle wrote: > > > > On Sat, May 11, 2013 at 6:43 PM, Monty Taylor <mord...@inaugust..com > <mailto:mord...@inaugust.com>> wrote: > > > > On 05/11/2013 05:48 PM, Anne Gentle wrote: > > > > > > > > On Sat, May 11, 2013 at 3:12 PM, Monty Taylor <mord...@inaugust..com > > <mailto:mord...@inaugust.com <mailto:mord...@inaugust.com>>> wrote: > > > > > > > > On 05/11/2013 04:07 PM, Asher Newcomer wrote: > > > Or even better, just continue to call it openstack > networking. The > > code > > > names only serve to confuse the uninitiated. They needlessly > > steepen the > > > learning curve and slow uptake. > > > > The problem with OpenStack Networking (or getting rid of > codenames) is > > seen with pre-incubation->incubation->integrated cycle. > > > > A project cannot call itself "OpenStack Foo" until it actually > _is_ > > openstack foo. So any new project by necessity has to start off as > > something else. > > > > But - if we then require them to drop that name and become > openstack foo > > when they become incubated or integrated, then we've got > what's become a > > stable project with a decent amount of contributors renaming > itself. > > > > Every. Time. > > > > The code names aren't just cute. I kind of wish they were, > because it > > would make several things much easier if we could just ditch > them and do > > a pure openstack. code namespace. But the reality is that it > gets really > > really tricky to deal with a bunch of things if they go away. > > > > > > I told Monty and the TC this at the Summit (sorry I couldn't > attend the > > session about code names). > > I promise, it wasn't the world's most fun session. :) > > > I'm sure. :) I think I don't have much regret but do feel sorry that I > don't know more. > > > > > I find this trickiness a weak argument in the > > face of the invented names that are getting to be as bad as U.S. > > pharmaceuticals. Plus it forces us to put a "lookup" table in the docs > > forever. [1] Let's find a process for naming that meets a few reqs: > > - describes the service > > - goes through a legal review > > - enables new eyes to understanding it by reading the English word > that > > the service represents (that can be translated into a meaningful > word in > > other languages) > > I don't think it's a weak argument at all. There are real technical > issues. > > > The technical issues, to me, and I may be missing something, are when > the name is used as: > - service/daemon name > - command/CLI name
And the directories in the code where those things live, and the name of the python package that gets installed, and the name of the client library used to connect to it. > You can use any pet name you want for your team and project while > addressing technical issues some other way? > > Here's another way I'm looking at the naming autonomy/process. Why > incubate? > - you get to pick your cool name > OR > - you get access to infrastructure, tools, events, community, and > branding that is OpenStack > > The naming can't be THAT crucial. I get that we want projects to be fun > to work on. But it can't be just the naming that brings the fun. I don't think "having a cool name" is interesting or important at all. Not one little bit. If any part of this was about esprit de corps or team bonding or identity I'd be 100% on board with the no-codenames approach. Also, to be clear, I don't think there are any problems with using non-codename for identification. Already, as part of the upgrade of our build stuff to PBR I've been setting the project short description to the non-codename. So, nova's is "OpenStack Compute" I think that's a great idea, and it's important. Equally as important, although harder, is that we should all try our best to use the non-codenames when we're talking about official projects. It's not going to work or be 100% covered - but we should all make a best-effort. (these are all things that did come out of that session - perhaps one of us should do a writeup on that?) The thing that _I'm_ sticking on is the above list of technical issues. What is the daemon named? What is the command line tool named? What is directory in which the code lives? Those may seem trivial, but those are the primary interface that a developer and deployer has with the project. And it's an issue because of the lifecycle of these code projects before they are integrated. It's not ok for moniker to call it's API daemon "openstack-dns-api" until it's actually openstack DNS. It has to call itself something though. That's where names come in. It's a practical thing that there must be a name. And let's be honest - it's my least favorite part of making a project. So much so that our CI project which makes jenkins jobs from yaml files is called "jenkins-job-builder" and the tool we use to manage our projects in gerrit/github and launchpad is called jeepyb - which is a phonetic re-working of "G P B" which stood for Gerrit Project Builder. Shoot me now. There's another rub with descriptive names. Jenkins Job Builder has become WILDLY successful. People use it all over the place in areas completely unrelated to OpenStack. I believe there's a guy on an oil rig somewhere who is not only using it, but contributes patches. It's great. AND ... a couple of weeks ago Jim and I met one of the guys from the Eclipse Foundation... You may not be aware, but the original codebase for Jenkins was called Hudson, and it was a Sun project. When Oracle bought Sun, the screwed it up like they screw up just about everything Open Source, so the core team left, forked it, and many of us, including OpenStack, followed the Jenkins fork. (If you've ever wondered why you get messages from jenkins under the email name of "OpenStack Hudson" - that's why - we haven't ever renamed the original hudson service account) In any case, Oracle finally realized that they didn't know what they hell they were doing, so they gave hudson to the Eclipse foudation... which brings us back to - Jim and I and the guys from wikipedia and the guys from Eclipse are going to have a talk about how we can all work together better ... turns out Eclipse already uses gerrit too. We'll tell them all about the things we've built that make things work smoothly - like Zuul and Jenkins Job Builder. Oops. Jenkins Job Builder. That's going to be awkward. Zuul will be fine - it reads gerrit event stream and makes jenkins API calls. Hudson has the same calls, it should just work. Jenkins Job Builder creates xml snippets. It SHOULD just work technically - but we're going to wind up asking the guys running the hudson project to use "Jenkins Job Builder" to manage their CI. Naming is important - and not for cute hipster reasons. There are real logistical challenges that a unique non-descriptive name help with. There's a reason that Ivory doesn't just call itself "Pure White Soap" Our brains process pattern and names in a peculiar manner, and it helps us to communicate specifically. We also none of us have problems dealing with made up word names - we've got 13 years of dot-com era dopplr and yelp and bing and iphone and whatnot. It's not a problem. One of the things that IS an interesting intersection of problems here is actually the real issue. It's not that short names are bad for any technical reasons. It's that they're potentially problematic from a legal perspective, but there is no avenue for us to engage with that in a way that is consistent with our community values. We, from the beginning, and to this day, spend a MASSIVE amount of effort in doing everything in the open, because Open Process and Open Governance are just as important to a community as Open Source is. This, however, it turns out, is directly at odds with just about everything of how corporate entities work. We've way more meta-discussion at the board meetings about the need for our private executive sessions. We don't like it, but there are times that for legal reasons we actually HAVE to not do some things publicly. I think it's crap and one more way in which the man is trying to keep us down, but it is a fact of life. Why do I think that's relevant? It's because we don't get the benefit of private codenames for work and then public marketing names. Rackspace Cloud Servers internally is called Ozone, am I right? Cloud Files was called Swift before it was part of OpenStack. And it still is. Our problem is directly related to our value - which is that we market ourselves directly through telling people they can look at our code. That means that as much as we can have a project called swift that the business folk call OpenStack Object Storage - there is no escaping the fact that the technical folk are going to talk about it as swift in their technical conversations. In fact, we've done such a good job as a technical meritocracy that people consider our non-marketing/non-business choices as marketing/business actions - and they consider them potential grounds for lawsuits. So we're going to have this problem. It's not going to go away - because we're doing something different, and we're doing it in a way that isn't compliant with the box that the world wants to put us in. In theory, it should be hurting adoption for us to have 18 different projects with completely un-understandable names. I'm pretty sure that the last couple of summits have shown that, of the problems we have, that is not one of them. There is one more problem with coupling the technical part of the project to the branding - and that's one from the opposite side of incubation. What if we eject a project? What if the TC decides to get together and say "you know what? We don't think swift has enough production deployments at scale (hahaha) and doesn't meet our criteria for a good OpenStack project. Monty and Jim wrote a shell script that stores objects in mercurial. Mercurial is in python. We want to use that for OpenStack Object Storage instead." Now what? Does swift have to rename their project again? If they decide "cool, we don't need you, we're going to continue life as part of the Eclipse foundation" - do they need to rename the innards of their project from openstack/storage/object back to swift? Which law forces them to do that? Because I'm pretty sure that would be trademark. That would mean that we'd have a non-free trademark usage policy concerning forks - which would make us DFSG incompatible which would mean that Debian would stop shipping us. I would really like to keep our trademark out of our source code, because it opens a giant can of worms. I would really like to keep the marketing/business folks out of our source code. Most importantl, I would really like to keep the lawyers out of our source code. Occasionally this means we're going to get stuck, like with Quantum, and we're going to need to do a project name change. Ok. I think we've now learned that we as technical people have GOT to check more than just "is the project name available on github/launchpad/debian/redhat and pypi" - cause we already do that. We should do things like "does a quick google search of my project name and core elements of it return, you know, a business." I mention our erstwhile nascent DNSaaS project as an example of pre-incubation... hopefully someone in that project will do the thing I just mentioned and will come to us at incubation time with a name that is not a CLEAR violation. I mean, we can't be perfect, but we can at least try. Because if we try, then it keeps the lawyers out of our business - and that's really better for all of us. > I think you believe I have some strict naming process in mind, so I'm > trying to explain my position more. > > It's more that I believe we can have team/project names without naming > technical things (repositories, CLIs) with that "cool/fun" name. > > Go with kumquat, but don't call the CLI kumquat. Call your team kumquat > and your repo kumquat. > > That assumes that OpenStack is involved with the project pre-incubation. > That's was the case with Quantum and Ceilometer and Ironic. On the other > hand, the heat folks had heat-api.org <http://heat-api.org> and a > heat github org and other > things before they started down the stackforge road. Looking right now > at non-incubated projects just off the top of my head: > > Libra is an LBaaS solution that was started on stackforge and which it's > increasingly unlikely will go to incubation rather than just atttempt to > merge stuff in with Quantum LBaaS. Moniker is a DNSaaS that hasn't > applied for incubation, might do so, but as of right now has been around > for almost a year yet has no formal relationship with OpenStack. > healthnmon may or may not be an incubation candidate. > > Before that, reddwarf was not-incubated for pretty much the entire time > OpenStack has existed until just now. > > All of these things have had to have lifecycles during a period of time > before they have any interaction with us formally. > > On the other hand, if we did checking pre-incubation, we'd be in a very > odd position of granting permission/blessing/tentative interest in > projects before they come close to sorting things out. Moniker is great, > but 6 months ago there were as many as 4 different DNSaaS possibilities. > > In any case, I don't think there is any way that we can, become directly > involved in projects before they are incubated. > > Stackforge helps already, in that moniker is stackforge/moniker rather > than openstack/moniker. But neither has any effect on the fact that > there is a directory named "moniker" in moniker repository. If we go > with 'descriptive' names, then there are two choices: > > a) moniker starts life with a directory structure underneath > openstack/dns inside of its repository, even though it is not an > openstack project. > > b) moniker starts life with a moniker directory, and then when > incubated, renames that directory from moniker to openstack/dns. > > > Yeah I'm not too concerned with repository names, though I do understand > the need for uniqueness there. We incubate for a reason, to experiment a > bit. In that experimentation I hope projects are considering their users. > > > We can't stop anybody from doing (a) of course, but let me tell you - > you wanna talk about confusing and bad messaging - we had apt repos at > the beginning of the project with giant letters on them "FOR TESTING > ONLY" but because they had our name on them people assumed we supported > them. > > (b) sound easy, until you reckon with things like line-wrapping changes, > sort order changes, and client library/API consumption changes. If > something is using python-monikerclient and thus the monikerclient > namespace of the API, that person would have to port their code to now > do something like openstack.dns.client or similar. > > > I totally get how hard the CLI work is. But what I don't get is why a > unique name that is meaningless is so valuable? > > > Even ignoring people who may have already been using the code (many of > these things start life as a service by one of our member companies and > then enters incubation when it's become baked a little bit - reddwarf > was in production at RAX and HP before it got incubated, moniker is in > production at HP, etc) and just focusing on our own code base, the > massive undertaking that it is to change the name of the project inside > of the project is daunting enough that we're still talking about it for > Quantum. > > Don't get me wrong - I totally hear you on the matrix of what-does-what, > and obviously there are legal naming issues- I'm not trying to be > insensitive to them - this is a crap position to be in. But so far, I > haven't heard an actual proposal on how we deal with a model other than > our current one - and when I say that, I mean a _detailed_ plan that > takes in to account all of the various things we know right now that we > will run in to. How do we do X, and then how do we deal with Y and what > is the process and timing we use to deal with Z. We have a massively > complex project, and as much as I would like for this question to be > simpler in its solution, it simply is not. > > At the moment, absent a concrete proposal for the process change that > would necessarily ensue from ditching code names, I believe we're stuck > in the not-great but not-any-worse-than-current situation of having > potentially infringing names. For our current names, well, we're dealing > with that as best we can. For future incubation requests, we are now > raising the name as a question - which means that we can tell people > that we are going to be doing that, which means that projects that are > not careful and do not pick a trademark friendly name may have to go > through a rename if they hit a problem ... but it's also possible with > care that renames can be avoided. > > > I'd love to work on a concrete proposal (thanks to Davanum for the > podling page, that's useful). I'm okay with digging into the work we > have to do here as it has worthwhile outcomes. > > > > If we have to preface with Stackforge to indicate pre-incubation, > that's > > fine. Use Incubating or some such to indicate incubation. Meaningful > > words have meaning. > > Once it's incubating, it's in our world - we, as a body, have made a > choice that it's a thing we want to be involved with, pending the > technical things working out. I don't think we have any deficiencies > there at the moment. > > > I acknowledge we still have to indicate what commands, daemon > names, and > > so on are related to a particular service. That issue is also fixable > > with some resources and effort and pays off in easier adoption and > > understanding. > > It's entirely possible that after all of that text above, we are talking > about completely different things when we talk about naming here. I love > meta discussions... > > > Does some further explanation help? Yours is so nice and eloquent, I > feel a bit intimidated. :) It's not that I'm backing off either, but > trying to get to the heart of my concerns/questions with naming. > > Thanks for the meta Monty! > Anne > > > > 1.. > > http://docs.openstack.org/grizzly/openstack-compute/install/yum/content/terminology-codenames.html > > > > > > > > > On May 11, 2013 3:59 PM, "Davanum Srinivas" > <dava...@gmail.com <mailto:dava...@gmail.com> > > <mailto:dava...@gmail.com <mailto:dava...@gmail.com>> > > > <mailto:dava...@gmail.com <mailto:dava...@gmail.com> > <mailto:dava...@gmail.com <mailto:dava...@gmail.com>>>> wrote: > > > > > > Lattice > > > > > > -- dims > > > > > > On Sat, May 11, 2013 at 3:52 PM, Mark Turner > <m...@amerine.net <mailto:m...@amerine.net> > > <mailto:m...@amerine.net <mailto:m...@amerine.net>> > > > <mailto:m...@amerine.net <mailto:m...@amerine.net> > <mailto:m...@amerine.net <mailto:m...@amerine.net>>>> wrote: > > > > Tubes > > > > > > > > ;-) > > > > > > > > > > > > On Sat, May 11, 2013 at 12:51 PM, Jason Smith > > > <jason.sm...@rackspace.com > <mailto:jason.sm...@rackspace.com> <mailto:jason.sm...@rackspace.com > <mailto:jason.sm...@rackspace.com>> > > <mailto:jason.sm...@rackspace.com > <mailto:jason.sm...@rackspace.com> <mailto:jason.sm...@rackspace.com > <mailto:jason.sm...@rackspace.com>>>> > > > > wrote: > > > >> > > > >> Hello, > > > >> I understand why we had to give up Quantum code name > but rather > > > than just > > > >> refer to it as networking let's come up with a new > code name! > > > >> > > > >> Thoughts? > > > >> > > > >> Thanks, > > > >> -js > > > >> _______________________________________________ > > > >> Mailing list: https://launchpad.net/~openstack > > > >> Post to : openstack@lists.launchpad.net > <mailto:openstack@lists.launchpad.net> > > <mailto:openstack@lists.launchpad. > <mailto:openstack@lists.launchpad.>.net> > > > <mailto:openstack@lists.launchpad.net > <mailto:openstack@lists.launchpad.net> > > <mailto:openstack@lists.launchpad.net > <mailto:openst...@lists..launchpad.net>>> > > > >> Unsubscribe : https://launchpad.net/~openstack > > > >> More help : https://help.launchpad.net/ListHelp > > > > > > > > > > > > > > > > _______________________________________________ > > > > Mailing list: https://launchpad.net/~openstack > > > > Post to : openstack@lists.launchpad.net > <mailto:openstack@lists.launchpad.net> > > <mailto:openstack@lists.launchpad.net > <mailto:openstack@lists.launchpad.net>> > > > <mailto:openstack@lists.launchpad.net > <mailto:openstack@lists.launchpad.net> > > <mailto:openstack@lists.launchpad.net > <mailto:openst...@lists..launchpad.net>>> > > > > Unsubscribe : https://launchpad.net/~openstack > > > > More help : https://help.launchpad.net/ListHelp > > > > > > > > > > > > > > > > -- > > > Davanum Srinivas :: http://davanum.wordpress.com > > > > > > _______________________________________________ > > > Mailing list: https://launchpad.net/~openstack > > > Post to : openstack@lists.launchpad.net > <mailto:openstack@lists.launchpad.net> > > <mailto:openstack@lists.launchpad.net > <mailto:openstack@lists.launchpad.net>> > > > <mailto:openstack@lists.launchpad.net > <mailto:openstack@lists.launchpad.net> > > <mailto:openstack@lists.launchpad.net > <mailto:openstack@lists.launchpad.net>>> > > > Unsubscribe : https://launchpad.net/~openstack > > > More help : https://help.launchpad.net/ListHelp > <https://help.launchpad..net/ListHelp> > > > > > > > > > > > > _______________________________________________ > > > Mailing list: https://launchpad.net/~openstack > > > Post to : openstack@lists.launchpad.net > <mailto:openstack@lists.launchpad.net> > > <mailto:openstack@lists.launchpad.net > <mailto:openstack@lists.launchpad.net>> > > > Unsubscribe : https://launchpad.net/~openstack > > > More help : https://help.launchpad.net/ListHelp > > > > > > > _______________________________________________ > > Mailing list: https://launchpad.net/~openstack > > Post to : openstack@lists.launchpad.net > <mailto:openstack@lists.launchpad.net> > > <mailto:openstack@lists.launchpad.net > <mailto:openstack@lists.launchpad.net>> > > Unsubscribe : https://launchpad.net/~openstack > > More help : https://help.launchpad.net/ListHelp > > > > > > _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp