15:34:25 #startmeeting 15:34:26 Meeting started Wed May 23 15:34:25 2012 UTC. The chair is mtaylor. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:34:27 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:34:36 #topic what the heck do we do with pypi and client libs 15:34:53 this url works as a substitute for a git url; it may provide a short term solution 15:34:56 https://github.com/openstack/swift/zipball/208b8e85a80e46ddb49dc2035cb292570a20c7db#egg=swift 15:35:12 or for python-glanceclient - -e https://github.com/openstack/python-keystoneclient/zipball/master##egg=python-keystoneclient 15:40:30 bcwaldon: https://review.openstack.org/#/c/7696/ <- new approach 15:41:34 mtaylor: could you explain why we need pypi specifically for client libs ? 15:41:56 mtaylor: i mean, we don't provide pypi for server packages 15:42:18 is it for users of openstack ? for developers ? 15:42:41 Want to make sure I understand the WHY before I jump in the HOW 15:43:44 ttx: i think it's for end users 15:43:46 ttx: pypi is the standard way to distribute python libraries 15:44:30 so, for end users - like me- pypi is where I expect to go to get the latest and greatest python libraries for connecting to openstack 15:44:31 mtaylor: so we should push all our releases to PyPI in addition to LP 15:44:39 well, kinda 15:44:48 that doesn't explain why we would need per-commit as well :) 15:45:19 I do _NOT_ believe that pypi serves any purpose for our server products, because there is virtually no way to get nova, for instance, to install properly via python setup.py install 15:45:29 and also, it's not something that other packages are going to depend on 15:45:52 whereas various tools written in python (including but not limited to our own) will need to express dependencies on python-*client 15:45:55 mtaylor: ok, we use PyPI as a delivery mechanism for our libraries. In which case I'd link it to the release process for any and all libs we provide 15:46:09 ttx: and I'm fine with that in general ... 15:46:18 ttx: the problem is that our release process is designed for our server software 15:46:20 mtaylor: why do you need more than releases ? 15:46:30 and has at its core the idea of multiple parallel supported releases 15:46:40 such as stable/essex, stable/diablo and master 15:46:54 which is of paramount importance for the server 15:47:04 but actually is problematic and gets in the way for client api libraries 15:47:24 (version difference here - think server versions vs. library soname versions) 15:47:36 mtaylor: actually most of our release process ignores stable/* 15:47:52 mtaylor: we have a specific process for stable releases updates (think 2012.1.1) 15:48:02 but the main process is tracking ~trunk 15:48:21 sure. but ... 15:49:15 mtaylor: I think what you mean is that for client libraries stable updates are mixed with new releases 15:49:16 we don't want a user of the libraries to ever need to know about a stable release update for a client lib 15:49:21 yes 15:49:35 so the versioning (that supports the server model) sucks a bit 15:49:36 there should really be one and only one sequence of releases for client libraries 15:49:39 yes 15:50:08 whoops, back now 15:50:09 mtaylor: suppose we do a completeky separate model for client libs 15:50:13 the versioning should be more like libtool library versioning, where there is a libmysqlclient15 and a libmysqlclient16 and no 15.1 ever 15:50:28 (I want to avoid that, but let's talk hypothetically) 15:50:37 ttx: happy to talk hypothetically :) 15:50:58 what would it look like ? 1.1 ? 15:51:03 1.4.5.6 ? 15:51:08 2012.1.122 ? 15:51:12 actually - can we agree first that we all agree that we don't want parallel release trains of client libs? 15:51:14 (at the summit, 'release every commit' was well received enough for us to put it in the etherpad. 15:51:25 mtaylor: agreed 15:51:40 mtaylor: what do you mean ? 15:51:54 "parallel release trains of client libs" ? 15:52:07 oh. stable/* separate from master ? 15:52:08 there are no unstable or stable branches 15:52:11 yeah 15:52:14 ttx: that we don't want stable/essex of *client releasing tarballs in addition to master 15:52:26 single sequence of releases 15:52:35 mtaylor: I think we agree, but there was a bit of opposition to it recently 15:52:42 oh there was? 15:52:51 (from dan/joe in that thread ?) 15:53:12 I believe joe is on board with the idea ... just needs his needs met in the implementation 15:53:13 or did you convince them ? 15:53:20 what thread? 15:53:36 the one where he wanted to make sure there was a way to bake crazy re-structuring 15:53:42 ah 15:53:52 so i think development branches and release branches can be considered separate 15:54:10 if you're doing a crazy rewrite on a crazy development branch, let's not release that to pypi 15:54:19 let's only release it when it's merged to master 15:54:20 I agree we should avoid parallel release trains of client libs if we can 15:54:36 ttx: great! that's a great starting place for the rest of things :) 15:54:44 #agreed we should avoid parallel release trains of client libs if we can 15:54:55 its a worthwhile goal, but so far the cost always appeared prohibitive 15:55:23 (except that we don't have parallel release trains of client libs right now, and it will be expensive to add them) 15:56:18 ANYWAY - now back to your question from earlier about hypothetical versioning... 15:57:13 to me (and I could be wrong, I don't hold this opinion strongly) ... it seems like released client lib versions during the folsom cycle are updates to the essex client lib 15:57:29 rather than pre-releases of a theoretical folsom lib 15:57:55 mtaylor: maybe, but they definietly could have been pre-releases of a folsom lib 15:58:03 think glance v2 or keystone v3 15:58:09 (they could be developing the ability to talk to a folsom feature, for instance) 15:58:48 mtaylor: but they could also be fixing problems talking to essex. it seems ambiguous. 15:59:17 agree 15:59:30 well, and that's part of the thing ... they really arent' tied to essex or folsom 15:59:42 they are libs that talk to _openstack_ - not specifically to essex or folsom 15:59:59 so patches to add support for talking to either version of openstack are enhancments in general to the api library, no? 16:00:07 bcwaldon: (you still lurking here?) 16:00:30 getting pulled in a million directions 16:00:33 (Historic note: the reason why the client libs are considered "just another deliverable of the corresponding server project" was so that we didn't get into difficult discussions about a whole new category of core projects that would not really be released as the rest of core) 16:00:36 bcwaldon: GREAT! 16:00:38 going to have to leave shortly 16:00:42 but I'm here for a minute 16:01:22 (But yes, I'd agree that it forces the client libs to adopt a release model that fits server parts better) 16:01:55 Not sure if any cinder folks are going to make it today, but we're scheduled for 10:00... 16:02:08 jgriffith: how far away is 10:00? 16:02:15 jgriffith: oops, we just sort of commandeered the room - we can vacate... 16:02:18 (and I've yet to see a model that would be compelling enough to justify muddying the waters about what "OpenStack Core" is) 16:02:24 jeblair: 2 minutes ago :) 16:02:38 jgriffith: ah, thanks! :) 16:02:43 evacuate... evacuate... 16:02:47 mtaylor: no worries, keep it untl folks speak up that they're here for the meeting 16:02:55 ttx: well, I don't think we need to muddy the waters ... I think we can still tie the projects together like we have 16:03:14 mtaylor: with different release models ? ew. 16:03:28 or different version numbers ? ewwww. 16:03:42 jeblair: ok - sake of argument in the opposite direction from what I was suggesting before ... (check me if I'm stupid here) 16:03:49 ttx: i do think that client libs syncing up and releasing with servers is still very useful; it just seems it would also be useful if they released much more frequently as well. 16:04:04 oh, no - I remember why the thing I was about to say is broken 16:04:12 mtaylor: glad i could help 16:04:49 mtaylor: we should #endmeeting and continue the discussion elsewhere 16:04:52 ok 16:04:54 #endmeeting