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