20:00:12 <jbryce> #startmeeting
20:00:13 <openstack> Meeting started Tue Jan 17 20:00:12 2012 UTC.  The chair is jbryce. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:00:38 <jbryce> who all is here?
20:00:45 <ewanmellor> Ready and willing
20:00:48 * jk0 
20:00:54 * ttx 
20:00:55 <jbryce> ewanmellor: but are you able?
20:01:18 <mtaylor> o/
20:01:26 <ewanmellor> Less able than I was when I was younger.  I have to settle for "willing" these days.
20:01:49 <jbryce> ewanmellor: ha
20:01:58 <johnpur> o/
20:02:28 <anotherjesse> o/
20:02:34 <jbryce> joshuamckenty, anotherjesse, vishy, pvo, zns: here?
20:02:43 <anotherjesse> and vishy is here
20:02:56 <jbryce> agenda: http://wiki.openstack.org/Governance/PPB
20:03:13 <jbryce> first couple of items were requested by josh, so maybe we skip to m2crypto and give him time to arrive
20:03:19 <jbryce> #topic M2Crypto options
20:03:27 <jbryce> mtaylor: want to lead this one?
20:04:08 <mtaylor> totally
20:04:11 <joshuamckenty> hey, sorry I was late
20:04:23 <zns> zns here
20:04:28 <anotherjesse> our use is pretty small at the moment
20:04:41 <anotherjesse> we could just shell out to openssh ....
20:04:45 <joshuamckenty> gah
20:04:56 <joshuamckenty> we USED to do that, and replaced it with m2
20:05:17 <mtaylor> m2 seems to be a pretty good lib - other than the abandoned part, yeah?
20:05:25 <joshuamckenty> I like the idea of reviving m2crypto if it's paid for by HP
20:05:39 <johnpur> :)
20:06:08 <mtaylor> yeah - I certainly don't mind doing the work on it (or making someone else do the work)
20:06:12 <anotherjesse> it is only used for the EC2 x509 cert stuff - we originally wrote it shelling to openssh
20:06:29 <joshuamckenty> it's used in cloudpipe as well, IIRC
20:06:32 <anotherjesse> switching back to not using m2crypto should be pretty easy
20:06:38 <joshuamckenty> but I don't think anyone uses cloudpipe anymore
20:06:50 <ttx> is there another better-maintained Python lib to do that ?
20:06:53 <anotherjesse> joshuamckenty: xtoddx- has been rewriting in openstack
20:07:07 <joshuamckenty> yeah, I saw the bastion-host notes
20:07:11 <ewanmellor> You all mean openssl, no?  For x509 processing?
20:07:14 <mtaylor> there was also the thought of moving people away from pycryto so that we used m2 in all the places we use pycrypto too
20:07:40 <ttx> ewanmellor: yes
20:07:42 <joshuamckenty> one dependency is better than two
20:07:46 <mtaylor> Paul McMillan was suggesting that he thought that would be a good idea a little while ago
20:07:58 <ttx> ewanmellor: (if they don't, that's what they should mean)
20:08:12 <joshuamckenty> is m2crypto > pycrypto ?
20:08:22 <mtaylor> that's what paul was asserting
20:08:28 <anotherjesse> other than x509 it is used in ./nova/virt/xenapi/vmops.py
20:08:41 <anotherjesse> everwhere else already does shells out to openssh
20:08:52 <joshuamckenty> openssl
20:09:41 <anotherjesse> vishy doesn't want m2crypto either
20:09:55 <anotherjesse> we both prefer removing it as a dependency if we have this issue
20:10:01 <joshuamckenty> is that because of packaging bugs?
20:10:17 <anotherjesse> m2crypto has always been a pain
20:10:22 <anotherjesse> the value we get out of it so small
20:10:29 <joshuamckenty> esp. for mac dev environments :)
20:10:51 <_0x44> One thing... nova has paramiko as a requirement and paramiko depends on pycrypto...
20:10:51 <mtaylor> well, packaging bugs/bugs in setup.py are the thing that brought it to mind - but we have no way to fix upstream bugs of any sort at the moment
20:11:24 <joshuamckenty> well, if it's a nova dependency only, it seems like a PTL call
20:11:37 <ttx> Shelling out to openssl would be ugly if we didn't shell out in lots of places already
20:11:39 <mtaylor> it's less work from my end to just stop using it - and yeah, that's totally a vish call
20:11:47 <joshuamckenty> I prefer libraries to shelling out in general, but it's a loosely held opinion
20:12:02 <ttx> joshuamckenty: I agree with that, when a valid lib exists.
20:12:09 <anotherjesse> https://github.com/openstack/nova/blob/master/nova/crypto.py#L124 <- in the same file we already use it
20:12:24 <mtaylor> so shall I just file a bug requesting m2crypto removal from nova?
20:12:37 <jk0> +1
20:12:38 <joshuamckenty> anotherjesse: if you git blame that, is it mine?
20:12:43 <mtaylor> (that's so much less work on my part)
20:13:02 <ttx> mtaylor: sounds more reasonable than aopting M2Crypto under openstack core infra
20:13:07 <ttx> adopting*
20:13:09 <mtaylor> great!
20:13:10 <joshuamckenty> mtaylor: +0
20:13:11 <notmyname> -1 to that
20:13:20 <LinuxJedi> mtaylor: happy to take that one once you file it
20:13:23 <joshuamckenty> notmyname: you'd rather fix the library?
20:13:23 <notmyname> (adopting m2crypto into openstack)
20:13:26 <joshuamckenty> oh, right
20:13:36 <johnpur> ok by me to removal
20:13:36 <joshuamckenty> notmyname: we're voting the reverse - gut m2crypto use
20:13:42 <ewanmellor> Doesn't anyone fancy taking it over, outside of OpenStack infrastructure?  Just maintain it like any other open-source project?
20:13:44 <mtaylor> thanks LinuxJedi
20:13:56 <joshuamckenty> ewanmellor: I'll propose that to CloudPassage
20:14:00 <notmyname> joshuamckenty: it's a nova-only thing so its use is, as you said, a ptl issue
20:14:10 <joshuamckenty> it's kind of outside our focus, really
20:14:17 <notmyname> indeed
20:14:52 <johnpur> just so Monty has a clear directive from Vish, or whatever
20:14:54 <jbryce> sounds like there's no real interest in taking it over so it just falls back to the project to decide about taking it out
20:14:56 <mtaylor> yup. as long as we decide that we don't want to take it under our wing, the rest I can take up with vish. thanks!
20:15:03 <joshuamckenty> Next topic?
20:15:12 <jbryce> #topic ppb role in foundation
20:15:17 <joshuamckenty> Right
20:15:19 <jbryce> joshuamckenty: did you have anything specific in mind on this one?
20:15:42 <joshuamckenty> There were some comments on the foundation list about whether we should be reviewing / juggling the governance structure prior to foundation formation
20:16:09 <joshuamckenty> I know the issue of jbryce, anotherjesse, johnpur and myself having appointed seats has come up repeatedly
20:16:25 <ttx> joshuamckenty: opening more seats to election ?
20:16:35 <ttx> (or all ?)
20:16:44 <joshuamckenty> Personally, I don't see this as something that needs to get changed prior to the foundation setup, but I should probably excuse myself from the vote :)
20:16:55 <jbryce> honestly, i'd rather focus on figuring out what changes we want in the foundation and move as quickly as we can on that than trying to push changes to existing--lightly used anyway--structure
20:17:11 <zns> +1
20:17:15 <mtaylor> +1
20:17:16 <ttx> joshuamckenty: unfortunately the PPB doesn't own its own governance, so we can't vote to change that
20:17:39 <joshuamckenty> well, I would respect a PPB vote to have me give up my seat
20:17:46 <joshuamckenty> so in that sense, we do
20:17:48 <anotherjesse> ttx: we can't vote to appoint ourselves dictators for life :(
20:17:51 <johnpur> jbryce: is the foundation thinking far enough along to have this discussion?
20:18:23 <joshuamckenty> The PPB is currently the closest thing to what the foundation board is likely to look like
20:18:23 <johnpur> at some poiont we will need a transition plan
20:18:30 <ttx> jbryce: I think opening all seats would be a step forward towards a full meritocracy though -- and we don't have an idea of when the foundation will be set up, yet
20:18:47 <joshuamckenty> so I'm curious if we feel any specific responsibilities towards foundation-establishment
20:18:50 <joshuamckenty> as a group, I mean
20:18:56 <joshuamckenty> I'm personally fairly involved with it
20:19:00 <joshuamckenty> but not in the PPB context
20:19:05 <jbryce> ttx: that's based on the assumption that voting is automatically a better result which you yourself told me you don't fully agree with at the last conference
20:19:07 <anotherjesse> not sure that PTLs would want to be on the governance board of the foundataion…  speaking not as one
20:19:34 <jbryce> johnpur: we've said that there will be a technical body in the foundation similar to the ppb
20:19:42 <joshuamckenty> ttx: I'm also not convinced that a full meritocracy is either ideal or likely for the foundation
20:19:47 <ttx> jbryce: you can't blame RAX for getting people elecrted, but you can blame Rackspace for having the power to appoint
20:19:56 <joshuamckenty> since the community itself is largely (exclusively) a business ecosystem
20:20:04 <zns> We talked about the governance of the foundation being separate from the technical governance. So PTLs would probably be more keen on technical governance, IMO.
20:20:19 <joshuamckenty> zns: good point
20:20:26 <johnpur> zns: agree
20:20:28 <ttx> joshuamckenty: the solution would be to have a board of directors that is separate from the technical meritocracy
20:20:30 <jbryce> i think it makes sense to have a discussion about what the technical governance body should look like in our opinion, but that will also be a discussion that the broader community will have input on as well
20:20:34 <mtaylor> what jbryce just said is my only important concern ... I want to make sure there is a technical meritocracy body to take questions like the m2crypto question to. I certainly don't mind there also being a business-focused board as well
20:20:57 <joshuamckenty> mtaylor: +1
20:21:10 <joshuamckenty> so my only concern is getting a better balance in the technical board
20:21:11 <ttx> the problem being, the current PPB kinda has the double role
20:21:28 <joshuamckenty> I think the PTL mechanism isn't that useful for a set of projects at different lifecycle points
20:21:30 <notmyname> joshuamckenty: balance in what way?
20:21:39 <ttx> joshuamckenty: we could have quotas from a given company ?
20:21:41 <joshuamckenty> nova is 80% of the active development, no?
20:21:46 <joshuamckenty> no, I meant across projects
20:21:47 <jbryce> ttx: i'd be happy to blame rax if i felt damaging decisions were coming from that power. can you point to specifics that have damaged the community or the developers?
20:21:55 <ttx> joshuamckenty: i.e. they can't own more than 49% of the seats ?
20:22:03 <joshuamckenty> I'm worried about company quotas on the board, not so much on technology
20:22:34 <ttx> jbryce: people that are afraid of this power look at the future more than at the past
20:23:12 <notmyname> joshuamckenty: do you think that means that nova needs more or less representation on a tech board?
20:23:20 <joshuamckenty> notmyname: I sort of feel like nova needs proportional representation - e.g., more.
20:23:27 <joshuamckenty> to account for nova-volumes and nova-network
20:23:48 <ttx> joshuamckenty: you can have one seat reserved by project (kinda PTL) + the rest elected from the global community of dev
20:24:08 <jbryce> joshuamckenty: that tends to leave the smaller projects underrepresented who have a different perspective and need sometimes
20:24:09 <joshuamckenty> but again, the projects aren't equal in size, community interest, or lifecycle
20:24:17 <ttx> Anyway, we are discussing foundation structure now
20:24:25 <joshuamckenty> no
20:24:35 <joshuamckenty> we're discussing the role that the PPB should have in establishing it
20:24:37 <joshuamckenty> if any
20:24:39 <zns> joshuamckenty: what does a better balance on the technical board get you? What problem are you trying to solve? Does Nova have a problem they are facing because of underrepresentation?
20:24:46 <jbryce> the other question is does every ptl get a seat forever? what if we end up with a dozen projects, does the technical body grow infinitely?
20:24:52 <notmyname> joshuamckenty: is nova getting forced into decisions now that it wouldn't if it had more representation?
20:24:58 <joshuamckenty> yes to both
20:25:10 <zns> joshuamckenty: elaborate?
20:25:10 <joshuamckenty> nova has the bulk of the work from any openstack-wide technical decisions
20:25:19 <jbryce> yes to both of my comments or ziad's? = )
20:25:29 <joshuamckenty> yes to zns and notmyname
20:25:32 <joshuamckenty> multithreading
20:25:55 <ttx> jbryce: I think I would rather have project representatives present at the meetings, but with no voting power if they weren't elected
20:26:05 <anotherjesse> joshuamckenty: vishy and I think the rest of the projects have been pretty supportive of project wide issues
20:26:11 <anotherjesse> joshuamckenty: can you give examples?
20:26:19 <joshuamckenty> paste
20:26:20 <zns> What about multithreading? * not arguing, just missing info *
20:26:22 <ttx> and have true elections over the whole corpus of openstack developers, no per-project seat
20:26:33 <jbryce> zns: i think he was just referring to multiple conversations threads
20:26:41 <joshuamckenty> yeah, sorry
20:26:47 <joshuamckenty> I am multithreading
20:26:54 <zns> ah. Got it.
20:27:16 <jbryce> ttx: so elected voting members and PTLs are ex-officio?
20:27:31 <joshuamckenty> Anyway, technical board composition I think we can solve going forward. Is that something the PPB wants to put a proposal forward on?
20:27:41 <ttx> if they didn't get elected, PTLs should be present, but not have voting powers
20:27:44 <joshuamckenty> E.g., do we think that's a role we play in foundation discussions?
20:28:05 <ttx> joshuamckenty: as a group ?
20:28:08 <joshuamckenty> yes
20:28:21 <jbryce> joshuamckenty: i think it would be very relevant for us to talk about this specifically
20:28:22 <ttx> if we agreed on something, we... could
20:28:34 <ttx> but we also can as individual members
20:28:35 <jbryce> we've probably all seen plenty of the problems and areas for improvement
20:28:40 <joshuamckenty> So I see three key topics the PPB could weigh in on...
20:28:47 <joshuamckenty> 1. Technical board composition, representation, etc.
20:29:02 <joshuamckenty> 2. OpenStack as implementation and not standards
20:29:12 <joshuamckenty> 3. OpenStack as IaaS
20:29:33 <joshuamckenty> the third is, e.g., clarifying the openstack mission statement
20:29:34 <ttx> joshuamckenty: it seems simpler to weigh in the general foundation discussion as individuals with influence
20:29:46 <ttx> rather than try to come up with some lazy consensus among all PPB members
20:29:52 <joshuamckenty> well, the first might be good to have a PPB lazy consensus
20:30:04 <joshuamckenty> since it would represent the current-best-effort
20:30:49 <joshuamckenty> Do we feel we own responsibility for a transition plan? Jointly with whomever/whatever the foundation is?
20:30:54 <ttx> joshuamckenty: so we would discuss that on our mailing-list rather than on the foundation ml ?
20:31:14 <joshuamckenty> Or cc both of them < ttx
20:31:34 <joshuamckenty> Is everyone on the PPB also on the foundaotion mailing list?
20:31:37 <ttx> joshuamckenty: I'll be happy to weigh in on any discussion about tech board composition, on whatever ML
20:31:46 <notmyname> once the foundation is in the later stages (ie we have a pretty good idea of what it will look like), IMO we have the responsibility to be a part of a smooth transition
20:31:54 <notmyname> joshuamckenty: I'm not on the foundation list
20:31:59 <joshuamckenty> I would feel uncomfortable drawing conclusions about PPB dynamics without knowing that everyone else was involved
20:32:06 <ttx> I already did start a discussion on that on the foundation ML, but almost nobody picked it up
20:32:32 <zns> joshuamckenty: I'm not on the foundation ml. Not looking to be either unless I am called upon...
20:32:37 <jbryce> i think these topics are important to have in the broader discussions, but i would appreciate thoughts based on the last year of this PPB experiment from all of you who i'm sure have opinions
20:32:38 <jbryce> = )
20:33:13 <jbryce> and i read the messages to the both lists so wherever it happens is fine with me
20:33:13 <joshuamckenty> For context, can we get some numbers from stefano about contributor's / committers to each project?
20:33:13 <notmyname> zns: +1
20:33:50 <jk0> we need to make sure those numbers are accurate :)
20:33:58 <joshuamckenty> Alright, if I start a rant about tech board composition with ttx, I'll make sure it's cc'd to both foundation ML and PPB ML
20:34:07 <mtaylor> joshuamckenty: I also want to take soren's participation numbers from a few months ago and expand them into a few regular reports
20:34:13 <ttx> "I'll be ranting with you"
20:34:32 <mtaylor> since we can get some really accurate numbers about committers from gerrit pretty easily
20:34:38 <joshuamckenty> Anyone else feel we have foundation responsibilities? Either in definition, in transition, or ongoing?
20:34:41 <jbryce> what if we start with a reasonable proposal before we go straight to a rant
20:34:43 <joshuamckenty> As a group, not as individuals.
20:34:53 <jbryce> it sounds like there's some pretty common ground
20:34:57 <joshuamckenty> jbryce: I'm down with that
20:35:21 <jbryce> joshuamckenty: i think transition definitely...we've got some projects in incubation
20:35:42 <joshuamckenty> I'd like to see us decouple (a little bit) the "openstack core" definition with PPB membership / PTL status
20:35:45 <jbryce> but my guess is that since 10 of 14 seats are currently elected, the make up will be fairly similar
20:35:53 <mtaylor> joshuamckenty ++
20:36:19 <joshuamckenty> like what ttx is suggesting vis-a-vis ex-officio for PTLs that haven't been elected yet,
20:36:36 <joshuamckenty> but also allowing PPB participation for really LARGE incubated projects
20:36:56 <mtaylor> and not getting swamped as we collect things like client libraries and the like
20:37:15 <zns> joshuamckenty: define LARGE. Lines of code or importance? … slippery
20:37:16 <joshuamckenty> agreed
20:37:41 <notmyname> joshuamckenty: in other words, be decent grown-ups and talk to each other?
20:37:53 <ttx> I'd rather have more area-specific technical leads and less PPB members
20:38:02 <joshuamckenty> Well, just thinking about nova-volumes again
20:38:18 <joshuamckenty> Wanting to make sure it's got solid tech board representation even BEFORE it gets carved off from nova
20:39:19 <joshuamckenty> since API definition, etc. is all happening inside nova, but will end up being a point of cross-project integration
20:39:28 <zns> Sounds like Large would probably be defined by the PPB. And since they're voting on incubation, there caveat for LARGE is unnecessary…
20:39:47 <jbryce> we've got 20 minutes left and i'd love to get to the last agenda item
20:39:49 <zns> i.e. vot in or out. Size doesn't matter ( in this case )
20:39:54 <zns> vote
20:39:54 <joshuamckenty> Let's do it
20:40:00 <jbryce> can we make starting a mailing thread the action of this?
20:40:03 <joshuamckenty> zns: I just want them decouipled
20:40:22 <jbryce> #topic Essex release check
20:40:26 <joshuamckenty> yeah
20:40:27 <zns> joshuamckenty: not against that. For a later discussion....
20:40:37 <joshuamckenty> Am I the only one who's worried?
20:40:44 <ttx> worried by ?
20:40:46 <joshuamckenty> Of course, I'm ALWAYS worried
20:40:52 <joshuamckenty> state of essex
20:41:00 <joshuamckenty> Lack of good CI coverage at this date
20:41:02 <joshuamckenty> the usual
20:41:08 <zns> No, you're not the only one.
20:41:18 <joshuamckenty> Having the entire tree broken in 2.6 just prior to E3
20:41:31 <joshuamckenty> We *can't* ship a broken Essex
20:41:34 * ttx puts his release manager hat on
20:41:38 <joshuamckenty> So if we're going to slip the date,
20:41:40 <notmyname> that really happened? how? isn't that why we have gates?
20:41:47 <joshuamckenty> I think we should do it now.
20:41:56 <joshuamckenty> Messaging will be much worse if we're closer to the release date.
20:42:06 <ttx> joshuamckenty: how is slipping the date helping in the areas you outlined ?
20:42:07 <zns> -1 on slipping the date. +1 on focusing on hitting it.
20:42:15 <mtaylor> jaypipes: (or anyone) is tempest ready to be turned on in the integration test gating yet?
20:42:18 <ttx> With Nova/Glance/keystone using Essex-3 as their feature freeze, we already have 10 weeks of stabilization planned
20:42:24 <jaypipes> mtaylor: no.
20:42:25 <ttx> Compared to 4 weeks for Diablo, and 3 weeks for Cactus
20:42:27 <mtaylor> ok
20:42:33 <ttx> So the challenge will be to get most developers focused on bugfixing for 10 weeks
20:42:40 <joshuamckenty> right
20:42:43 <ttx> Slipping the date doesn't help when nobody is working on bugfixing
20:42:45 <joshuamckenty> we've got global hack day
20:42:48 <joshuamckenty> and bug crush day
20:42:53 <ttx> On previous releases I could count the number of developers working on that on one hand
20:42:59 <joshuamckenty> we're trying to use meetups to build some shared momentum around bug fixing
20:43:12 <ttx> So I'd really like people/companies complaining about Essex potential lack of stability to put their foot where their mouth is and get developers on deck working on existing known bugs
20:43:23 <anotherjesse> joshuamckenty: are you concerned about E3 not being "feature complete"
20:43:27 <ttx> I'd like core reviewers to get anal-rententive
20:43:35 <jaypipes> ttx: ++
20:43:36 <anotherjesse> is there stuff your team is still working on?
20:43:37 <joshuamckenty> anotherjesse: no, just not stable.
20:43:59 <jaypipes> joshuamckenty: what is piston doing about stability?
20:43:59 <joshuamckenty> Yeah, but we're shipping on Diablo anyway, so that doesn't worry me.
20:44:03 <ttx> That's all we need.
20:44:13 <joshuamckenty> jaypipes: Organizing bug fixing sprints. You coming on the 2nd?
20:44:23 <jaypipes> joshuamckenty: yup. already booked tix.
20:44:27 <anotherjesse> 3 months before release seems early to call it
20:44:38 <joshuamckenty> Any later will be too late
20:44:46 <joshuamckenty> there will be too much market pressure to hit the date
20:44:49 <ttx> anotherjesse: slipping the date is not really an option
20:44:56 <jaypipes> joshuamckenty: but that doesn't mean bugs get fixed. we need a better prioritization of bugs and less focus on Diablo.
20:45:00 <joshuamckenty> Slipping the date is always an optino
20:45:03 <ttx> We have a design summit lined up, and promises to distributions
20:45:04 <notmyname> can there be a later date (say 1 month from now) where everything is reevaluated and a decision to push back is made then?
20:45:13 <joshuamckenty> I'd like to propose a vote to fire the release manager who doesn't believe we can slip the date
20:45:19 <jaypipes> joshuamckenty: disagree. slipping the date just means we aren't doing time-based releases..
20:45:28 <ttx> a later date will NOT help in anything. We'll just ship later, in the same state
20:45:44 <ttx> The challange is to get developers working on bugfixes.
20:45:51 <ttx> Not just their bugs
20:45:54 <jaypipes> ttx: and functional test writing.
20:45:55 <ttx> Known bugs
20:45:56 <anotherjesse> ttx: ++
20:46:03 <mtaylor> ttx: ++
20:46:03 <ttx> jaypipes: and functional test writing.
20:46:05 <jbryce> so how can we rally on that front?
20:46:20 <ttx> rallying doesn't help. Mettups don't help
20:46:30 <jaypipes> jbryce: getting help from devs at RAX and Piston on Tempest test writing would be a good start...
20:46:34 <jbryce> admitting defeat helps?
20:46:35 <ttx> Forcing your developers to work on it helps
20:46:53 <joshuamckenty> jaypipes: wait - it's Tempest now?
20:46:56 <joshuamckenty> What happened to Kong?
20:47:01 <joshuamckenty> And SmokeStack?
20:47:03 <ttx> For Diablo we had 4 weeks, but only 5 people actually tried to address known bugs
20:47:04 <zns> Part of the problem is we're pushing to get features in by E3 given we're freezing features after E3. So stability has been pushed back to beyond E3. That does not bode well for E3 being stable...
20:47:06 <anotherjesse> jbryce: imho the fact that the folks working on feature changes are all targeting E3 as feature complete and focusing on stability after Jan 26 means we are
20:47:09 <jaypipes> joshuamckenty: different things.
20:47:09 <joshuamckenty> And... what was Soren's thing?
20:47:12 <ewindisch> jaypipes: companies shipping this code do need to continue working on and fixing Diablo. Piston and Cloudscaling both. That doesn't distract too much from fixing bugs in Essex, imho.
20:47:22 <anotherjesse> joshuamckenty: tempest has be the ci project for a few months now
20:47:25 <anotherjesse> ci.openstack.org
20:47:28 <ttx> I'd like to have a sizeable portion of our 200+ committers working on bugfixes. Not 5
20:47:32 <vishy> zns: agreed, but no one is trying to ship off of e3
20:47:41 <mtaylor> joshuamckenty: tempest is the name of openstack-integration-test project, it sucked in code from kong early on
20:47:43 <ttx> and that WON'T happen unless they get the word from their management
20:47:43 <anotherjesse> err - http://qa.openstack.org/
20:47:48 <jaypipes> ewindisch: those companies should be helping to write test cases (in Tempest) and firing those tests against their Diablo targets.
20:47:56 <ttx> the PTLs have done their share, featurefreezing at E3 is VERY early
20:47:56 <zns> joshuamckenty implied he wants to "ship" E3...
20:47:58 <anotherjesse> http://qa.openstack.org/integration.html is the details
20:48:06 <ewindisch> Cloudscaling has some people working on bug fixes and we're increasing that effort. We also have the zeromq-rpc blueprint ready to move toward inclusion, which is a new driver, but the code doesn't change or break anything that is already in trunk, so it is low-risk.
20:48:08 <vishy> ttx: i know that our team is rallying around testing / perf testing / bugfixing / administration cleanup
20:48:14 <joshuamckenty> zns: I didn't imply that that I know of
20:48:29 <ttx> vishy: goos. We'll see how that translates into targeted bugs getting picked up
20:48:32 <ttx> good*
20:48:36 <jbryce> ttx: that sounds like rallying the companies to put their money where their mouth is...
20:48:57 <jaypipes> vishy: your team, yes. I
20:49:08 <mtaylor> also - as soon as we have even smaller chunks of usable tests laying around, let us know and we can add them to the integration testing being done
20:49:09 <jbryce> which i'm willing to go work on
20:49:10 <ttx> jbryce: yes. Give a break to their devs and tell them to go and fix known issues instead of doing... whatever they do
20:49:12 <jaypipes> 'm hoping Gigi's team can add some heft to Tempest
20:49:31 <ttx> joshuamckenty: and I'd agree that the time ie NOW
20:49:34 <ttx> is*
20:49:38 <jk0> ttx: it's not always that easy
20:49:45 <ttx> jk0: explain
20:50:01 <zns> joshuamckenty: my bad. I misread your "we can't ship a borken Essex". That I agree with. So, does that mean we can live with an unstable E3 to get features in and then stabilize by Essex release?
20:50:26 <notmyname> ttx: we can't control what companies set as the priorities for their devs
20:50:28 <jk0> if a team is in the middle of trying to ship features, it can be hard to break away and focus only on bugs (that might not even apply)
20:50:36 <jaypipes> zns: for Glance, I'm going to push back hard on any features after E3.
20:50:36 <joshuamckenty> "We", being the OpenStack community, can't afford to have Essex as broken as Diablo was
20:50:41 <joshuamckenty> it will be the end of OpenStacl
20:50:44 <notmyname> joshuamckenty: +1
20:50:46 <jaypipes> joshuamckenty: ++
20:50:50 <mtaylor> ++
20:50:54 <johnpur> +1
20:50:56 <ttx> notmyname: indeed. But we can spread the word that it will be their fault (again) if it's not rock-solid
20:51:01 <jaypipes> joshuamckenty: and "broken" == "not integrated properly"
20:51:06 <joshuamckenty> correct
20:51:14 <joshuamckenty> also not release-noted
20:51:32 <jaypipes> joshuamckenty: release-noted?
20:51:35 <ttx> "We", being the OpenStack community, should spend our resources getting integration tests written, then
20:51:46 <joshuamckenty> So can we get a PPB vote, just so I'm clear on the consensus?
20:51:55 <joshuamckenty> OpenStack should never slip a release date:
20:51:57 <jaypipes> joshuamckenty: vote on what precisely?
20:52:01 <anotherjesse> what is the vote on?
20:52:13 <joshuamckenty> That OpenStack is a time-based release, no matter the quality
20:52:35 <ttx> I would slip the release date if I thought it would help in quality. It's usually a few more days at the end.
20:52:43 <joshuamckenty> It puts a very clear message on openstack's priorities
20:52:48 <jaypipes> no it doesn't.
20:53:01 <zns> Those are not the only two options. You can have time and qualirty if you're flexible on scope.
20:53:06 <jaypipes> yep
20:53:21 <joshuamckenty> not as a community effort you can't
20:53:23 <jaypipes> it's all about whether you push back properly.
20:53:31 <jaypipes> yes you can...
20:53:31 <joshuamckenty> in a company, you can redirect resources from features, to quality
20:53:40 <jaypipes> yes you most certainly can.'
20:53:53 <anotherjesse> you can not accept patches that aren't improving quality
20:53:55 <zns> joshuamckenty: sounds like your opinion, but not necessarily fact or shared...
20:53:56 <joshuamckenty> in a community, you need a lever against business investment
20:54:05 <ttx> joshuamckenty: then you should get the word out there to all those openstack companies you see at your meetups
20:54:22 <mtaylor> anotherjesse: ++
20:54:23 <ttx> joshuamckenty: all we can do is say "no more features past next week"
20:54:39 <ttx> and ask core reviewers to not let pass any crap
20:55:00 <jaypipes> right.
20:55:01 <johnpur> ttx: agree 100%
20:55:08 <zns> +1
20:55:13 <ttx> in the end, if nobody works on bugs, adding months to the release won't change a single thing.
20:55:23 <anotherjesse> ttx:  / joshuamckenty - and that is exactly what we said at the summit
20:55:27 <anotherjesse> and all the PTLs agreecd
20:55:51 <jaypipes> anotherjesse: ++
20:56:05 <ttx> I think we are having a reasonable state of breakage at feature freeze. Now we need to REALLY switch to bugfixing.
20:56:17 <ttx> and not just continue to work on features on our end
20:56:27 <jbryce> so...what are we arguing about right now exactly? it sounds like we have a plan that we think we yield better results if we are sticklers for what gets in and we need companies to commit to quality for the remaining milestones
20:56:28 <ttx> jbryce: that's the message we need to get out
20:57:14 <jbryce> in terms of what we can do, do all reviewers know what they should be using as new guidelines?
20:57:25 <jbryce> ttx: we'll work on getting that message out
20:57:48 <joshuamckenty> fair enough. I have a 1pm, gotta run. Good to know what we're working with.
20:57:48 <jbryce> i just happen to be meeting with managers at several companies next week. this will definitely be on my list of topics
20:57:55 <ttx> jbryce: a lot of companies said they would invest in strategic contributions, and yet jaypipes has been struggling to get people writing integration tests
20:58:08 <jaypipes> jbryce: we need a strong and united PTL voice to the mailing list to say that after E3, the focus is entirely on stabilizing and bug fixing.
20:58:22 <ttx> and Cish and I have been struggling to get people assigned to known and targeted bugs
20:58:25 <mtaylor> and for folks doing work on test suites ... get me things I can run consistently and repeatably ... the more tests we can run, the more we can check that quality
20:58:27 <ttx> Vish*
20:58:27 <jbryce> and we can review progress in a month
20:58:43 <jaypipes> mtaylor: that is the goal.
20:58:56 <ewindisch> It is pretty short notice to say that for E3. I suppose it is fine if it isn't a hard-fast rule, or if there is a leniency for new code.
20:58:58 <mtaylor> jaypipes: I know it. :) -- just re-iterating
20:59:14 <jbryce> ewindisch: i believe this is the plan for after e3
20:59:16 <jbryce> ok
20:59:19 <jbryce> we're up against our time limit
20:59:26 <zns> Good meeting. It's been a while! Thanks, all.
20:59:37 <jbryce> thanks everybody. i thought we actually covered some good stuff today
20:59:38 <ttx> and with that.. next meeting is precisely on getting a better handle on release status
20:59:42 <mtaylor> ++
20:59:47 <jbryce> #endmeeting