20:02:53 <ttx> #startmeeting tc
20:02:54 <openstack> Meeting started Tue Dec 18 20:02:53 2012 UTC.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:02:55 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:02:57 <openstack> The meeting name has been set to 'tc'
20:02:59 <ttx> Agenda for today is:
20:03:03 <ttx> #link http://wiki.openstack.org/Governance/TechnicalCommittee
20:03:12 <ttx> #topic Update on the "Future of Incubation / core" joint committee
20:03:17 <ttx> markmc: quick update ?
20:03:39 <markmc> sure
20:03:50 <markmc> had quite a productive meeting actually
20:03:58 <markmc> got more into the incubation process
20:04:07 <markmc> how projects are "trained" to follow our processes
20:04:25 <markmc> how CI starts taking more of an interest in helping incubating projects
20:04:39 <ttx> also raised an interesting question about trademark analysis
20:04:42 <markmc> how incubating projects being part of the devstack gate should become more of a hard requirement
20:04:53 <ttx> on project codenames
20:04:56 <markmc> indeed, trademark
20:05:12 <markmc> how the legal committee could provide kind of consultative help when choosing new project names
20:05:32 <markmc> how part of a project graduating is a qualitative analysis
20:05:44 <markmc> i.e. we should have some sort of quality level we require
20:05:51 <markmc> and how we go about making that call
20:06:09 <markmc> and then we started getting into the whole "what does core mean"
20:06:23 <markmc> jbryce had a nice summary of core vs "part of the release"
20:06:41 <markmc> that core is a label the board can attach to projects in the integrated release
20:06:53 <markmc> and then we were out of time
20:07:02 <ttx> we have one more this Thursday.
20:07:06 <markmc> we'll get more into the "what does core mean" on thursday
20:07:10 <markmc> </summary?
20:07:13 <markmc> </summary>
20:07:20 <ttx> Thanks!
20:07:26 <ttx> questions before we move on ?
20:07:43 <russellb> some of that seems a little tangential, but good discussion anyway, i guess
20:08:06 <russellb> thanks for the update
20:08:09 <annegentle_> markmc: were there notes?
20:08:19 <annegentle_> markmc: was there another invite sent out for this Thurs?
20:08:25 <markmc> annegentle_, yes to both
20:08:27 <markmc> one sec
20:08:31 <ttx> annegentle_:  https://etherpad.openstack.org/IncUp
20:08:31 <markmc> actually, yes and no
20:08:49 <markmc> ttx, notes moved from etherpad to http://wiki.openstack.org/Governance/Foundation/IncubationUpdate2013
20:08:56 <ttx> oh, great
20:09:08 <ttx> #link http://wiki.openstack.org/Governance/Foundation/IncubationUpdate2013
20:09:14 <ttx> any other question ?
20:09:16 <markmc> no invite for this week yet
20:09:41 <AlanClark> I'll go check to see why the invite didn't go out
20:09:48 <ttx> #topic Discussion: Potential Grizzly schedule changes to match probable summit date
20:09:57 <ttx> The Foundation events staff is busy securing a location for the next summit...
20:10:05 <ttx> On the dates side, 40% chances it's Apr 15-18, 60% chances it's Apr 29 - May 2
20:10:13 <ttx> The issue for us is that it's a week before or later than the "ideal" week
20:10:29 <ttx> (ideal week being the one which leaves two full weeks between release week and summit week to prepare, like we did in Folsom)
20:10:39 <ttx> In the case it's one week before, no big deal, we'll just have less time to prepare for summit
20:10:49 <ttx> But if it's the week after, we have 3 full weeks between release week and summit week.
20:10:57 <ttx> I think that's too late in the cycle to have good design discussions at the summit.
20:11:07 <ttx> People would either get started way earlier in implementation, or lose too much time waiting for summit sessions to happen.
20:11:19 <ttx> ideally I would like to limit the amount of time between Grizzly feature freeze and H summit to 8-9 weeks max to avoid that
20:11:39 <ttx> If we don't change the release schedule (and the summit happens Apr 29-May 2, that will be 10 weeks for Grizzly.
20:11:46 <ttx> (in comparison, we had 7 weeks in Essex and 9 weeks in Folsom)
20:12:04 <ttx> So I would like us to look into potential adaptations, so that if we need any, we can push them during the holiday period rather than wait for next year's meetings
20:12:17 <jgriffith> +1 for adjusting to fit the summit
20:12:26 <ttx> Those options are mostly around pushing back final Grizzly release date, in the case Apr29-May 2 ends up being chosen
20:12:43 <ttx> Note that it's probably a one-off thing, next times we should know the date well before the release schedule is set up
20:12:49 <russellb> sounds good to me ... and push the freeze out a week too?
20:12:50 <ttx> I have a PDF showing various options for this scenario:
20:12:54 <ttx> #link http://ubuntuone.com/25a7M1o3jyNAjBUTOfZkHx
20:12:58 <markmc> I don't love that are schedule is driven by event planning considerations, in general
20:13:07 <markmc> but no real issue with pushing it out a week or two
20:13:12 <markmc> if planned well in advance
20:13:20 <ttx> Option A is the "no change" option, just accept having three full weeks between release week and summit week, and 10 weeks between feature freeze and summit
20:13:37 <ttx> Option B1 is pushing back G3 and release one week away. Main issue with this one is that I'm skiing that week.
20:13:49 <ttx> (so someone else would have to handle the final push toward feature freeze and publish that milestone)
20:13:58 <ttx> Option B2 is the same as B1, but taking the opportunity to push back G2 as well
20:14:09 <ttx> Option C is solving the skiing issue by pushing G3 *two* weeks off and have "only" 5 weeks of RC period between G3 and release (like we did for Essex)
20:14:21 <ttx> (means 8 weeks between feature freeze and summit and also pushing back G2 one week off)
20:14:29 <ttx> Finally, option D pushes back *both* G3 and release two weeks off.
20:14:30 <annegentle_> ttx: and others is it your instinct that people would appreciate a Jan 17th milestone based on how much they're trying to get into G2?
20:14:54 <ttx> annegentle_: that's one nice side-effect of B2, C and D
20:15:09 <ttx> (option D leaves only one full week between release week and summit week, and I know we all appreciated having two full weeks after Folsom release)
20:15:16 <ttx> Thoughts ?
20:15:22 <markmc> yeah, I'm sure there'd be general happiness with pushing g2 out a week :)
20:15:24 <ttx> My slight preference would be to go with option C with a pretty anal feature freeze
20:15:24 <annegentle_> B2 or C seem good to me
20:15:36 <bcwaldon> +1 to annegentle_
20:15:46 <ttx> so the shortebed Rc period does not have adverse effects
20:15:52 <ttx> shortened*
20:16:14 <russellb> B2 or C seem fine ... but it's C of those 2 unless someone wants to drive the release of grizzly-3, right?
20:16:21 <markmc> did much happen in the last week of rc in folsom?
20:16:22 <bcwaldon> C it is!
20:16:22 <ttx> russellb: yes
20:16:34 <russellb> bcwaldon: +1 :)
20:16:37 <ttx> markmc: not so much
20:17:06 <ttx> markmc: I think if we are more careful with the feature freeze and landing all stuff by G3... we have less of an issue with 5 weeks of RC
20:17:32 <ttx> 6 weeks was kinda nice but we also had a lot of Feature Freeze abuse after Folsom-3
20:17:39 <markmc> yeah, C it is - don't imagine anyone too eager to be ttx for grizzly-3 :)
20:18:16 <ttx> OK, so we don't change anything if summit is the week of Apr 15
20:18:28 <ttx> And we use option C if the summit ends up on the week of Apr 29
20:18:38 <russellb> hm, really?  what about shorten RC to 5 weeks if summit moves up?
20:18:42 <russellb> if we think 5 is enough?
20:18:47 <russellb> 2 weeks before summit is really nice ...
20:18:54 <ttx> Ah.
20:19:21 <ttx> That's one option yes. I'd like to only change the release date for a good reason though
20:19:33 <jgriffith> ttx: when would we *know* WRT the summit dates?
20:19:49 <ttx> so.. are we more attached to keeping release date or to two full weeks of summit prep ?
20:20:01 <ttx> jgriffith: they promised me in the next 72 hours
20:20:12 * jgriffith votes 2 weeks of summit prep
20:20:13 <ttx> jgriffith: but last week they promised the final decision for today
20:20:16 <russellb> 2 weeks of summit prep personally
20:20:19 <jgriffith> ttx: hehe
20:20:34 <ttx> russellb: that means releasing on March 28
20:20:54 <ttx> and rewriting all those slides that say "in April"
20:21:08 <russellb> who ever got in trouble for finishing a project early
20:21:14 <ttx> I'm fine with it, I like to confuse everyone
20:21:26 <ttx> vishy: opinion ?
20:21:35 <markmc> how about we aim for a very quite last week of rc
20:21:47 <markmc> quiet, dammit
20:21:49 <ttx> danwent: same -- you're the most RC-busy projects
20:22:03 <vishy> I don't like shortening the schedule for sure
20:22:19 <ttx> markmc: +1
20:22:35 <ttx> Let's aim for a quiet release week if summit is on Apr 15
20:22:39 <vishy> extending g2 1 week and g3 1 week seems fine
20:22:50 <vishy> which option was that?
20:23:07 <ttx> vishy: oh, we are exploring the case if the sumit is on Apr 15 now
20:23:13 <mordred> o/
20:23:27 <ttx> We settled for option C in the case the summit is on Apr 29
20:23:37 <vishy> Apr 15 i say no change
20:23:37 <heckj> vishy: +1
20:24:01 <vishy> sorry i was behind :)
20:24:08 <ttx> vishy: OK -- and we'll try to make a calm release week to have a bit more time to prepare summit
20:24:27 * annegentle_ lights calm candles
20:24:41 <ttx> #info If summit is on Apr 15 -- no change in schedule
20:25:24 <russellb> any info you can leak on location?  :)
20:25:38 <ttx> #info If summit is on Apr 29 -- push back G2 one week, G3 two weeks, release one week.
20:26:00 <ttx> russellb: not yet :)
20:26:12 <markmc> I heard it's in europe
20:26:19 <ttx> it's in the US for sure
20:26:24 <ttx> (the April one)
20:26:24 <markmc> heh :)
20:26:25 <mordred> ttx: also, they're working on getting the I summit scheduled/booked so that we know where it is by the H summit, right?
20:26:37 * markmc tries to get vicious rumours started :)
20:26:40 <ttx> mordred: yes. It should be international
20:26:51 <ttx> and location secured before the H summit
20:26:56 <mordred> GREAT
20:26:59 <ttx> #topic Ongoing discussion: Distro & Python 2.6/3.x support policy
20:27:00 <mordred> that will be quite lovely
20:27:03 * vishy looks around.
20:27:06 <ttx> mtaylor: You said you would push a clear motion to the ML to reboot the discussion
20:27:12 <vishy> someone is starting my rumors!
20:27:15 <ttx> mtaylor: looks like it will be for next year meeting now :)
20:27:19 <mordred> ttx: I did say that didn't I?
20:27:25 * mordred accepts chastisement
20:27:52 <ttx> Do you have a teaser version of it we could talk about today ?
20:28:04 <markmc> vishy, from here on in, I'm gonna think of you as Sid Vishy
20:28:06 <mordred> it was basically the summary from the last thread
20:28:17 <vishy> lol
20:28:52 <mordred> ttx: "we should continue dev focus for the latest ubuntu, but ensure that we don't do anything that fundamentally breaks the latest rhel"
20:28:54 <lifeless> Python 4 three-eva ?
20:29:11 <markmc> dev focus on latest ubuntu and fedora :)
20:29:31 <markmc> also, continue to support 2.6.x until it's blocking someone with patches getting 3.x support done
20:29:35 <markmc> ?
20:29:35 <mordred> markmc: for all intents and purposes for dev, that's probably the same
20:29:47 <mordred> markmc: I don't think we need to be that explicit
20:29:57 <mordred> markmc: I don't think we can drop 2.6 until there is a rhel that has 2.7
20:30:07 <mordred> markmc: based on the prior statement
20:30:32 <mordred> and once there is, we'll have an ubuntu lts and a rhel with 2.7 - so there wouldnt' be a compelling reason to keep 2.6 around
20:30:50 <markmc> heh
20:30:57 * markmc avoids repeating the whole thread again
20:30:59 <mordred> and we know for a fact that once we start trying to get 3.x patches done, we will immediately run in to 2.6 issues
20:31:21 <mordred> but, for now at least, I think my statement above doesn't really change anything for anybody, right?
20:31:42 <mordred> (it's clarification on the current policy, which is "we target latest ubuntu")
20:32:00 <markmc> not until there's a rhel with 2.7 or someone sooner than that with 3.x patches
20:32:09 <markmc> and then the whole discussion would start again :)
20:32:15 <mordred> markmc: I'm open to that
20:32:21 <ttx> mordred: ok, you can turn that into a proper motion to be discussed on the ML..; and we can decide on it at the next meeting
20:32:23 <markmc> "we target latest ubuntu/fedora"
20:32:35 <mordred> markmc: ok. btw ...
20:32:53 <mordred> markmc: since we're expressing the current justification for supporting 2.6 in terms of liking RHEL...
20:33:12 <mordred> markmc: you think there's any chance someone at redhat might be interested in helping port our jenkins_slave puppet template to be able to run on a rhel host?
20:33:29 <mordred> because that's our current blocker in running our 2.6 tests on rhel instead of ubuntu oneiric
20:33:34 <markmc> mordred, yes, definitely
20:33:37 <mordred> markmc: great!
20:33:48 <mordred> check it out - people helping each other  :)
20:33:51 <ttx> mordred: anything more on the subject ?
20:33:57 <mordred> ttx: nope
20:34:12 <mordred> ttx: when markmc and I agree on things, I consider the subject closed
20:34:13 <ttx> questions ? mordred WILL push a thread on the ML for further discussion anyway
20:34:21 <ttx> right ?
20:34:28 * mordred whistles
20:34:32 <ttx> #topic Skipping next weeks meetings
20:34:40 <ttx> So... next Tuesdays happen to be Christmas and New Year's day.
20:34:49 <ttx> My suggestion would be to hold our next TC meeting on January 8.
20:35:05 <heckj> ttx: +1 - that's the next keystone meeting as well
20:35:05 <ttx> Sounds good ?
20:35:09 <mordred> ++
20:35:14 <markmc> school's out!
20:35:21 * jgriffith realizes he needs to go shopping
20:35:25 <ttx> we'll probably do the same fate to the release status meeting in half an hour
20:35:36 <ttx> #topic Open discussion
20:35:42 <ttx> Anything else anyone ?
20:37:03 <ttx> Alrighty then. 23 minutes recess
20:37:08 <ttx> #endmeeting