19:04:27 <dtroyer> #startmeeting openstackclient
19:04:28 <openstack> Meeting started Thu Jun  9 19:04:27 2016 UTC and is due to finish in 60 minutes.  The chair is dtroyer. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:04:29 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:04:32 <openstack> The meeting name has been set to 'openstackclient'
19:04:35 <dhellmann> heh, I owe you a review of that reno patch still
19:04:52 <dtroyer> That is part of what I want to kick around a bit
19:05:07 <dtroyer> no hurries though
19:05:22 <dtroyer> #topic releases
19:05:44 <dtroyer> So, for the record, OSC 2.6.0 was released this week, scheduled to be the last 2.x series
19:06:02 <dhellmann> in what way is 3.0 planned to be incompatible?
19:06:11 <dhellmann> sorry, I'm a bit out of the loop...
19:06:28 <dtroyer> we're making some command changes to fix bad early decisions on my part (ip floating?????)
19:06:40 <dtroyer> plus the plugin interface is going to change (osc-lib is part of this)
19:06:42 <dhellmann> ok, cool
19:06:49 <dtroyer> plus auth is going to change
19:06:58 <dhellmann> wow, so very different it sounds like
19:07:00 <dtroyer> in short, stuff that we've been saving to do all at once
19:07:22 <dhellmann> I wonder if it's worth using a feature branch, in case there's something critical to make a 2.6.1?
19:07:25 <dtroyer> most of it should be internal, except for the potential auth behaviour changes and overt commands changes
19:07:43 <dtroyer> that's why we did 2.6.0, I had planned for 2.5.0 to be the last
19:07:49 <dhellmann> then merging the feature branch into master and releasing that as 3.0.0
19:07:50 <dhellmann> ok
19:07:56 <dtroyer> at this point I think we're past that
19:08:02 <dhellmann> ok, cool
19:08:13 <dtroyer> one thing I do want to talk about now though is the package name change we discussed about 3 generations ago
19:08:34 <dtroyer> I think we've all agreed that we should have not used the python- prefix
19:08:44 <dtroyer> this is the time to change that I think, if we are going to.
19:08:52 <dtroyer> (just the package name, not the repo)
19:09:06 <dtroyer> I need to refresh on what all would need to happen to do that
19:09:24 <dtroyer> so 'openstackclient' would be the 3.x package name
19:09:47 <dhellmann> I think we just need to edit the line in setup.cfg, although we might have to do some work in the releases repo to make the links to the tarballs work right
19:10:36 <dhellmann> ah, we can set 'tarball-base' in the deliverable file in the releases repo
19:10:47 <dtroyer> ok, cool.
19:11:19 <dhellmann> that might be a bit odd since we already have a newton deliverable, but that's not a blocker on changing the name
19:11:28 <dtroyer> are there installation considerations for pip?  we're not changing the internal namespace so we can't have 2.x and 3.x co-installed
19:11:53 <dhellmann> you'll have to register the new name on pypi
19:12:02 <dtroyer> I know rpm/apt handle that sort of thing
19:12:18 <dtroyer> ok, but to do an upgrade in one step, will we have to doc the uninstall first?
19:12:33 * dtroyer that didn't make sense
19:12:34 <dhellmann> I don't think pip handles it automatically. one way to do it is to release a python-openstackclient 3.0.0 that has nothing in it but the dependency on openstackclient, but that may be tricky
19:13:19 <dhellmann> given the number of ui breaks it might be better to *not* have a package dependency, and just document the name change
19:13:58 <dhellmann> we should look at what this will do to the documentation publication stuff, too. I don't know if it builds the URL for docs.openstack.org/developer from the git repo name or the deliverable name or something set in project-config
19:14:14 <dtroyer> what about the other way around?  have 'openstackclient' have an empty 'python-openstackcleint' 3.0 as a dependency?
19:14:18 <dhellmann> and obviously the install guide will need to be updated
19:14:42 <dhellmann> having the dependency go the other way wouldn't help with an upgrade, because you'd still have to know to install using the new name
19:15:00 <dhellmann> if you have python-osc -> osc ,then if you "pip -U python-osc" you'd get the new package
19:15:24 <dtroyer> I was thinking about the case of just pip install osc without uninstalling p-osc first
19:15:34 <dtroyer> they'd step on each other
19:15:39 <dhellmann> ah, yes
19:15:49 <dtroyer> so now I'm wondering if we should just suck it up and not change
19:16:06 <dhellmann> it's going to be quite disruptive to change
19:16:10 <dtroyer> it isn't a problem other than "I wish we had done it differently"
19:16:31 * dhellmann nods
19:16:33 <dtroyer> and it seems to have gotten worse since the last time we talked about it
19:16:46 <dtroyer> ok, I'm fine not doing it then
19:16:49 <dhellmann> the fact that we have things relying on it now makes it worse
19:17:48 <dtroyer> does this mean we're officially past the 'new-distrupting-green-field' stage and into 'stuck-with-what-we-are' stage? ;)
19:18:10 <dhellmann> yes, I think osc is all growed up
19:18:29 * dtroyer gets all nostalgic for <verb> <object> commands
19:19:19 <dtroyer> the release notes thing then is the other bit I wanted your thoughts on…
19:19:20 <dhellmann> what's the plan for the command renames? any backwards compat period, or cold turkey?
19:19:40 <dtroyer> at a high level, is bucking the release-codde-name model going to be too painful?
19:19:55 <dtroyer> the comamnd renames will have a deprecation period for the old names
19:19:59 <dtroyer> 1 year IIRC
19:20:07 <dhellmann> ok, that seems like plenty of time
19:20:35 <dhellmann> so, for the release notes, it's an interesting idea to base it on versions rather than our release series/branches
19:21:09 <dhellmann> I like it for osc, because as you point out the version doesn't really mean compatibility or not with a given version of openstack itself
19:21:28 <dhellmann> if we can get the build to look right, we can add some features to reno to make it easier to maintain in the future
19:21:31 <dtroyer> exactly
19:21:49 <dhellmann> the issue will come in if we need to scan more than one branch for version numbers in a given series
19:21:56 <dtroyer> I think having the latest-version attribute you mentioned would be enough for the current setup I have
19:22:35 <dhellmann> that works until you want a page showing all of the 3.x versions but those versions come from 2 or more branches
19:22:59 <dtroyer> I was watching some of your conversation about the release tag merge and understand how things work a bit more now
19:23:15 <dtroyer> and it's working today because we only have one place where a release isn't on master, 2.3.0
19:23:15 <dhellmann> yeah, that was a surprise to me, I didn't realize we were doing that
19:23:20 <dtroyer> or, 2.3.1 rather
19:23:46 <dtroyer> but it explained why what I did worked as much as it did, I understand where it'll break down the road
19:23:55 <dtroyer> I think
19:24:32 <dhellmann> I'll have to check, but I don't know if the tags are being merged for osc -- we only do that in very specific cases, and I think it only applies to milestone-based projects
19:24:52 <dtroyer> IIUC there might only be one tag to even merge
19:24:55 <dtroyer> 2.3.1
19:25:06 <dtroyer> in stable/mitaka
19:26:00 * dhellmann looks at git repo
19:26:13 <dhellmann> I don't see a 2.3.1
19:26:38 <dtroyer> oh, I know where I got that, it's what stable/mitaka reports itself as
19:26:56 <dhellmann> ah, yeah, that would be the next release for mitaka if you choose to tag it
19:27:10 <dhellmann> and I think that would not be merged into master, because master is already ahead of that
19:27:18 <dtroyer> right
19:27:18 <dhellmann> and it's not a pre-release version
19:28:53 <dhellmann> does what I said about the 3.x versions spanning multiple cycles, and stable branches, make sense?
19:29:24 <dtroyer> yes, and if that's a problem would probably convince me to not do this
19:29:41 <dhellmann> it may take some feature work in reno, but it's doable
19:29:54 <dtroyer> again, it isn't a big deal
19:30:06 <dhellmann> that, or have pages like 3.0-3.1.rst and then 3.2-3.4.rst or whatever
19:30:33 <dhellmann> this is the sort of thing a non-openstack project would want to do, so I'd like to be able to support it
19:30:43 <dtroyer> if we have those pages then ..include them together so sphinx makes one output page, I'd be happy
19:30:45 <dhellmann> oh, you know, we could just have multiple directives in a given file
19:30:50 <dhellmann> so I'm making this a bigger deal than it is
19:31:09 <dhellmann> yeah, ok, lightbulb went on, this is not an issue at all
19:31:15 <dtroyer> \o/
19:31:35 <dhellmann> just have more than one release-notes directive in each file, to pull in the versions from the branches they're on
19:31:41 <dhellmann> no big deal
19:32:02 <dtroyer> cool
19:32:25 <dhellmann> we can still do the latest-version thing to simplify that, too
19:32:35 <dhellmann> or, shudder, a pip-style version range
19:32:58 <dtroyer> that thought crosed my mind.    <3 would be good enough for this I think
19:33:09 <dtroyer> that was < 3
19:33:09 <dhellmann> of course that depends on this only working for pep440 versions, so I like a separate field better
19:33:36 <dtroyer> what I have now is even livable to me because it shouldn't change once set and is only set for a major bump
19:33:47 <dhellmann> reno is doing a literal string comparison of the version now
19:34:25 <dtroyer> version comparisons are ugly, if you don't need to go there…
19:34:42 <dhellmann> yeah, and I don't want reno to have to worry about what versions mean, because it doesn't now
19:34:49 <dhellmann> well, except for pre-releases collapsing
19:35:26 <dhellmann> ok, I'll make a note to work on the latest-version thing
19:35:40 <dtroyer> cool, thanks Doug
19:35:58 <dtroyer> if I can help, holler
19:36:56 <dhellmann> sure, I'll see what I come up with and run it past you to see if it's going to do what you want
19:37:23 <dtroyer> so unless someone else has something, I have a thing or two to record in the logs, then I'm done…
19:37:47 <dtroyer> #topic reviews
19:38:33 <dtroyer> I want to wait until next week (6/13-ish) to start merging 3.x stuff
19:38:36 <dhellmann> I don't have anything to raise
19:39:14 <dtroyer> which includes the KSA patch first, then tangchen's Ip command changes and the osc-lib stuff
19:39:37 <dtroyer> I would prefer to not merge any more cleanups (i18n, etc) until after that as its causing rebase fun for us ;)
19:40:14 <dhellmann> makes sense
19:40:27 <dtroyer> and that is all
19:41:16 <dtroyer> thanks dhellmann, this was very productive for me ;)
19:41:42 <dhellmann> good, I'm glad I was able to make it today :-)
19:42:01 <dtroyer> #endmeeting