*** asalkeld has left #openstack-relmgr-office | 00:32 | |
*** dims_ has quit IRC | 01:35 | |
*** dims_ has joined #openstack-relmgr-office | 08:02 | |
*** dims_ has quit IRC | 08:08 | |
*** dims_ has joined #openstack-relmgr-office | 09:57 | |
*** dims_ has quit IRC | 11:16 | |
*** dims_ has joined #openstack-relmgr-office | 11:17 | |
*** dims_ has quit IRC | 11:28 | |
*** dims_ has joined #openstack-relmgr-office | 11:28 | |
*** dims_ has quit IRC | 11:33 | |
*** dims_ has joined #openstack-relmgr-office | 11:39 | |
*** dims_ has quit IRC | 13:37 | |
*** dims_ has joined #openstack-relmgr-office | 13:38 | |
*** david-lyle_ has joined #openstack-relmgr-office | 14:56 | |
ttx | dhellmann: around? | 15:17 |
---|---|---|
ttx | so... crossproject meeting | 15:42 |
ttx | I could see a point in keeping it if we also used it as a minimal communication point to replace weekly 1:1 syncs | 15:43 |
ttx | for us to say things like "remeber liberty-1 is next week" | 15:44 |
ttx | in addition to discussing random cross-project specs | 15:44 |
ttx | I know some projects like the idea of having a soapbox to describe achivements | 15:44 |
ttx | although they could use the current meeting to do that and they don't | 15:45 |
dhellmann | the oslo team was looking for another outlet, and we thought about setting up a blog. annegentle and reed are going to set things up so we can post to blog.openstack.org, so maybe if more teams use that it can become an official notice channel? | 15:45 |
ttx | ideally all PTLs would be present at least at the beginning of the meeting | 15:46 |
ttx | (or their delegate) | 15:46 |
ttx | and stay if the remaining topics are of interest to them | 15:46 |
ttx | so we could use the start of the meeting for general comms | 15:46 |
dhellmann | that makes sense | 15:47 |
ttx | us and other horizontal teams | 15:47 |
ttx | I don't thin kthe concept of discussing cross-project specs there is flawed | 15:47 |
ttx | it's more the concept of cross-project specs that need a bit of rework I think | 15:47 |
dhellmann | we need more participation in those discussions, one way or another | 15:48 |
ttx | right, but removing the last meeting where we all meet doesn't seem to be the best step we can take | 15:50 |
ttx | I think having more people run that meeting will help finding the right tone/topic | 15:50 |
ttx | we should find other candidates to rotate with | 15:50 |
dhellmann | yeah, I agree that having the meeting still makes sense | 15:54 |
dhellmann | rotating the chair might help, too, and I'm definitely willing to take that on more this cycle now that I'm not running the Oslo meetings as well | 15:55 |
*** david-lyle_ has quit IRC | 16:16 | |
morganfainberg | ttx, dhellmann since I see both of you.... | 16:27 |
morganfainberg | And I suck at remembering to email people. | 16:27 |
ttx | dhellmann: if you review https://review.openstack.org/186390 , we could merge it and cut a new version for yaml2ical that would include your extra-settings and unblock that review | 16:27 |
morganfainberg | Moving keystonemiddleware to the standard 6mo release cycle. | 16:27 |
morganfainberg | When you have a moment. | 16:27 |
ttx | morganfainberg: I think dhellmann has run somewhere for an errand | 16:27 |
ttx | morganfainberg: I don't think that woud cause crazy issues on our side | 16:28 |
morganfainberg | Right. I just want to start making it happen and figure out the plan. | 16:28 |
ttx | morganfainberg: but I think you should start a thread about that on the ML, because I feel like there might be some resistance to the concept | 16:28 |
ttx | so better explain it in written form | 16:28 |
morganfainberg | Since it is unreasonable to assume ksm from say grizzly can run on Juno. | 16:28 |
morganfainberg | There was a ML thread. The only comment was from lifeless asking about semver and requirements issues. | 16:29 |
ttx | oh, ok | 16:29 |
morganfainberg | We did the leg work for general approval at the end of kilo. | 16:30 |
ttx | morganfainberg: to support intermediary releases we talked about denormalizing version numbers for stuff that is released on a 6-month cadence | 16:30 |
morganfainberg | Ok. | 16:30 |
ttx | morganfainberg: so it's not totally crazy to think that what you need to do is refrain from tagging final releases | 16:31 |
morganfainberg | We can keep using semver if we want. And just do the swift-ish releases per milestone, but just track per named release in stead of "whenever" | 16:31 |
ttx | so you are at 1.6.1, you could do 1.7.0b1, 1.7.0b2.. 1.7.0rc1 and 1.7.0 | 16:32 |
morganfainberg | Sounds good. | 16:32 |
morganfainberg | I'll also propose the governance chant to indicate it isn't independent releases? | 16:33 |
ttx | I'll give it another thought tomorrow. I bet dhellmann will have a poke at the idea when he comes back, too | 16:33 |
ttx | morganfainberg: yes, that would go with it | 16:33 |
morganfainberg | Yeah. Let me know after mulling on it / chatting with dhellmann | 16:33 |
ttx | we migth need to do some setup.cfg version to make pbr use preversioning | 16:34 |
morganfainberg | I'll also have a take away that we need to update he docs to say "this only works with its coinciding release" once we do that. | 16:34 |
ttx | so that the versions built are more 1.7.0-alphas than 1.6.1.0.1244 | 16:34 |
morganfainberg | Ttx++. I also think there is a test change we will need to make. But I'll poke at that front as we get there. | 16:35 |
ttx | morganfainberg: the only drawback of this approach is that you lose the sync with keystone version number | 16:35 |
ttx | morganfainberg: is the middleware release tied to keystone release ? Or to the series in general ? | 16:36 |
ttx | that would be the only reason to jump to keystone version as the next (so jump to 2015.2.0b1 at liberty-1) | 16:36 |
morganfainberg | Series. | 16:36 |
morganfainberg | Not to keystone b | 16:36 |
ttx | I mean, both would work | 16:36 |
morganfainberg | Middleware runs in the process space of nova etc. keystone version is fairly independent. | 16:37 |
morganfainberg | Ksm mostly works with any keystone version. Since keystone has its own special middleware. | 16:37 |
morganfainberg | Can't do a rest call to itself to lookup in the DB information. | 16:38 |
ttx | ok, then it might not make sense to jump to align to keystone version, especially with swift and ironic likely to diverge soon | 16:38 |
ttx | I think it makes sense to switch to 1.7.0 preversions | 16:38 |
ttx | and tag betas and all | 16:39 |
morganfainberg | ttx: I would try and diverge keystone itself but I think it would cause hell. | 16:39 |
ttx | ok, need to run | 16:39 |
morganfainberg | Ok will bug dhellmann about my other client release question later on. Thanks and cheers | 16:39 |
ttx | cheers | 16:40 |
*** sileht has quit IRC | 16:47 | |
*** david-lyle_ has joined #openstack-relmgr-office | 17:09 | |
*** david-lyle_ has quit IRC | 17:18 | |
*** sileht has joined #openstack-relmgr-office | 17:27 | |
morganfainberg | dhellmann: you around. Have a question about keystoneclient. I seem to have misplaced a release. And want to make sure I didn't miss something important. | 21:17 |
morganfainberg | dhellmann: we have a 1.4.0 tagged already. Was that you when you setup Liberty (you/ttx that is) | 21:17 |
morganfainberg | Trying to cut the next release but unsure where 1.4.0 came from. I guess I can poke at the signature on the tag as well. | 21:18 |
dhellmann | morganfainberg, ttx: we had a *lot* of resistance to using alphas, and it's quite likely that some of our release tools no longer work with them now. Is there any reason not to treat the middlware as we do other libraries, with intermediate releases and stable branches at the end of cycles? | 21:30 |
dhellmann | morganfainberg: yeah, I tagged 1.4.0 on 21 Apr | 21:30 |
morganfainberg | dhellmann: great I'll close that milestone and 1.5.0 for the next release. | 21:31 |
dhellmann | morganfainberg: I think when I did those, I told the script to ignore the milestones in lp because many projects didn't have them | 21:31 |
morganfainberg | For the middleware I want to clearly make it not a "library" because it really is insane to expect a Juno middleware to run in Liberty. | 21:32 |
dhellmann | I'll be updating that script to create new milestones, now that we're not doing predictive tracking for releases | 21:32 |
dhellmann | morganfainberg: you can control that with dependency specifications though, can't you? | 21:32 |
morganfainberg | Yeah. I will likely just do a per-milestone release with a specific release at the end of the cycle. | 21:32 |
morganfainberg | If the alphas are bad. | 21:32 |
morganfainberg | It was more of a "do it the best way to coordinate it" and make your lives easier. | 21:33 |
dhellmann | yeah | 21:33 |
dhellmann | do you ever want a kilo middleware to run in a juno environment? | 21:33 |
morganfainberg | At this point. No. | 21:33 |
dhellmann | cool | 21:33 |
morganfainberg | The keystone api should never move in a way that breaks people with that in mind. | 21:34 |
dhellmann | so if you have the apps specify the version of the middleware for the current cycle, you can just treat it like we do an oslo lib and make intermediate releases with stable branches at the end of the cycle | 21:34 |
morganfainberg | Midldeware is more closely lined with the services that use it rather than to keystone. | 21:34 |
morganfainberg | ++ works for me. | 21:34 |
dhellmann | yay, consistency! :-) | 21:34 |
morganfainberg | Also we are going to 2.0.0 keystoneclient this cycle. | 21:35 |
morganfainberg | I'll bug you as we get closer. | 21:35 |
morganfainberg | But we are doing that when we start depending on keystoneauth and will likely drop CLI at the same time. | 21:36 |
morganfainberg | And the bit rotting middleware in the ksc package will also drop (i can't even tell you if it works now with modern servers) | 21:36 |
morganfainberg | But I'll coordinate with you prior to making that release so we can head off icky-ness as it pops up. | 21:37 |
*** dims_ has quit IRC | 23:17 | |
*** dims_ has joined #openstack-relmgr-office | 23:20 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!