20:02:04 #startmeeting tc 20:02:05 Meeting started Tue Nov 13 20:02:04 2012 UTC. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:02:06 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:02:07 The meeting name has been set to 'tc' 20:02:36 On our plate today: 20:02:40 #link http://wiki.openstack.org/Governance/TechnicalCommittee 20:03:07 jaypipes, heckj, notmyname, bcwaldon, jgriffith, vishy: join us if you can 20:03:10 o/ 20:03:12 o/ 20:03:17 o/ 20:03:21 #topic Motion: 3rd-party APIs 20:03:28 #link http://lists.openstack.org/pipermail/openstack-tc/2012-November/000088.html 20:03:35 o/ 20:03:43 This was debated at length on the ML, but not so much after the actual motion text was posted 20:03:54 Any more questions/discussion needed on that before we vote ? 20:03:57 "does yet have" should be "does not yet have"? 20:04:03 probably 20:04:13 * markmc has the habit of saying the exact opposite of what he meant :) 20:04:25 markmc: then we must be in agreement ;-) 20:04:25 yeah, "does not yet" 20:04:37 markmc: ok 20:05:12 "The previous aspirational statement that the PPB made in May 2012 about 3rd party APIs being implemented external to core stands. However, where a given project does not yet have expose a "stable, complete, performant interface" for 3rd party APIs to build on, that project may choose to accept proposed new APIs in the interim if it sees fit." 20:05:36 any other question before vote ? 20:05:43 "does not yet have expose a" ? 20:05:54 heh 20:06:10 "The previous aspirational statement that the PPB made in May 2012 about 3rd party APIs being implemented external to core stands. However, where a given project does not yet expose a "stable, complete, performant interface" for 3rd party APIs to build on, that project may choose to accept proposed new APIs in the interim if it sees fit." 20:06:11 danwent: those crazy Irishmen can't spell 20:06:18 I can spell just fine 20:06:30 just add/miss random words here or there 20:06:37 it's that complicated forming of words into sentences thing... 20:06:40 well, i figured errors in the statement would make people think we didn't even read it :P 20:06:43 Sorry, I'm trying to get it. Any scenarios this enables or disables? Does it enable Google's APIs? Does it preclude AWS? 20:07:01 is it sufficiently vague to let PTLs do what they want? (Is that the idea?) 20:07:22 annegentle_: I don't think that statement enables or diables. It brings back full control on the matter to each PTL 20:07:39 ttx: ok, then I do get it :) 20:07:46 annegentle_, the specific ask is "should the Nova PTL be allowed add GCE support to Nova while we don't have a stale API for having GCE support external" 20:07:48 but still give a general "good" direction 20:07:55 s/stale/stable/ 20:08:17 any other question? 20:08:44 Ready to vote ? 20:09:25 #startvote Approve 3rd-party APIs motion? yes, no, abstain 20:09:26 Begin voting on: Approve 3rd-party APIs motion? Valid vote options are yes, no, abstain. 20:09:27 Vote using '#vote OPTION'. Only your last vote counts. 20:09:33 #vote yes 20:09:35 #vote no 20:09:40 #vote yes 20:09:50 #vote yes 20:09:52 #vote yes 20:09:53 #vote yes 20:09:54 #vote yes 20:09:54 #vote yes 20:10:11 "30" more seconds 20:10:13 #vote abstain 20:10:14 #vote yes 20:10:38 #vote yes 20:11:09 #endvote 20:11:10 Voted on "Approve 3rd-party APIs motion?" Results are 20:11:11 yes (9): markmc, bcwaldon, ttx, vishy, russellb, jgriffith, mordred, annegentle_, danwent 20:11:12 abstain (1): gabrielhurley 20:11:13 no (1): notmyname 20:11:23 #info Motion approved 20:11:28 #topic Ongoing discussion: Incubator process update 20:11:41 We have a thread going on openstack-dev... the idea being to come up with a view that has majority support from the TC to be defended in a joint committee with the BoD 20:11:48 #link http://lists.openstack.org/pipermail/openstack-dev/2012-November/thread.html#2387 20:11:58 Looks like positions are crystallizing around two views so far, which is quite good 20:12:08 View 1 is about separating the "core" and "common release" concepts... 20:12:11 * mordred is in favor of crystalization 20:12:18 ...considering incubation as the path towards common release, leaving the labels like 'core' to be applied for trademarks choice by the BoD 20:12:24 This was best expressed by markmc in: 20:12:29 #link http://lists.openstack.org/pipermail/openstack-dev/2012-November/002470.html 20:12:40 Here, one aspect to consider is that the Foundation bylaws actually define what an openstack project is (in section 4.1b): core + library + gating + supporting 20:12:56 Same article also defines "core" as "the software modules which are part of an integrated release and for which an OpenStack trademark may be used" 20:13:10 Note that the "and" in this definition leaves some room for us to have projects part of an integrated release which would not be "core". 20:13:25 Section 4.13b says the TC can decide for anything which is not a core project, but that the BoD approves TC recommendations for anything core. 20:13:39 The trick being that sections 4.1 and 4.13 is quite difficult (though not impossible) to change, as it's protected by section 9.2d 20:13:43 ttx, bylaws can be changed, sounds like the kind of thing that we should be open to changing 20:14:01 Thoughts? 20:14:05 I have a question about the proposal that includes the "common release" projects (or any proposal that decreases the number of core projects significantly): how does that affect TC membership? 20:14:17 markmc: sure, it's just one of the sections that require a lot of approvals to be changed 20:14:28 ttx, oh, is it? darn - I'd lost track 20:15:00 gabrielhurley, I think we'd eventually have to get back to the idea of all TC seats being elected 20:15:38 gabrielhurley: the "common release" projects could be considered like other "official projects": contributions to them would allow you to vote for directly-elected TC members 20:16:15 then we can decide to stop special-casing "core" projects since we wuldn't care that much about them 20:16:35 which then goes to what markmc just said 20:16:46 View 2 is to still define Core, as pure IaaS. Best expressed by notmyname @ 20:16:51 #link http://lists.openstack.org/pipermail/openstack-dev/2012-November/002455.html 20:17:05 I had a few questions about it, maybe others have too 20:17:11 notmyname: is it, in your mind, completely incompatible with view 1 ? 20:17:29 so, it seems like modulo some libraries and stuff, "Core" == "in OpenStack" under the current definition 20:18:05 it seems liek notmyname's definition would/could include dnsaas and lbaas but not horizon or dbaas 20:18:11 like 20:18:13 damn spelling 20:18:13 would we be having the same debate if the categories were "services + library + gating + supporting" 20:18:15 ? 20:18:15 zaneb: there are official projects, which we control... and a number of them were marked "core" 20:18:51 the only trick is that the bylaws mention the project categories, which makes it a bit difficult to change 20:19:00 * markmc thinks the project should be inclusive, that projects are attracted to joining us under our project umbrella is a good thing 20:19:09 markmc: ++ 20:19:11 we could cheat by adding whatever we want as "supporting" projects though :) 20:19:19 markmc: +1 20:19:20 my point is that we're more hung up on the definition of the word than the definition of the category 20:19:48 zaneb, View 1 is basically to stop fussing about the definition of Core 20:19:57 I think the disscussion about core and incubation will make a bylaws change necessary anyway 20:20:04 zaneb, and leave it purely be a trademark policy thing, which we leave up to the Foundation 20:20:11 so - there's a definition from the OIN about Linux which I really like: 20:20:26 notmyname: around? 20:20:31 markmc: I think that we should be restrictive because more projects will end up diluting what openstack is and distract from a focus on them 20:20:32 #link http://paste.openstack.org/show/25820/ 20:20:33 ttx: ya 20:20:42 notmyname: is it, in your mind, completely incompatible with view 1 ? 20:20:47 (view 2) 20:20:56 ttx: ya, I'm trying to grok that into a short statement 20:21:07 ok, take your time :) 20:21:10 notmyname, new projects and contributors IMHO don't dilute, they enhance 20:21:31 markmc: +1 20:21:38 specifically, I like the (reworded): "has been or is likely to be leveraged across multiple OpenStack platforms" 20:21:45 markmc: generally I agree more projects are great, but the shared resources then become more taxed. 20:21:49 ttx: I think that both view one and view two share similar goals, but the specifics (especially around scope) make the two views incompatible 20:22:14 hopefully we can grow the contributions to shared resources just as the set of projects grows 20:22:18 annegentle_: well, the shared resources physically are fine - the shared resources in terms of Docs and CI - people need to understand that they need to start participating and sharing the load there 20:22:24 but that goes for our core projects as it is now 20:22:25 notmyname: so your definition of "core" is only valid if core == common release ? 20:22:28 * markmc stops typing what russellb just typed 20:22:37 as almost none of the big-time people contribute squat to the CI infrastructure as it is 20:22:53 so I don't really think that adding new projects is going to be any worse from that perspective than it is now 20:22:55 mordred: russellb: yes I share that hope but then that expectation must be built into the bylaws 20:23:17 ttx: that's a tautology since it's what's in the bylaws. core should be a limited set of projects that enhance the focus of openstack. I think that means we should focus on IaaS 20:23:25 annegentle_: I think it could be in the TC guidelines for new projects inclusion - hey, you guys particupating in supporting systems at all? 20:23:25 annegentle_, bylaws can't really be used to force people to contribute to specific areas, I think 20:23:37 notmyname: +1 20:23:44 yeah, rules around that worry me a bit 20:23:54 ++ 20:23:56 should be a cultural thing, part of what makes a project be "playing nice" in openstack 20:23:58 yes 20:24:05 markmc: that's true. Just stating my position about expansion vs. conservation. 20:24:10 and I think it's something we need to get out there now anyway 20:24:18 even for our current projects 20:24:23 mordred, yep 20:24:30 definitely legitimate growing pains, but i don't think we should let that hinder growth 20:24:34 russellb: ++ 20:24:41 Hmm, what's the way forward ? Continue discussion on the ML ? Formalize both views as motions and vote for or gainst them at next meeting ? 20:24:50 except that it seems what you're proposing (new projects and more people help us all) is counter to your other goals of "all the projects should work together". all the core devs helping out on all the projects means that the core devs become more "shared resources" and that means more projects dilutes the community 20:25:05 I disagree 20:25:09 I think we're talking about different thigns 20:25:11 I wonder if we're really addressing what the board needs addressed? http://lists.openstack.org/pipermail/openstack-tc/2012-November/000072.html 20:25:15 russellb: "playing nice" seems to be a bit subjective and open up quite a bit of interpretation, result is ANY project is core if they "play nice" 20:25:19 I'm not talking about core devs working on all the projects 20:25:29 I was talking about dilution of shared resources - specifically doc and CI teams 20:25:41 jgriffith: sure ... but we're charged with making that judgement call when evaluating projects 20:25:46 and I mainly htink that the project as a whole has not valued adding resources to doc and CI as it grows 20:25:52 in favor of adding more devs to hack on features 20:25:56 mordred: your team was just talking about core devs needing to research and file bugs on different projects when those bugs prevent gating on a patch 20:25:58 jgriffith, playing nice is a requirement, but not sufficient on its own 20:26:06 markmc: that's kinda my point 20:26:07 annegentle_: view 1 is addressing the board needs imho. View 2 is a bit stepping on their toes 20:26:09 notmyname: yes. that's a specific issue 20:26:33 I'm talking about rackspace and nebula and at&t and NTT and HP ponying up people to work on docs and CI 20:26:45 instead of having those people working on internal versions of the same 20:26:48 ttx, I'd love us to have consensus, but it seems like we need some sort of vote 20:26:55 mordred: which doesn't have anything to do with "core", right? (although it is a critical need) 20:26:59 that's a good point, mordred, we do need to do a better job of that. 20:27:00 notmyname: it does not 20:27:06 ttx: Perhaps we vote on if we should even define core or not? 20:27:11 notmyname: it only is a response to "more projects dilute shared resources" 20:27:13 ttx, problem with voting on something is that it needs to be a broad direction, not specifics - plenty to discuss with the board that could change the details 20:27:14 ttx: Seems we're all over the map here right now 20:27:16 the shared resources should be scalable 20:27:19 or in a different view, making contributions to docs and CI a part of the bar for incubation/core... 20:27:20 if we're doing it right 20:27:27 and if we're not doing it right, we're screwed anyway 20:27:28 ttx, maybe vote on direction, but need to come back and vote on final specifics after the discussion? 20:27:34 gabrielhurley1: yes that was what I had hoped would be part of the Core definition 20:27:39 markmc: +1 20:27:57 markmc: that sounds good. Are we going to be ready to vote on direction anytime soon, though ? 20:28:11 are we clear on whether core == included in openstack? 20:28:12 notmyname: so in short, I think "diluting shared resources" shouldn't be a criteria for expansive or restrictive core view 20:28:18 ttx, come up with a "direction motion" over the next week on the list, vote next week? 20:28:18 do we need a vote on that point? 20:28:24 markmc: ++ 20:29:06 vishy, more like we don't care about the definition of core, what we really care about is "included in openstack" 20:29:07 vishy: "core" means "the software modules which are part of an integrated release and for which an OpenStack trademark may be used" 20:29:12 mordred: that seems impractical. of course it matters. the shared resources are what define openstack. otherwise we're just some cool tech projects 20:29:31 hey, sorry y'all.. just now back from a dentist appt. 20:29:38 * mordred punches jaypipes 20:29:40 vishy: theer are multiple ways to interpret that "and" 20:29:41 :( 20:29:53 * jaypipes grabs tendon 20:29:54 notmyname: sure they are - but they're also scalable 20:30:08 I think we can add some more projects without the shared resources falling over 20:30:18 unless there is a bottleneck on, say, only having one annegentle_ 20:30:35 may I suggest that we voice our opposition to the two predominant views on the ML thread asap 20:30:42 mordred: I'd never prevent expansion -- I just want scope. I'd like a non-incubated, non-core project to win with a better process. 20:30:43 ttx: ++ 20:30:47 so that they can be formalized in time for next meeting 20:30:56 and we can start the discussion on the long overdue other topics 20:31:02 annegentle_: I think I agree with you - but I'm not sure what you mean 20:31:11 ttx, shall I take a stab at drafting another typo-ridden motion? 20:31:12 markmc: YES! 20:31:28 ttx: based on Alan Clark's email, why isn't the motion just to nominate a few people to participate in the revisiting of Incubation? 20:31:34 we can bounce back and forth variations on the motion 20:31:34 markmc: I hereby name you "Main dyslexic motion writer" 20:31:43 that'll get us closer to something to vote on 20:32:00 annegentle_: well i think we need a unified opinion that those people will represent to the board 20:32:01 annegentle_: we discussed that last week. Nobody can represent the TC since the TC has no official opinion on that yet 20:32:08 ah okay. 20:32:24 * mordred will just pretend to be the voice of the TC at the next board meeting 20:32:25 * annegentle_ thinks back to how easy it was to ask Ryan Lane to be a user advocate 20:32:26 it's a bit hard to pick people if everyone has a different opinion 20:32:42 annegentle_, it doesn't help the strength of the TC if we go into a discussion with the board with multiple disjoint positions 20:32:48 markmc: ++ 20:33:10 #action everyone to voice their opposition to the two predominant views on the ML thread asap 20:33:34 ttx: will you kill me if I mail out a door-number-3 proposal? 20:33:45 mordred: no, it's perfectly alright 20:33:52 ttx: k. just making sure. 20:33:56 * mordred doesn't like angering ttx 20:34:03 is door #3 the mystery box? 20:34:05 I was wondering if those two views were capturing all views 20:34:09 who can resist the mystery box? 20:34:19 since it looked like most people were satisfied abandoning their own view for view 1. 20:34:41 ok, let's move on. Nothing like an IRC meeting to reignite a dead thread 20:34:46 ttx: view 1 is pretty good ... but I just spent a lot of time on a plane, which gave me time to go crazys 20:34:54 * mordred sets ttx on fire 20:34:58 #topic Preliminary discussion: Distro support policy 20:35:02 mtaylor: ok go 20:35:12 great. SO 20:35:20 in direct oppostion to what I just said to notmyname ... 20:35:28 (we'll be back to incubator process upadte at the end of meetign if there is time left) 20:35:33 I don't think we, as a project, can support all versions of all pythons on all distros 20:35:48 what does "support" mean 20:35:53 active CI testing? 20:35:56 yes 20:36:01 and or policy 20:36:03 such as - 20:36:11 so, this is mostly a discussion of where to focus CI resources? 20:36:16 no 20:36:18 and *not* that not supporting it means we rip out all compat code ... 20:36:22 although that enters in to it 20:36:31 but, specifically, there are two things: 20:36:36 a) 2.6 vs. 2.7 20:36:47 we can't really start supporting python3 until we drop support for 2.6 20:36:56 I'm not saying we _should_ start supporting 3 20:36:59 just saying, it's a choice 20:37:02 right, so moving forward makes supporting an older version impossible? 20:37:07 right 20:37:12 BUT 20:37:21 we're sure that 2.6 support precludes starting to support 3.x? 20:37:35 it is possible at this point to write code that is compat with 2.7 and 3.3 at the same time 20:37:48 (string handling is the thing that kills you with 2.6 and/or 3.x<3.3 20:38:03 it's just not possible to write code which will satisty both at the same time 20:38:06 so, what dependencies are blocking us from python3? that might make this a big no-op anyway? 20:38:21 well - fun story - python3 is going to be the default python in the next ubuntu LTS 20:38:22 eventlet, for one. 20:38:46 markmc: python 2.6 is syntax incompatible with 3 (or vice verca:) - you can use 2to3 though 20:38:52 we are *very* tied to eventlet right now, and if that doesn't support python3 and isn't going to in the near future ... 20:38:52 so it's possible that our decision is to continue supporting 2.6 for now 20:38:58 mordred: ^ 2to3 20:39:02 mordred: how would we justify the requirement for python 2.4 in xenserver plugin code? 20:39:11 lifeless: right. without using 2to3 20:39:22 bcwaldon: I believe the xenserver plugin is a special case at the moment 20:39:28 using 2to3 is a bit time consuming 20:39:34 kk, just wanted to make sure everyone knew about that 20:39:41 we don't even come CLOSE to doing 2.4 for the other projects :) 20:39:43 bcwaldon: good point 20:39:56 before we get too tied in this part, lemme bring up part b 20:40:03 which is distro target support 20:40:13 in the past, we have targeted "latest ubuntu" as our dev platform target 20:40:20 and again, is this about CI focus? or? 20:40:38 it's partially about dependent library versions that we as a project assert to support 20:40:49 CI can and will support whatever the project states that it supports 20:40:54 mordred, what I understood roughly our distro support matrix to be 20:40:59 pip install everywhere, problem solved. 20:41:02 * lifeless runs 20:41:02 lifeless: it's not 20:41:09 most recent Ubuntu LTS and RHEL 20:41:19 markmc: RHEL is not part of the projects matrix 20:41:22 latest and previous version of Ubuntu and Fedora 20:41:24 although it could be if we decided to make it 20:41:32 and fedora is also not part of that matrix 20:41:38 mordred, well, it'd be a reason to continue supporting python 2.6 20:41:42 so where's the matrix, heh 20:41:46 mordred, or not moving to e.g. a newer version of libvirt 20:41:50 that's the main question here - what is the matrix 20:42:01 like, what is it actually, rather than what does CI happen to run 20:42:06 Can you see the matrix ? 20:42:15 how can you say what the matrix is and say there isn't a defined matrix? 20:42:21 in the same few sentences? :) 20:42:31 markmc: what I'm saying is, WAY BACK WHEN, it was "latest ubuntu"[ 20:42:36 mordred: The answer is out there, Neo, and it's looking for you, and it will find you if you want it to. 20:42:36 to my knowledge, it has never changed from that 20:42:47 although we've talked about wanting it to 20:42:48 mordred: what I see in production deploys is "supported LTS releases" and CentOS 20:42:52 mordred, ok, I understood that the "loosely defined matrix" had evolved into what I said before 20:43:12 notmyname: totally. there are MANY ways to skin this cat 20:43:25 basically, I do not want to be defining this ad-hoc by the set of things I run in CI 20:43:30 mordred, if it wasn't written down, it was a "rough consensus" - I had assumed the consensus had moved on 20:44:03 because notmyname brings up a great point - there are people running lucid in production still with openstack 20:44:10 do we care, as a body? 20:44:18 what's lucid? most recent LTS? 20:44:21 nope 20:44:23 so what value do we gain in "officially" supporting a distro, and not just leaving it as having distros officially support openstack? 20:44:24 it's the previous one 20:44:25 markmc: 10.04 20:44:32 none of the projects other than swift can even come close to running on it 20:44:39 mordred, ok, but the most recent one was very recently released ? 20:44:40 markmc: best ever. i did it. 20:44:45 markmc: yes 20:44:52 that's why I'm bringing this up, actually 20:44:57 mordred, there's probably a transition point where you support two LTSs, but not for long I guess 20:45:02 we have now hit the point where CI would normally upgrade the build slaves to quantal 20:45:06 however, there are big swift clusters running on Lucid, so that should be considered 20:45:16 but this is the first time we've had a supportable ubuntu LTS during openstack dev 20:45:19 markmc: actually, LTSs have 5 years of support, so the window is quite large 20:45:25 notmyname: ++ 20:45:45 * russellb is curious about the answer to his question 20:45:56 markmc: in fact, it will be possible for a lucid deployment to entirely skip precise and move to the next one and not be out of support 20:45:58 notmyname, RHEL has 10+ years, but I don't think it makes sense to support latest OpenStack on 10 year old RHEL 20:46:03 russellb: I think it's a question of what devs can be expected to care about in their patches 20:46:21 russellb: that's what I mean by "support" 20:46:26 ok. 20:46:32 russellb: not to raise another issue, but that is a great question because openstack doesn't actually provide packages for a distro 20:46:44 if someone submits code, and notmyname says "that breaks on lucid" ... should people care 20:46:54 (I mean, I care about everything notmyname says, but you know) 20:47:26 there is a point where supporting old releases is in conflict with using new libraries 20:47:34 i just don't want to start a distro flame war with people asking why XYZ isn't on our matrix 20:47:38 well, as an comparable example - I think it makes sense to stop caring about RHEL6 maybe 6 months after RHEL7 comes out 20:47:39 indeed 20:47:43 even if that screws RH a bit 20:47:55 which is one of the reasons that 'latest ubuntu' has been the de facto answer so far 20:48:35 I'd be 'happy' to support latest LTS, latest RHEL, latest fedora and latest ubuntu in the CI systems - although I would need some help from redhat to get working redhat slaves up and going 20:48:50 mordred: that sounds like a good set 20:48:58 but I'm not about to start adding complexity if we don't actually want it or just ad hoc 20:49:09 because even if I added that I still wouldn't be supporting lucid for swift 20:49:12 mordred: what value do we get from running on all those platforms? 20:49:22 (although we've discussed adding lucid slaves just for swift because notmyname is cool) 20:49:27 I'm not sure thinking about CI is really getting to the root here 20:49:27 we know much sooner if we break something on platform X 20:49:34 maybe it's really about dependency management 20:49:36 markmc: I agree 20:49:38 but why do we care about that? 20:49:48 we care about having a platform that works for our testing 20:49:49 e.g. a patch to require a newer version of libvirt might kill support for some distros 20:49:55 bcwaldon: that's the question - _DO_ we care? 20:49:58 not that everybody has done their homework before something lands 20:50:04 we should have policy on which distros we support so we can make such a decision sanely 20:50:09 bcwaldon: or do we want to have a dev target and let the distros sort out distro support 20:50:25 (sorry, I might have been phrasing this poorly) 20:50:29 mordred: I think thats much more sane 20:50:48 mordred: there are a ton of windows people that we would be cutting out if we dont run on their platform 20:51:34 bcwaldon: I'd say running on multiple platforms (> 1) helps us determine if a given issue is in our code or in the platform code 20:52:11 there are some decisions we might make about dependencies that would totally eliminate the ability of people to run OpenStack on a set of distros 20:52:11 but maybe we want mulyiple platform only to not be called partial in the choice of the "reference platform" 20:52:12 python version, libvirt version, etc. 20:52:15 ttx: but it also introduces the need to pre-package things before being able to build out deployments and it introduces a bigger set of distro-specific bugs 20:52:17 I know of swift clusters running on bsd and illumos. I'd hesitate to drop "official" support for lucid, but I'm more opposed to simply saying "latest X". I think mordred's list is a good starting point for compromise 20:52:35 and i think it's to the benefit of openstack, for greater proliferation to have as broad of distro support as possible, so finding issues that hurt that as soon as possible is a good thing. 20:52:43 I don't see enough value in more than two distros 20:52:57 bcwaldon: more than X distros? (why 2) 20:53:06 notmyname: to thierry's point 20:53:06 so, the big deployers, AFAIK, are all keen on running tip 20:53:16 bcwaldon: ah, sorry 20:53:20 well, the multi-distro thing ties back to the 2.6 vs. 2.7 thing ... for instance, precise (latest LTS) and quantal (latest ubuntu) do not have python 2.6 20:53:25 perhaps that should be factor in assessing what the project has interest in supporting 20:53:38 RHEL 6 does (and thus CentOS 6) 20:53:44 lifeless: but rackspace are running tip of swift on lucid 20:53:56 mordred: what are they running tip of nova on ? 20:54:03 I think I'm missing one key piece of info here - are we looking to gate on all of these platforms, or just run post-merge testing? 20:54:12 lifeless: dunno. 20:54:18 bcwaldon: 'accept bugs on' I think is the statement 20:54:21 it's a tradeoff thing too - I'd probably welcome dropping 2.6 support, if we were actually getting 3.x support in the short term 20:54:24 lifeless: ++ 20:54:28 bcwaldon: at what point do you say 'that is not a bug' 20:54:39 but dropping 2.6 support and crossing our fingers that it will help 3.x support happen sometime, not so much value 20:54:42 lifeless: I'm not following you 20:54:43 markmc: right but that doesn't seem to be anywhere on the horizon, we're blocked on dependencies 20:54:44 bcwaldon: e.g. syntax incompatible with python 3.3? Thats a bug. Incompatible with 2.4? Thats not a bug. 20:54:50 mordred: to summarize: I think adding a lot more platforms doesn't really help. it's not more fair because there will always be distros out 20:55:10 mordred: so better choose a reasonable/manageable set. Could be one or 2 or 4. 20:55:13 lifeless: I'm talking about distros not providing packages or something, not python issues 20:55:24 well there's CI, and there's what do we care about. can we reject a patch because it breaks platform X. 20:55:40 russellb: yes, thats what I'm interested in getting answered 20:55:41 russellb: absolutely. production is what matters 20:55:50 that's the thing - we can make automatoin decisions with CI _after_ we know what it is that we have chosen to care about 20:55:55 notmyname: 'production' is subjective, though 20:55:56 bcwaldon: same basic thing though is my point. Distro has a too-old python-eventlet -> not a bug, if the version is lower than some N 20:55:57 bcwaldon: I don't think it's just about distro packages 20:56:06 we run mostly from pip anyway (other than libvirt) 20:56:08 Swift will keep working on 2.6, but that doesn't mean it has to be CIed. IMO. 20:56:11 mordred: true, that was just an example 20:56:14 missing entirely is equivalent to too-old :) 20:56:16 redbo: +1 20:56:17 I think it's mainly libvirt + libxml + python-version 20:56:26 redbo: +1 20:56:29 redbo: +1 20:56:39 mordred: running out of time. 20:56:40 bcwaldon: if someone from RAX proposes a patch to swift that breaks softlayers bsd deploy or X's CentOS deploy, it probably shouldn't be merged 20:56:42 if it's a pain, I mean 20:56:50 ok - if we leave 2.6 support for swift out of it 20:56:51 mordred: way forward ? 20:56:58 does anyone ELSE care about 2.6? 20:56:58 notmyname: how can we know that during the gate, though? 20:57:07 mordred: no 20:57:08 lifeless, too old eventlet isn't as big a deal as too old python, though - but hard to define the line there 20:57:11 mordred: bburn it 20:57:12 mordred: well, yes, if we want it to run on RHEL 6 / CentOS 6 20:57:19 russellb: does EPEL have 2.7? 20:57:37 don't know 20:57:38 because something tells me pure RHEL isn't going to work with openstack anyway, right? 20:57:47 sure it does 20:57:52 it does? I stand corrected 20:58:01 ok. then the RHEL/2.6 is still on the table 20:58:09 bcwaldon: heh, so maybe we should have a list of stuff we'll support and test against ;-) 20:58:10