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