On 5/18/16 11:55 AM, Clint Byrum wrote: > Excerpts from Nikhil Komawar's message of 2016-05-18 11:03:45 -0400: >> On 5/18/16 2:15 AM, Clint Byrum wrote: >>> Excerpts from Robert Collins's message of 2016-05-18 14:57:05 +1200: >>>> On 18 May 2016 at 00:54, Brian Rosmaita <brian.rosma...@rackspace.com> >>>> wrote: >>>> >>>>>> Couple of examples: >>>>>> 1. switching from "is_public=true" to "visibility=public" >>>>> This was a major version change in the Images API. The 'is_public' >>>>> boolean >>>>> is in the original Images v1 API, 'visibility' was introduced with the >>>>> Images v2 API in the Folsom release. You just need an awareness of which >>>>> version of the API you're talking to. >>>> So I realise this is ancient history, but this is really a good >>>> example of why Monty has been pushing on 'never break our APIs': API >>>> breaks hurt users, major versions or not. Keeping the old attribute as >>>> an alias to the new one would have avoided the user pain for a very >>>> small amount of code. >>>> >>>> We are by definition an API - doesn't matter that its HTTP vs Python - >>>> when we break compatibility, there's a very long tail of folk that >>>> will have to spend time updating their code; 'Microversions' are a >>>> good answer to this, as long as we never raise the minimum version we >>>> support. glibc does a very similar thing with versioned symbols - and >>>> they support things approximately indefinitely. >>> +1, realy well said. As Nikhil said, assumptions are bad, and assuming >> You have only conveniently picked up one things I've said in my email, >> why not choose the other parts of resolving those assumptions correctly. >> Please do not phrase me when the propaganda is orthogonal to what I >> proposed. >> >>> that nobody's using that, or that they'll just adapt, is not really a >>> great way to establish a relationship with the users. >> It's not that assumption that users are not using it: >> >> The very _assumption_ people who are using it is that glance v1 is ok to >> be public facing API which was never designed to be one. So, that's the >> assumption you need to take into account and not the one you like to >> pick. That's the part where I talk about being engaged missing in your >> message. >> > It doesn't really matter what it was designed for, once something is > released as a public facing API, and users build on top of it, there > are consequences for breaking it. > > There's nothing personal about this problem. It happens. My message is > simple, and consistent with the other thread (and I do see how they are > linked): We don't get to pick how people consume the messages we send. > Whether in docs, code, mailing list threads, or even a room with humans > face to face, mistakes will be made. > > So lets be frank about that, and put aside our egos, and accept that
Again, like I keep mentioning in various emails, catching intent is hard on the ML. If you read the full email and not in pieces you will realize the point I make about being rational in the feedback. The problem is about speculation and not ego. Something I wanted to start as a result of my thread to prove a point and that's been achieved. The fallout is me merely making sure that Glance team stays happy. If a few glance-cores leave just because one user is unhappy, that's a big loss, for the entire community. Again, let's avoid speculation, keep maintaining rationality in our approach. Stay on topic, read the comments fully before replying. What someone consumes is not in our will, but whether we as a community appreciate such approache is. Let's keep that in mind. Being judicious in our communication is far more important than frank, wise feedback always improves, frank may not always do so. > mistakes were made _by all parties_ in this specific case, and nobody is > "mad" about this, but we'd all like to avoid making them again. If you have to work on something in openstack for a few years and that still remains unresolved for not necessarily the most convincing reasons, a large portion of the community is going to be mad. What you see is merely a oversight. > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Thanks, Nikhil __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
