20:01:18 <jbryce> #startmeeting
20:01:19 <danwent> o/
20:01:19 <openstack> Meeting started Tue Jun 12 20:01:18 2012 UTC.  The chair is jbryce. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:35 <jbryce> 6 of us...one more around?
20:01:44 <chmouel> notmyname is not able to attend today so I will be giving the swift update for him
20:01:52 <bcwaldon> chmouel: wrong meeting!
20:02:01 <jk0> o/
20:02:06 <ttx> chmouel: one more hour to wait :P
20:02:16 <jbryce> devcamcar, heckj, vishy: around at all?
20:02:20 <chmouel> hey :)
20:02:24 <bcwaldon> vishy and anotherjesse are out
20:02:59 <jbryce> well jk0 makes 7 so we can get started
20:03:05 <mtaylor> don't count me ...
20:03:16 <mtaylor> I'm not a member any more - i'm merely a petitioner today
20:03:21 <jbryce> oops...habit
20:03:36 <jbryce> pvo: ?
20:03:36 <ttx> jaypipes is your man
20:03:44 <jaypipes> hello.
20:03:54 <jaypipes> sorry for being late.
20:03:55 <jbryce> sweet
20:04:12 <jbryce> #topic Library/Gating projects
20:04:16 <jbryce> http://wiki.openstack.org/Governance/Proposed/LibraryProjectDefinition
20:04:28 <jbryce> ttx or mtaylor: want to intro this oen?
20:04:29 <jbryce> one
20:04:39 <ttx> I can intro and let mtaylor elaborate
20:04:39 <mtaylor> yeah
20:04:44 <mtaylor> or ttx can
20:04:54 <heckj> o/
20:04:58 <ttx> I'll do the historic intro
20:05:18 <ttx> For client library projects we've always been a bit in between states
20:05:47 <ttx> when they got split out of their "parent" project we decided that they would retain core status...
20:06:00 <ttx> ... by being considered another deliverable of the same project
20:06:06 <ttx> so same PTL, but also same release date
20:06:18 <ttx> and same project in Launchpad, so same bugtracker
20:06:36 <ttx> This creates a number of problems, so now is probably the time to change
20:06:44 <ttx> mtaylor: go for it
20:07:06 <mtaylor> so what we'd like to do, as I've written up above with a bunch of chatting with bcwaldon and ttx
20:07:28 <mtaylor> is to divorce the release of the client libs from the normal release process a bit
20:07:38 <mtaylor> and just release them whenever they need a release
20:08:04 <mtaylor> in general, we seem to be in general agreement that any given version of a client lib should support both the current and the previous versions of the api
20:08:13 <jaypipes> ++
20:08:28 <danwent> mtaylor: how far back?  do we have a strategy for EOL-ing API versions?
20:08:34 <ttx> took us a while to come up with somethign that we would both agree with
20:08:46 <mtaylor> danwent: well, at the moment as far back as essex, because diablo is problematic
20:08:51 <mtaylor> but, I'd argue indefinitely, tbh
20:08:56 <bcwaldon> mtaylor: 'essex' is not an api version
20:09:03 <mtaylor> you can still use libmysqlclient to talk to v1.0 mysql if you can find a v1.0 mysql
20:09:18 <mtaylor> bcwaldon: sorry. v2 and on, since v1 didn't have a fully impl, right?
20:09:27 <bcwaldon> mtaylor: are you talking about compute api?
20:09:34 <danwent> mtaylor: but there's definitely a maintenance burden to supporting all API versions.
20:09:47 <jaypipes> mtaylor: compute 1.1 api was renamed to 2
20:10:08 <mtaylor> danwent: that there is - so I'm purely talking about theory - I think we probably do want to think about an EOL policy for practicality sake
20:10:24 <bcwaldon> hold on meow, mtaylor, do you have anything else to say w.r.t. explanation, or can we move forward with feedback?
20:10:24 <danwent> I'd like to remove support for Quantum v1.x APIs fairly agressively… maybe even in Folsom.
20:10:34 <mtaylor> but, the thing is - thinking about it from an end user's perspective, if they hear "my cloud provider is running openstack" -
20:10:39 <danwent> bcwaldon: good point, i'll hold off :)
20:11:05 <mtaylor> then it really should be enough for them to just grab the openstack library and be assured that they can talk to that cloud
20:11:18 <ttx> the discussion on deprecation doesn't really affect the proposed plan anyway
20:11:20 <mtaylor> without having to know whether or not the provider is running essex or garbanzo
20:11:26 <mtaylor> it actually doesn't
20:11:40 <mtaylor> well, it does a LITTLE
20:11:49 <mtaylor> so- amongst the points are:
20:12:01 <ttx> the question at hand is about the creation of new categories of projects to cover for a separate release scheme for client library projects
20:12:21 <ttx> and additionally recognize gating projects as a category of openstack projects as well
20:12:25 <mtaylor> indeed. sorry, I got caught up in technical details :)
20:12:27 <danwent> ttx: ok, let's talk about that first, then we can circle back to backward compat questions.
20:12:34 <ttx> separate from our strict definition of "core"
20:12:35 <heckj> mtaylor, ttx: what are the problems this is triyng to solve? ttx referred to problems that have come up…
20:12:57 <mtaylor> a couple - one of them is the branching problem
20:13:04 <ttx> heckj: on my side, I'd say pressure to release cleint libraries at other moments that openstack core releases
20:13:15 <ttx> than*
20:13:24 <mtaylor> in that a stable/essex branch of python-*client doesn't make any sense from a release perspective for an end user
20:13:28 <mtaylor> the other being what ttx just said
20:14:04 <markmc> mtaylor, why not a stable/essex branch? it's what essex distros would ship
20:14:23 <mtaylor> markmc: say you're a customer of rackspace or hp
20:14:24 <ttx> additionally, sharing bugtracker is actaully a bit of pain that we'd remove :)
20:14:29 <mtaylor> or ibm or at&t
20:14:32 <pvo> jbryce: here now.
20:14:43 <mtaylor> and you'd like to talk to instances in your cloud account
20:14:50 <mtaylor> what version of the library should you install?
20:15:08 <mtaylor> additionally, what if you have an account on rackspace AND hp AND at&t
20:15:08 <heckj> mtaylor: I'm not getting the "a stable/essex branch of python-*client doesn't make any sense from a release perspective for an end user"… why doesn't it make sense?
20:15:10 <ttx> for the late arrivals, we're discussing http://wiki.openstack.org/Governance/Proposed/LibraryProjectDefinition
20:15:21 <mtaylor> and you would like to have a script which operates on all of those clouds
20:15:28 <mtaylor> (such as the devstack gating scripts)
20:15:47 <mtaylor> do you suggest that I should install two different versoins of python-*client to talk to the different clouds?
20:15:49 <markmc> mtaylor, you might need to e.g. wait until Fedora 18 before being able to talk to a folsom based cloud provider
20:16:00 <jaypipes> heckj: have you ever downloaded the "stable/whatever" version of libmysqlclient? :)
20:16:05 <mtaylor> markmc: I'm installing from pypi
20:16:13 <markmc> mtaylor, I'm giving the distro perspective
20:16:13 <jaypipes> heckj: or have you downloaded the libmysqlclient0.15?
20:16:13 <jbryce> heckj: i think because the clients are talking to APIs not a specific version of the implementation
20:16:18 <mtaylor> markmc: I know
20:16:34 <mtaylor> markmc: I'm giving the "end user wants to talk to service" perspective
20:16:50 <mtaylor> which I battle with every day as a very large customer of both hp and rackspace clouds :)
20:16:54 <markmc> mtaylor, right, but both might be an option - stable/essex branch and more regular releases from master
20:17:13 <heckj> jaypipes, mtaylor: then it's the same issue that Thierry is asserting - we'd like to have client library release versioned independently of the core projects, and not assert dependence on client library to core version
20:17:26 <mtaylor> heckj: yes
20:17:35 <jaypipes> heckj: exactly.
20:17:39 <jbryce> markmc: but it's not essex from a client perspective, it's api v X
20:18:01 <jbryce> which may or may not be different in essex from diablo or folsom
20:18:20 <jaypipes> heckj: and the clients would be named not stable/essex, but python-glanceclient-2.x.x
20:18:41 <jaypipes> heckj: with the number representing the last version of the API they speak to.
20:18:52 <ttx> fwiw I was defending the same view as markmc until recently, but the idea of versioning client libraries by API support... and have pure <= backward compat makes the need for stable/* go away... and not having them simplifies versioning wrt PyPI publishing a lot
20:19:00 <jbryce> that's pretty appealing to me from a user perspective
20:19:16 <johnpur> jbryce: agree
20:19:27 <bcwaldon> I do want to bring up that it doesn't work 100% to version clients to match api versions directly
20:19:32 <mtaylor> it means we'll need stronger back-compat testing than we have, but that's on our todo list
20:19:39 <mtaylor> bcwaldon: why not?
20:19:40 <jaypipes> bcwaldon: just the major API version..
20:19:46 <heckj> I just updated http://wiki.openstack.org/Governance/Proposed/LibraryProjectDefinition to add the list of problems that we're solving with this proposal
20:19:47 <mtaylor> yeah- just major version
20:19:49 <bcwaldon> jaypipesThe versioning needs to belong to the library -- what if we need to rewrite a client lib without changing supported versions?
20:20:02 <heckj> bcwaldon: +++
20:20:10 <jaypipes> bcwaldon: then the minor/revision numbers would change.
20:20:13 <mtaylor> bcwaldon: so, I'd say that the Major of the client lib matches the major of the api
20:20:19 <bcwaldon> and what does it mean to release glanceclient v2, then add a bugfix for v1 support
20:20:23 <bcwaldon> jaypipes: that versioning is insane
20:20:28 <bcwaldon> mtaylor: no
20:20:43 <markmc> I guess I mean "stable releases of the v2 glance client"
20:20:44 <mtaylor> bcwaldon: I would argue that the major of the client lib is the contract assertion "I support X and earlier"
20:20:54 <markmc> i.e. safe fixes to the v2 API support
20:20:58 <bcwaldon> but that version represents the librarary, not itscapabilities!
20:21:05 <jaypipes> bcwaldon: you'd still increment the minor (or revision) number... it's a fix in the v1 area for the client that supports v2
20:21:06 <bcwaldon> what other projects do that?
20:21:12 <markmc> adding v3 support does not qualify as a safe update to the v2 client
20:21:16 <mtaylor> bcwaldon: every C library that versions itself sensibly
20:21:22 <jaypipes> bcwaldon: every C library I know.
20:21:23 <heckj> I'm 100% with bcwaldon here - the versioning of the library needs to be independent of it's capabilities. The whole point is to break this away from dependence on core project releases.
20:21:25 <mtaylor> bcwaldon: standard libtool versioning
20:21:43 <bcwaldon> I'm not a C developer, so I don't have that bias
20:21:49 <bcwaldon> or experience, however you want to say it
20:21:50 <mtaylor> no, the version of the library is only meaningful as an API contract assertation
20:22:03 <jbryce> i think the version is actually very easy to understand and pretty consistent with most server/client libs that i've seen
20:22:11 <bcwaldon> jbryce: example?
20:22:17 <ttx> jbryce: ++
20:22:22 <jbryce> we've already talked about mysql
20:22:29 <bcwaldon> I agree it's EXTREMELY obvious, but then we lose the versioning of the library itself
20:22:30 <jbryce> postgres
20:22:37 <jbryce> bcwaldon: how?
20:22:41 <jbryce> bcwaldon: did you read the proposal?
20:22:47 <bcwaldon> jbryce: ...yes
20:22:50 <jbryce> bcwaldon: there is versioning of the library itself
20:22:57 <jbryce> bcwaldon: all the other numbers
20:23:01 <ttx> fwiw mtaylor proposed pure numbers as versions (1...2..3...) but I really thought that linking them to supported APi versions would make it a lot more meaningful
20:23:14 <bcwaldon> so let me post this case to you
20:23:23 <markmc> mtaylor, libtool versioning is independent of project release versioning
20:23:35 <bcwaldon> if I want to completely rewrite my library, I'll probably increment the major version to indicate that
20:23:40 <jaypipes> markmc: not project release. API version.
20:23:44 <mtaylor> markmc: yes. that's what's great about it
20:23:51 <bcwaldon> if I completely rewrite glanceclient, I can't tell anybody about it!
20:23:57 <jbryce> bcwaldon: why? i don't have that bias...or experience
20:23:58 <devcamcar> o/
20:23:59 <devcamcar> made it finally
20:24:02 <mtaylor> bcwaldon: why would they care?
20:24:06 <jbryce> mtaylor: ++
20:24:15 <bcwaldon> mtaylor: as a developer, I care a LOT
20:24:17 <mtaylor> bcwaldon: why would I, as a consumer of the library and its api, care if you rewrote it?
20:24:21 <mtaylor> bcwaldon: you shouldn't
20:24:23 <jbryce> versions are useful for the meaning we put in them
20:24:27 <mtaylor> either it works when you call its api or it doesn't
20:24:29 <bcwaldon> mtaylor: do you care if you hav epython 2.6 vs 2.7?
20:24:35 <mtaylor> bcwaldon: I care if the api changed
20:24:47 <mtaylor> bcwaldon: I do not care if guido rewrite string.strip()
20:24:53 <jaypipes> right.
20:24:56 <mtaylor> as long as it behaves the same
20:24:56 <bcwaldon> mtaylor: I think you should
20:24:59 <mtaylor> bcwaldon: no
20:25:00 <mtaylor> actually
20:25:05 <mtaylor> that's why apis are awesome
20:25:06 <bcwaldon> mtaylor: maybe not *you*, but you should be able to
20:25:07 <mtaylor> I don't have to know
20:25:10 <ijw> What if you changed the Python side of the calling interface but it still works with over-the-wire API v2?
20:25:16 <bcwaldon> great point
20:25:25 <mtaylor> ijw: I would argue that you can't do that
20:25:31 <bcwaldon> mtaylor: and thats where you lose me
20:25:35 <markmc> of course you care if an implementation is a compatible rewrite of the same API
20:25:35 <mtaylor> add a new interface
20:25:40 <bcwaldon> mtaylor: if you want to tie my hands, I guess you can
20:25:42 <bcwaldon> mtaylor: but I will disown you
20:25:44 <markmc> we cared about ksl being a rewrite of the same API
20:25:47 <jbryce> versioning schemes have whatever meaning we give to them
20:25:53 <mtaylor> so, you might have 10000s of devs using your lib
20:25:54 <bcwaldon> markmc: +1 million
20:26:02 <mtaylor> do you want to make them rewrite all of their code just because you had a whim?
20:26:05 <mtaylor> that's crazy
20:26:07 <bcwaldon> jbryce: and I want to assign the most sane versioning
20:26:08 <ttx> bcwaldon: I see your point. API-based versioning doesn't let you "show" that you made a major rewrite of the lib if it supports the same APIs
20:26:20 <bcwaldon> ttx: yes
20:26:28 <ttx> The proposed plan supposes a bit of stability in the client libs
20:26:33 <bcwaldon> ttx: and major versions are supposed to indicate backwards incompatibile changes
20:26:43 <bcwaldon> or at least allow it
20:27:00 <markmc> minor versions indicate a large, potentially risky update
20:27:03 <heckj> bcwaldon: I think the idea here (re-reading the proposal) is that the first number is intended to indicate the API compatibiity, the second, third, etc - are whatever the client wants to use for it's versioning
20:27:08 <markmc> micro versions indicate a safe update
20:27:20 <bcwaldon> heckj: I know what the proposal is
20:27:47 <jbryce> heckj: exactly
20:27:48 <ttx> bcwaldon: would a era.api.revision numbering work better for you ?
20:27:55 <jbryce> again...the version means whatever we want it to mean
20:27:59 <ttx> instead of api.revision ?
20:28:03 <heckj> bcwaldon: so for example 2.5 getting a core API rewrite could go to 2.6?
20:28:29 <heckj> ^^ that made no sense as a sentence
20:28:30 <uvirtbot> heckj: Error: "^" is not a valid command.
20:28:38 <bcwaldon> ttx: I dont really want 'api version' in my versioning scheme
20:28:38 <mtaylor> heckj: :)
20:28:48 <mtaylor> ok. can I propose something then?
20:28:49 <heckj> doing a rewrite of the client library but supporting the same API would do something like go from 2.5 to 2.6
20:28:52 <ttx> bcwaldon: I'd argue that's a bit developer-centric
20:28:54 <bcwaldon> mtaylor: shoot
20:28:58 <ijw> The significance of the code version number isn't so much a significance of the number of lines of code changed.  It's more an indicator of what reported bugs apply to the version you're looking at.
20:28:59 <mtaylor> can we table the exact versioning scheme discussion for later
20:29:17 <mtaylor> and get through the "we should release these in this general manner" bit for now
20:29:18 <ttx> yes, it's actually not the core of the proposal either ;)
20:29:23 <jbryce> ttx: ++ personally i hope we have far more users than developers...otherwise we're all going to be in a tough place
20:29:29 <mtaylor> and then we can circle back on what the major number should mean or not mean
20:29:36 <jbryce> mtaylor: good idea
20:29:39 <mtaylor> because I TOTALLY hear your point
20:29:48 <bcwaldon> okie dokie
20:29:57 <mtaylor> and I've got a slightly different one that I think we can sit down and work through so that we're both happy :)
20:29:59 <ttx> the cenrtal part of the proposal is:
20:30:29 <ttx> * Agree on a category of "openstack" project that is separate from core (which is the servers that get released every 6 months)
20:30:39 <ttx> * Agree that those could be released separately
20:31:01 <johnpur> I think that any developer will need to read the "doc" README etc. prior to using a particular library to see if his app will be compatible with the target system. To some extent the actual versioning numbers have little meaning to me as a dev, except as a starting point perhaps
20:31:05 <ttx> Then the secodn part is the abandon of stable/* branches and pure backwards compat
20:31:10 <ttx> Then versioning
20:31:18 <ttx> Then deprecation of API
20:31:31 <jbryce> ok
20:31:38 <johnpur> ttx: agree
20:31:52 <ttx> I think the versioning discussion is actually not that important once you agree on the "second part"
20:31:52 <jbryce> is the vote bot running?
20:32:02 <jaypipes> jbryce: should be.
20:32:13 <ttx> it's more what is obvious by the version number and what is documented
20:32:22 <Daviey> /win 286
20:32:31 <ttx> Does anyone have objections on the central part of the proposal
20:32:42 <bcwaldon> negative
20:32:42 <ttx> The idea that there are openstack projects that are not core projects.
20:32:49 <jaypipes> no objections.
20:32:49 <jbryce> not here
20:32:53 <ttx> Libraries and Gating projects
20:33:00 <jaypipes> notmyname: thoughts?
20:33:05 <jbryce> jaypipes: he's out today
20:33:07 <ttx> that we stronglmy depend on to build core projects anyway
20:33:08 <jaypipes> ah, k
20:33:18 <ttx> jaypipes: I picked my day to present that ;)
20:33:23 <jaypipes> heh
20:33:24 <heckj> no objection
20:34:04 <ttx> OK... second part then, the absence of need for stable/* branches  and the idea that you should always be running the latest version of the client anyway
20:34:26 <ttx> since that's what supports every non-completely-deprecated old version
20:34:39 <bcwaldon> ttx: how reasonable is that for distros?
20:35:02 <bcwaldon> always running the latest client, that is
20:35:06 <ttx> bcwaldon: you have to take into account that there aren't so many fixes to client libs
20:35:08 <heckj> for a distribution, you need a cut somewhere, and I want to be able to patch those specific pieces. Are you asserting all distributions should choose their own markers for that?
20:35:08 <danwent> ttx:  i mentioned this in an email to you all a while back.  If in folsom I make big changes to the client, but someone discovers an important but small fix in what we release for essex, where do I commit that minor fix such that distros pick it up?
20:35:42 <bcwaldon> danwent: you won't be releasing clients as 'folsom' or 'essex'
20:35:47 <danwent> ttx: assumption is that current state of client lib is in churn.
20:35:49 <ttx> bcwaldon: otherwise it's quite unacceptable, and they would be doing their stable/essex branches anyway... but if you consider that there aren't that many updates anyway...
20:35:56 <bcwaldon> danwent: you'll bump the bugfix number and release again
20:35:57 <annegentle> do we have any limiters on complaints about documentation for non-core projects? :)
20:36:03 <heckj> danwent: ^ exactly. I think we need this. I don't care if we call it stable/*, but we should have a branch or at least tag when we make a release. Doing otherwise is irresponsible
20:36:14 <danwent> bcwaldon: fair, substitute "previous release" for essex, and "next release" for folsom.
20:36:45 <danwent> bcwaldon: so we as developers we essentially keep an internal notion of a stable branch?
20:36:48 <bcwaldon> danwent: I would assume you could maintain the previous major release if you really wanted to and tag it
20:37:07 <bcwaldon> danwent: with glanceclient, I would only tag master when I want to release
20:37:21 <ttx> heckj: the trick is that there are going to be a flow of releases (uploads to Pypi)
20:37:35 <ttx> heckj: no strong marker like "essex"
20:38:24 <danwent> bcwaldon: that makes sense.  I guess my point is that we'll effectively be having a "stable" branch.  So I guess i'm missing why we said we're getting rid of stable branches.
20:38:26 <heckj> ttx: I'm fine with a tag on each release then, and not a branch - but there needs to be a marker in our code control that indicates where that match is. I don't relish using git commitish
20:38:40 <bcwaldon> danwent: how would we have 'stable' branches?
20:38:48 <ttx> heckj: client libs are actually released by tagging, that's mtaylor's plan
20:39:03 <bcwaldon> danwent: there would be a single branch: master
20:39:36 <danwent> bcwaldon: if i have one branch where I make major changes targeted for the next "big" release of the client, and I also have the ability to keep patching the last big release with minor fixes, to me that seems like having a master branch and a stable branch.
20:39:46 <ttx> we basically only maintain the master..; that doesn't prevent people from having branches... or caollaborating in backporting
20:39:52 <danwent> b/c those "minor bug fixes" would accumulate
20:39:57 <bcwaldon> danwent: I'm advocating for not keeping a 'previous relase' branch around
20:40:26 <ttx> but the CI only tests a simple square matrix of combinations on every commit... not a cubic one
20:40:52 <ttx> hmm, I mean, a set instead of a matrix :)
20:41:04 <jaypipes> we're still talking about the client library projects ONLY here, right?
20:41:08 <danwent> ttx: ok, i don't want to throw this discussion off track.  my only point was that we may well be developing on train sequence of commits, while doing bugfix releases on another.
20:41:09 <bcwaldon> I think we're wandering off into arbitrary-land here
20:41:10 <ttx> jaypipes: yes
20:41:25 <bcwaldon> ttx: get us back on track! :)
20:41:30 <ttx> struggling
20:41:42 <ttx> mtaylor just shot himself
20:41:45 <bcwaldon> we're obviously all in support of the overarching goal here
20:41:48 <mtaylor> hehe
20:42:24 <ttx> mtaylor: stil here ? Defend the absence of need for stable branches, that's your idea :)
20:42:39 <mtaylor> ttx: yup
20:42:42 * markmc wonders whatever happened to the idea of proposals for the PPB being discussed on the mailing list first
20:43:14 <mtaylor> it comes back down to user experience thing ... in what way do you release the old bugfixed client lib so that it's useful to the end user
20:44:07 <danwent> sorry, is that a question to me? :)
20:44:43 <danwent> mtaylor: i agree that's the question I'm getting at.
20:45:26 <ttx> markmc: actually I don't think we'll close the proposal this week, it's more RFC at this stage
20:45:47 <ttx> when we know how to write the final proposal, we'll push to list
20:45:55 <markmc> ttx, cool, just think the various strands could be teased out more thoughtfully on list
20:46:21 <ttx> markmc: in particular, got to know if the "cental part" is acceptable to a majority of PPB members or not
20:46:27 <ttx> central*
20:47:05 <danwent> ttx: none of my concerns are around the central part.
20:47:22 <ttx> So if I summarize...
20:47:36 <jaypipes> yes please :)
20:47:42 <ttx> We can elaborate a plan based on the central part, with the following remaining pain points:
20:48:01 <ttx> - need for "official" stable branches
20:48:29 <ttx> - API or major-rewrite-driven versioning scheme
20:48:50 <ttx> - room for deprecating old APIs
20:48:58 <ttx> any other pain point ?
20:49:45 <danwent> ttx: captures my comments
20:49:51 <johnpur> just a comment, as this is a "policy" decision... this needs to be globally applicable, not choose or not on a per project basis
20:50:04 <heckj> ttx: matches to me
20:50:27 <ttx> johnpur: that would apply to the new "Library" category of openstack projects.
20:50:40 <ttx> but yes, for all of them.
20:50:50 <johnpur> right
20:51:23 <ttx> In particular, it should probably include openstack-common once it is released as a separate lib
20:52:32 <ttx> mtaylor: so that sums up the pain points you need to discuss on and off the ML this week
20:53:12 <ttx> mtaylor: ideally we'll have a final proposal based on that feedback for next week ?
20:54:53 <ttx> Corollary: devstack becomes a gating project, so it is no longer "not an official OpenStack project" as the website claims
20:55:04 <jbryce> all right...anything else for this week on this one?
20:57:18 <mtaylor> ttx: yes. by next week we will have that
20:57:41 <ttx> jbryce: looks like we're done for this week
20:57:55 <jbryce> thanks guys
20:58:00 <jbryce> #endmeeting