| ttx | mikal: FTR there is no pause. When https://review.openstack.org/#/c/171078/ is merged, Liberty starts | 06:40 |
|---|---|---|
| ttx | I cut the release branch from the previous commit in history | 06:40 |
| ttx | So if you're ready you should probably approve that | 06:42 |
| ttx | (otherwise I'll check with zz_johnthetubagu when he is no longer zz) | 06:42 |
| mikal | ttx: I just emailed you the SHA for RC1, and +2'ed that review, so I think we're good to go | 07:08 |
| mikal | You'll need John to remove his -2 though | 07:09 |
| ttx | Oh. | 07:09 |
| ttx | Right. | 07:09 |
| ttx | mikal: anything that sneaks in before that review will be in Kilo, I fear | 07:09 |
| ttx | I'll make sure he approves it first thing when he gets up | 07:09 |
| mikal | Yeah, two things have snuck in already, but they look harmless to me | 07:10 |
| mikal | I thought I was meant to provide a SHA, but perhaps I am confused | 07:10 |
| ttx | nope. SHAs are for milestone tags. For RC1 we need to bump to liberty and then I take the previous commit and create the kilo release branch from it | 07:11 |
| mikal | Ahhh, ok | 07:11 |
| mikal | Fair enough then | 07:11 |
| mikal | Regardless, I think I've done those thigns now | 07:11 |
| ttx | Indeed | 07:11 |
| ttx | I'll make magic happen from there | 07:12 |
| mikal | Thanks | 07:12 |
| *** zz_johnthetubagu is now known as johnthetubaguy | 08:05 | |
| johnthetubaguy | mikal: ttx: that change should be in the gate now | 08:20 |
| ttx | yep, saw that, thx! | 08:21 |
| johnthetubaguy | np | 08:21 |
| johnthetubaguy | sorry we are using some pacific island time again! | 08:21 |
| johnthetubaguy | ttx: just checking, now we are merged, I guess liberty is open? | 09:14 |
| ttx | yes | 09:14 |
| ttx | Triggering the big machine now to cut proposed/kilo | 09:14 |
| johnthetubaguy | ttx: cool, I thoughts that how it worked, cool | 09:15 |
| johnthetubaguy | ttx: cool | 09:15 |
| johnthetubaguy | ttx: thanks for you help pushing on this, as always! | 09:15 |
| ttx | cheers and congrats! | 09:15 |
| ttx | nikhil_k: Looks like you're ready to go ? | 09:55 |
| *** asalkeld has quit IRC | 10:19 | |
| mikal | I guess we should send a "liberty is open for nova" email to -dev? | 11:01 |
| * mikal sends that email | 11:02 | |
| ttx | mikal: Sure. it's announced at the end of the rc1 email but a bit hidden | 11:29 |
| sdague | ttx: so what's left for RCs? | 12:59 |
| ttx | Glance Horizon Ironic and Swift | 12:59 |
| sdague | ok | 12:59 |
| ttx | I'll have to doublecheck if we need to wait on Swift, but I guess we do | 12:59 |
| sdague | they have a time line? curious when we can cut over g-r | 12:59 |
| ttx | Ironic Monday, Swift Tuesday | 13:00 |
| ttx | Glance and Horizon hopefully today | 13:00 |
| sdague | ok, sounds reasonable | 13:00 |
| ttx | yes, it's not going too bad. | 13:00 |
| ttx | Let me compare with previous cycle(s) | 13:00 |
| ttx | For Juno last RC1s were done by Oct 6 (swift) Oct 3 (others) for an Oct 16 release | 13:02 |
| ttx | For Icehouse last RC1s were done by Apr 4 (swift) and Apr 2 (others) for a Apr 17 release | 13:03 |
| ttx | So we are 10 days earlier. | 13:03 |
| sdague | cool | 13:03 |
| ttx | err well | 13:03 |
| ttx | By Tuesday we'll be D-16 while at Juno we were D-10 and for Icehouse D-13 | 13:04 |
| ttx | so 3-6 days earlier, rather | 13:04 |
| ttx | yes and for Juno we waited until after Swift to unfreeze requirements. | 13:06 |
| sdague | so, is there a reason for that? because swift doesn't do the requirements sync like other projects anyway | 13:07 |
| ttx | which is why I was looking into it | 13:07 |
| ttx | It might have just been laziness | 13:07 |
| ttx | sdague: They could hold on requirements syncs for a few days. They don't really do them anyway | 13:08 |
| ttx | But then if they hit Tuesday it's a bit of a non-issue | 13:09 |
| sdague | agree | 13:19 |
| *** dansmith is now known as superdan | 13:47 | |
| ttx | david-lyle: ping me when around | 14:08 |
| ttx | nikhil_k: ping me when around | 14:08 |
| *** mestery is now known as mestery_afk | 14:13 | |
| nikhil_k | ttx: hi | 14:18 |
| ttx | nikhil_k: glance looks ready from where I stand... Anything you're waiting for ? | 14:20 |
| nikhil_k | double checking | 14:20 |
| nikhil_k | ttx: looks good | 14:21 |
| ttx | nikhil_k: ok, feel free to approve that open-liberty patch then | 14:22 |
| nikhil_k | ttx: will you be sending a bulk email to ML with RCs? | 14:22 |
| ttx | https://review.openstack.org/#/q/branch:master+topic:open-liberty,n,z | 14:22 |
| nikhil_k | ttx: Just want to wait a few days to see how RC1 is | 14:22 |
| ttx | yes, I'll take it from there, just approve the review :) | 14:22 |
| nikhil_k | then consider RC2 | 14:22 |
| nikhil_k | ttx: so we can open Liberty even if we want RC2? | 14:22 |
| ttx | yes | 14:23 |
| ttx | let me explain | 14:23 |
| ttx | You push the libert version bump on master | 14:23 |
| nikhil_k | ttx: ok, please do.. | 14:23 |
| ttx | then I cut a kilo release branch from the commit just before this one | 14:23 |
| ttx | And I tag that same commit as RC1 | 14:24 |
| ttx | Then if you need an RC2 you push the bugfix to master, backport it for proposed/kilo | 14:24 |
| ttx | and we tag proposed/kilo again as RC2 | 14:24 |
| ttx | etc | 14:24 |
| nikhil_k | perfect | 14:24 |
| nikhil_k | makes sense | 14:24 |
| nikhil_k | and about communication for this? | 14:24 |
| nikhil_k | Would you email cover the RC1 part and I can try to explain this to people in a meeting? | 14:25 |
| ttx | I mention liberty being open in the RC1 announcement | 14:25 |
| ttx | Doc is at https://wiki.openstack.org/wiki/Release_Cycle | 14:25 |
| nikhil_k | Cool | 14:25 |
| ttx | or https://wiki.openstack.org/wiki/Branch_Model | 14:25 |
| nikhil_k | people have questions even with the doc :| | 14:25 |
| nikhil_k | Thanks for the links | 14:26 |
| nikhil_k | ttx: approving the review now | 14:27 |
| nikhil_k | ttx: done. https://review.openstack.org/#/c/171227/ | 14:28 |
| ttx | cool, will branch and tga ocne that's in | 14:28 |
| ttx | tag once* | 14:28 |
| nikhil_k | thanks | 14:30 |
| david-lyle | ttx: here | 14:33 |
| ttx | david-lyle: should we wait anymore ? | 14:34 |
| david-lyle | The only reason to wait is django-openstack-auth version | 14:34 |
| david-lyle | I have https://review.openstack.org/#/c/172123/1 posted | 14:34 |
| david-lyle | but not entirely sure that's sufficient to remove the py26 job from the gate for d-o-a | 14:35 |
| ttx | let's ask on #-infra | 14:35 |
| david-lyle | ok, I did yesterday, but I think it got lost in the other things happening | 14:36 |
| ttx | sdague: so it looks like we have incoming: python-cinderclient django_openstack_auth python-barbicanclient python-ironicclient | 14:36 |
| sdague | so.... why? | 14:36 |
| sdague | we've done *all* our validation against the older versions for the servers | 14:37 |
| ttx | let's see... | 14:37 |
| ttx | thingee says "we do have some good fixes" but could skip it | 14:38 |
| sdague | I feel like any client releases need a High priority bug | 14:38 |
| ttx | for django_openstack_auth I'll let david-lyle explain | 14:38 |
| david-lyle | it's requirements mismatch | 14:39 |
| ttx | barbicanclient... "The planned version is 3.1.0. [1] and it will include features landed during FFE." -- since it's not integarted it flies below radar | 14:39 |
| sdague | but, that barbicanclient statement is nonsense | 14:39 |
| ttx | ironicclient... "I've tagged a 0.5.0 version two days ago, and plan a quick fix (0.5.1) today." except he didn't | 14:40 |
| sdague | there are no consumers of those features as a library in the kilo release | 14:40 |
| david-lyle | horizon supports django 1.7 and actually django_openstack_auth 1.1.9 supports django 1.7, but it's requirements list <1.7 | 14:40 |
| sdague | david-lyle: ok, that's a legit bug | 14:40 |
| sdague | and I'd say that's valid to get this out | 14:40 |
| ttx | david-lyle: you need the py26 disable in first right | 14:42 |
| david-lyle | yes, https://review.openstack.org/#/c/172123/1 | 14:42 |
| david-lyle | have I mentioned how much I'd like to run away from Django recently | 14:43 |
| sdague | david-lyle: ok, +A on the project-config change | 14:43 |
| ttx | we can probably resist the cinder one, since thingee wasn't originally planning to push for it | 14:43 |
| sdague | yeh, honestly, these library releases are mostly totally gratuitous, and *unneeded* in any way by the kilo release | 14:44 |
| ttx | barbican is an interesting one. In my simplified view it's not integrated so I shouldn't care. But turns out I have to | 14:44 |
| * ttx checks what depends on it | 14:44 | |
| sdague | I know there is nova code that uses it | 14:44 |
| david-lyle | sdague: ok thanks, once that merges, I'll merge the requirements bump | 14:44 |
| sdague | optionally | 14:44 |
| ttx | So.. they could wait a few days and release it after the cap. Or release it now and we cap with it in it | 14:45 |
| sdague | so, I think we need to figure out how to get the PTLs to understand what libraries shipped with the kilo release are for | 14:45 |
| ttx | except our testing until now was done with the previous version | 14:46 |
| ttx | so the former is safer | 14:46 |
| sdague | right | 14:46 |
| sdague | which is why requirements goes into freeze at M3 | 14:46 |
| sdague | so that all our RC testing is basically on the same code | 14:47 |
| ttx | The trick is in absolute they want the client version in kilo to expose the features in kilo | 14:47 |
| sdague | that's irrelevant | 14:47 |
| ttx | only for different meaning of "in kilo" | 14:47 |
| ttx | right | 14:47 |
| sdague | just release a new version on release day | 14:47 |
| sdague | people can use it | 14:47 |
| ttx | So the optimal solution is.. for tehm to release it between the cap and the release day | 14:47 |
| sdague | yeh | 14:48 |
| ttx | I think we could convince redrobot to do that | 14:48 |
| sdague | it's the confused bit of CLI use and library us in kilo | 14:48 |
| ttx | as always | 14:48 |
| ttx | Let's see.. ironic | 14:48 |
| ttx | tagged 0.5.0 4 days ago | 14:49 |
| ttx | plans to do a 0.5.1 | 14:49 |
| ttx | Looks like it's time for a "no client library release please" thread | 14:51 |
| ttx | to explain the difference between exposing features in CLI and screwing integrated release testing | 14:52 |
| sdague | yeh | 14:53 |
| ttx | sdague: are you pissed off enough to write it ? Or should I ? | 14:55 |
| sdague | no, I'm out of energy to be mad about this, especially as I'm actually still trying to get grenade split up for big tent support | 14:56 |
| ttx | ok, will do | 15:00 |
| *** mestery_afk is now known as mestery | 15:06 | |
| ttx | sdague: could you quickcheck facts in https://etherpad.openstack.org/p/0VFegeLsl0 ? | 15:08 |
| sdague | wfm | 15:09 |
| ttx | thx again for helping me through this maze :) | 15:09 |
| ttx | morganfainberg: oh, you wanted to do a keystonemiddleware / python-keystoneclient too. We should discuss that as well | 15:18 |
| morganfainberg | Yes. | 15:19 |
| morganfainberg | The ksm release should be (will check) a .Z relapse to sync global req. it can wait for cap if needed. | 15:21 |
| morganfainberg | I've been holding any major changes back to be sure we didn't introduce weird behavior. | 15:21 |
| morganfainberg | Client has some pending fixes but likely nothing that needs to land in kilo (but would be nice to have) | 15:21 |
| morganfainberg | Again, not the end of the world if it misses. | 15:22 |
| morganfainberg | So.. I can hold these and wait for cap and we g-r update middleware and call it a day. | 15:23 |
| morganfainberg | Once cap/ branch is cut. | 15:23 |
| * morganfainberg is trying to stay out of sdague 's way. | 15:23 | |
| ttx | That's the safe attitude :) | 15:24 |
| notmyname | ttx: what's the requirements sync you're waiting on swift for? what you and sdague were talking about? | 15:32 |
| notmyname | I thought the dependency freeze was march 19 | 15:32 |
| ttx | notmyname: once we cut stable/kilo requirements branch, we'll apply caps. That will trigger updates to proposed/kilo branches in various projects | 15:35 |
| ttx | The question was whether we need to wait for Swift's RC1 to do that | 15:35 |
| notmyname | ah, gotcha | 15:35 |
| ttx | The perceived answer is that since you don't blindly apply requirements syncs from the bot, it doesn't matter that much | 15:35 |
| ttx | and if you stick to Tuesday you might not be the last one anyway | 15:36 |
| *** dimsum__ has joined #openstack-relmgr-office | 15:36 | |
| notmyname | ok | 15:37 |
| ttx | ok, tagging glance now | 15:40 |
| ttx | david-lyle: I think we'll have to wait until Monday for yours, so that you straighten everything today. If all is green feel free to approve the open-liberty review. i'll pick it up first thing Monday morning | 15:41 |
| david-lyle | ttx: sounds good, couple things have merged to get d-o-a moving, couple more needed | 15:42 |
| david-lyle | will continue to make progress and hopefully all is ready before monday | 15:42 |
| ttx | awesome | 15:42 |
| -openstackstatus- NOTICE: gerrit has been restarted to address a hung event stream. change events between 15:00 and 15:43 utc which were lost will need to be rechecked or have approval workflow votes reapplied for zuul to act on them | 15:45 | |
| *** dimsum__ has quit IRC | 16:05 | |
| *** dims_ has joined #openstack-relmgr-office | 16:07 | |
| *** dims_ is now known as dimsum___ | 16:08 | |
| *** dimsum___ is now known as dimsum_ | 16:08 | |
| *** johnthetubaguy is now known as zz_johnthetubagu | 17:40 | |
| *** mestery has quit IRC | 17:43 | |
| *** mestery has joined #openstack-relmgr-office | 17:43 | |
| *** mestery has quit IRC | 20:24 | |
| *** mestery has joined #openstack-relmgr-office | 20:33 | |
| *** mestery has quit IRC | 21:07 | |
| *** mestery has joined #openstack-relmgr-office | 21:08 | |
| *** mestery_ has joined #openstack-relmgr-office | 21:22 | |
| *** mestery has quit IRC | 21:25 | |
| *** mestery_ is now known as mestery | 21:26 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!