21:03:11 #startmeeting project 21:03:11 Meeting started Tue Sep 23 21:03:11 2014 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:03:12 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:03:15 The meeting name has been set to 'project' 21:03:22 Our agenda for today: 21:03:28 #link http://wiki.openstack.org/Meetings/ProjectMeeting 21:03:48 #topic News from the 1:1 sync points 21:03:51 Here is the log: 21:03:56 #link http://eavesdrop.openstack.org/meetings/ptl_sync/2014/ptl_sync.2014-09-23-08.02.html 21:04:02 Most projects still struggling with RC1 buglists 21:04:08 RC1 race tracked at: 21:04:11 #link http://old-wiki.openstack.org/rc/ 21:04:33 (insert bi-yearly disclaimer for not having time to move it to infra again) 21:04:50 I see the horizon buglist was pruned recently 21:04:50 that's probably a warez site by now :) 21:04:59 it's my warez site. 21:05:06 and soren's 21:05:38 hint: the curves on this graph should go DOWN. 21:05:55 #topic Other program news 21:05:58 Any other program with a quick announcement ? 21:05:59 hah 21:06:03 ya 21:06:10 i'm going to send an announcement to -dev soon about this 21:06:11 ttx: just the update on cinderclient 21:06:24 we are going to freeze project configuration changes in infra (eg, jenkins/zuul config changes) starting thursday 21:06:29 so that we can move all of the project configuration into its own repo 21:06:35 which is awesome because it means it will be much easier for you (yes -- YOU) to review 21:06:44 * SergeyLukjanov here 21:06:44 * dhellmann dances a bit 21:06:50 o/ 21:06:54 jeblair: Yay! 21:06:57 new repo will be openstack-infra/project-config 21:07:15 (existing repo will eventually be renamed openstack-infra/system-config at a later date; we also have other plans for it afoot) 21:07:38 jeblair: ie each project will have its own config repo? 21:07:44 jeblair: what's the difference with openstack-infra/config ? 21:07:50 or just moving all project config to one separate repo? 21:07:58 notmyname: the second thing 21:08:11 you separate the puppet stuff from the config stuff ? 21:08:14 ttx: basically 21:08:57 so other installs would just use system-config, but would redo project-config ? 21:09:10 ok, got it 21:09:14 prototype of what project-config will look like when we are done: https://github.com/anteaya/reorganized-project-config-02 21:09:20 any other announcement ? 21:09:30 ttx: yeah, but more refactoring of system-config needs to happen to make that more useful. but that's the general idea. 21:09:46 ttx: it's a very long-term plan :) 21:10:02 anyway, we will try our best to flush the config review queue before the freeze 21:10:08 in case anyone missed the announcement on the ML, we've started removing code from the incubator for graduated libraries. backports should go straight to the stable/juno (or other stable branch) if needed. 21:10:43 #topic Requirements freeze exceptions 21:11:06 So sdague dhellmann and myself went on a cleanup spree for the requirements repo 21:11:17 we are left with a number fo depfreeze exceptions 21:11:23 that we need to decide on 21:11:30 * kombu >=2.5.0 (https://review.openstack.org/#/c/92095/) 21:12:10 This is just bumps the lower bound for kombu 21:12:31 i'm not sure we *need* it for Juno, but it's certainly closer to reality 21:12:45 is that what we're gating on? 21:12:58 we are gating on 3.something 21:13:04 wow, ok 21:13:29 personally I would freeze that one and wait for a more documented bump to 3.x 21:13:43 rather than just bump 2.4.8 to 2.5.0 21:13:49 ttx: a few things have come up for ironic which would be useful to us, but not critical. please let me know if this is the right place to discuss, or if, as a non-integrated project, it's simply too late 21:13:50 yeah, that makes sense 21:13:55 which feels like a shot in the dark 21:14:09 devananda: probably too late yes 21:14:13 * urllib3 (https://review.openstack.org/#/c/122993/) 21:14:15 ttx: ack 21:14:18 this one is more funny 21:14:29 ttx: the commit message on kombu explains why 2.4.8 is unlikely to work 21:14:43 sdague: ah! here you are 21:14:58 but we aren't really sure 2.5.0 would work a lot better ? 21:15:00 kombu 2.5.0 and newer has switched away from amqplib 21:15:20 hmm, ok, so 2.5.0 is closer to 3.0 than to 2.4.8 maybe 21:15:22 to amqp, which is a fork of amqplib started with the following 21:15:23 goals: 21:15:25 yeh 21:15:33 2.5.0 had a known lib dep change 21:15:34 I can agree with that 21:15:57 Let's bump unless someone complains 21:16:15 +2 21:16:24 sdague: was confised by your lack of +2 on that one :) 21:16:32 ttx: I rebased it 21:16:36 ah! 21:16:43 approved 21:16:50 so .. bck to urllib3 21:16:57 I had an old +2 on it 21:17:07 the urllib3/requests thing seems like a mess 21:17:08 * urllib3 (https://review.openstack.org/#/c/122993/) 21:17:13 dhellmann: agreed 21:17:18 it's the vendorizor vs. Debian thing 21:17:22 * dhellmann considers creating "demands" as a fork 21:17:29 dhellmann: LOL 21:17:31 and honestly, I'd rather not make it more of a mess at this stage of the release 21:17:45 so my feeling is stay how we've been doing this 21:17:55 can change in kilo 21:17:56 sdague: yeah. Debian does effectively fork request locally by unvendorizing it 21:18:04 so they can carry the patch that will make it work 21:18:09 even if they are doing the right thing 21:18:11 sdague: I agree, we have tested it this way all cycle and requests is used everywhere 21:18:14 yeah 21:18:17 sdague, ++ 21:19:28 clarkb: our min version of requests is very old though 21:19:40 dims: ok? 21:19:56 clarkb: https://review.openstack.org/#/c/122716/ just saw this one yday 21:20:02 dims: we're actually testing with 2.2.0 atm 21:20:03 commenetd -1 21:20:12 * xstatic-jquery-ui >=1.10.1 (https://review.openstack.org/#/c/113184/) 21:20:18 sdague: asking for requests>=2.1.0 21:20:22 david-lyle: around? 21:20:26 yes 21:20:43 this is due some structural changes in the package of jquery 21:20:48 dims: there is no requirements review for this is there? 21:20:53 so that's a lower bound bump from 1.8.18 21:21:03 it's actually intended to be a convenience to packagers 21:21:10 sdague: wanted to check before i raised one 21:21:18 dims: well we're in freeze, so no 21:21:22 ok 21:21:37 otherwise when they replace the jquery package with the system package, they have to alter some paths 21:21:46 david-lyle: they all seem happy with it on the review 21:21:56 yes 21:22:01 sdague: any reason we should block it ? 21:22:07 (https://review.openstack.org/#/c/113184/) 21:22:14 ttx: no, I'm pretty 0 on the xstatic stuff 21:22:26 +2ing 21:22:32 * websockify >=0.6.0 (https://review.openstack.org/#/c/114757/) 21:22:32 because it continues to confuse me :) 21:22:48 sdague: do liek me and pretend you understood what David just said 21:22:52 ttx: +2a 21:23:01 \o/ 21:23:31 websockify bump would close a nova bug 21:23:38 that's why I revived it 21:23:42 it seems the packagers can live with it 21:23:51 I think that's a vlid case 21:23:53 +a 21:24:17 +2a 21:24:19 makes sense 21:24:22 * python-heatclient >=0.2.11 (https://review.openstack.org/#/c/122520/) 21:24:38 zaneb: did you get the opportunity to talk with steve*? 21:24:40 yes 21:24:47 stevebaker did just -1 it himself 21:24:52 so it wasn't a specific bug thing 21:25:03 ok, no need to up the floor then 21:25:12 just a case of wanting to make sure that all the new features for Juno were available 21:25:16 ttx: agree 21:25:17 i'll -2 depfreeze it 21:25:29 and unfreeze it in a few days when all RC1s are baked 21:25:49 looks like we have a bunch of approvals that are failing tests (or just not merging) 21:26:18 dhellmann: well rackspace deb mirrors were borked all morning 21:26:24 ah 21:26:31 yes, we'll need a few reeenqueues 21:26:44 and there is a giant backlog because of that 21:26:45 I'll follow up tomorrow morning if nobody beats me to it today 21:26:56 #topic Kilo release schedule 21:27:02 #link http://lists.openstack.org/pipermail/openstack-dev/2014-September/046793.html 21:27:16 * ttx looks at thread to see new comments 21:27:36 so we ahve to choose between two options 21:28:18 one tries to anticipate on a short M cycle by placing the release date on Apr 23, but that means 3 full weeks between release and summit 21:28:26 which can be a bit long, that's what we did before HK 21:28:37 I'm not sure that an "off-week" really is equivalent to an extra week to work on L 21:28:51 zaneb, i'd agree with that assessment. 21:28:55 and it didn't really work as an "off-week" either 21:29:01 the other is the natural date (Apr 30), with two full empty weeks between release and summit 21:29:05 ttx: in the past we tried to sync the releases to ubuntu releases. is that still very important? maybe we can live with our releases being a bit more skewed based on summit dates? 21:29:12 but that makes for a rather short M cycle 21:29:13 * eglynn_ questions the whole idea of an officially blessed "off-week" 21:29:24 eglynn_: ++ 21:29:32 clarkb: the date on Apr 30 is sure to screw them up a bit 21:29:34 yeh, I'm pretty -1 on off-week as a concept 21:29:42 the dates are never going to suit everyone, or even most people, for taking vacation 21:29:57 don't focus on off -week. Are you -1 on the concept of 3 full weeks between release and summit 21:29:57 eglynn_: last time I thought I would spend the week actually working on code, but email continued to roll in at exactly the same rate :/ 21:29:58 it was more about saying "we're not going to be reviewing anything" than "go take a vacation" 21:30:15 ttx: so I'm more -1 about the earlier cadence issues 21:30:23 I didn't take the week off, but was ablt to focus on some internal work 21:30:26 for the start stop reasons I pointed in my email 21:30:26 ttx: I am -1 on that. the summit is already too late IMO 21:31:06 ok, so you all prefer Apr 30 as release date, even if that means a short M cycle 21:31:17 ttx: you mean L cycle, right? 21:31:19 but us 21:31:20 yes 21:31:24 no I mean M 21:31:32 L cycle will be long. 21:31:41 ttx: I'm confused 21:31:48 err 21:31:49 sdague: longer L means shorter M 21:31:50 ttx: I think you're mistaken 21:31:51 dumb question: I presume the summit date is already fixed in stone? 21:31:54 unless we adjust again 21:32:00 yes I am confused 21:32:02 erk 21:32:04 M summit will be early so L cycle will be short 21:32:06 K/L 21:32:08 LOL 21:32:12 eglynn_: I would expect so, by now 21:32:12 sLong K cycle (Oct 16 - Apr 30) 21:32:17 long K cycle, short L cycle. 21:32:22 right, short L 21:32:24 Short L cycle (Apr 30 - Oct 8/15) 21:32:33 yeh, I'm fine with short L 21:32:38 i think we can plan for that, and with a full cycle notice it shouldn't be a big issue 21:32:43 Also fine with a short L 21:32:51 yeah it makes more sense that the longer lead-in to the L summit 21:32:52 tbh long K cycle is good because we always lose a lot of time over new year 21:33:04 zaneb: good point 21:33:06 OK, I'll rework the proposal 21:33:07 zaneb: that's a good ponit 21:33:10 they may come out about even in real terms 21:33:10 because honestly, I think naturally aligning around big outages like christmas will actually provide higher throughput 21:33:16 zaneb, very good point. 21:33:30 and ask RFC with the whole schedule shifted one week to the right 21:33:53 clarkb: so it may screw up Ubuntu, but then they didn't ask us before setting their release dates 21:33:53 ttx: +1 21:34:16 ttx: ya I don't think I am personally worried about it. I just remember that being one of the reasons for stickign to 6 months pretty closely 21:34:18 and they scrapped their own event so they don't have so much constraints as we do 21:34:41 also with cloud archive this probably becomes less problematic? 21:35:04 probably 21:35:14 ttx: do we have L milestone map as well? 21:35:37 if we know when the summit is, it would be handy to get that out there, so people can plan midcycles further in advance 21:35:40 the summit date is not confirmed yet 21:35:49 but i can build one based on the hypothesis 21:35:59 ttx,that would be good. 21:36:06 might be handy so we know what we're talking about L wise 21:36:25 (I actually already have)� 21:36:48 https://docs.google.com/spreadsheets/d/1Ypxkvsfth0DHsDKlPhsjtHaM4zJ_f9sdDgr3pArZEdY/edit?usp=sharing 21:36:58 because honestly, I'm very pro getting milestone-3 back into august, because I felt like the post labor day rush week after tons of people on vacation caused some oddities 21:37:36 all options put l-3 milestoen the week before labor day 21:37:41 or the week before that 21:37:50 so we should be safe there 21:38:05 labor day is when, the first Monday in September? 21:38:08 yeh 21:38:24 Sep 7 in 2015 21:38:40 looks like we lose about 3 weeks in L with long K? 21:39:05 clarkb: i would blame the summit late May, rather 21:39:32 oh right the summit isn't moving 21:39:34 so bringing L-3 too early into August could also have issues with typical European vacation patterns 21:39:41 so I would do a short release-summit, with only one full week between the two 21:39:41 ttx: week before might overlap with burning man, for what that's worth 21:39:59 devananda: what's BM 2015 dates ? 21:40:16 eglynn_: yeh, honestly, it's probably better to have it land during people's vacations than after 21:40:17 usually the labor day weekend, but let me check if they're announced 21:40:30 ttx, Monday 31st August to Monday 7th September 2015 - TBC according to http://www.festivalmag.com/festivals/burning-man/ 21:40:35 ttx: Sept 05 21:40:41 because we saw this giant push of "zomg merge my code there are 3 days left" 21:40:48 and then went into 40 hour gate queues 21:40:53 and landed tons of bugs 21:40:58 sdague: yep, fair point 21:41:21 this spreadsheet is confusing, which part should I be looking at? 21:41:22 devananda: but then you're off for the two weeks before that, so it doesn't really help :) 21:41:26 if we have ms3 in august then we can just say - dude get your stuff in early, because reviewers will be on fvacation 21:41:34 ttx: so expect anyone who's attending that to be offline from aug 29 - Sept 6, if not earlier 21:41:54 devananda: there are far less people at burning man than on regular vacations :) 21:41:56 dhellmann: clearer ? 21:42:03 ttx: yes, thanks 21:42:06 sdague: indeed :) 21:42:42 anyway, still wip 21:42:58 #topic Open discussion 21:43:16 we don't even know if we'll have an integarted release then 21:44:17 or who'll be PTL 21:44:41 ... or even if we'll still have PTLs ;) 21:45:06 ttx, david-lyle, for sahara we need several patches to be merged into horizon to make it fully working - https://etherpad.openstack.org/p/sahara-horizon-remaining-changes-for-juno 21:45:32 * david-lyle looking 21:45:50 hm 21:45:54 https://bugs.launchpad.net/horizon/+bug/1349807 is targeted to k1 21:45:56 Launchpad bug 1349807 in horizon "[sahara] Failed to copy cluster template" [Medium,In progress] 21:46:07 I may have bumped that today 21:46:10 https://review.openstack.org/#/c/118159/ has no bug linked 21:46:41 https://review.openstack.org/#/c/118493 doesn't seem to have a horizon bug linked either 21:46:56 https://bugs.launchpad.net/horizon/+bug/1367394 is untargeted 21:47:00 Launchpad bug 1367394 in horizon "[data processing] Allow username password to be optional for data sources/job binaries" [Undecided,In progress] 21:47:16 SergeyLukjanov: you might want to make sure they are all attached to bugs that are targeted to RC1 21:47:19 ttx, should we re-upload them with bugs attached and target them to rc1 to make sure that sahara will work in Juno Horizon? 21:47:26 otherwise we'll probably release without them in 21:47:49 SergeyLukjanov: yes 21:47:58 ttx, okay, I'll reupload patches after the meeting and ask david-lyle to target them to rc1 21:48:03 david-lyle, ttx, thx 21:48:03 only one of those I was tracking at all 21:48:12 SergeyLukjanov: ++ 21:48:44 ok, anything else ? 21:49:56 I'll take that as a no 21:49:59 #endmeeting