20:02:17 #startmeeting 20:02:18 Meeting started Tue Jul 3 20:02:17 2012 UTC. The chair is jbryce. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:02:19 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:02:24 who all is present? 20:02:28 here 20:02:30 jbryce: awesome as always :) 20:02:38 o/ 20:02:41 \o 20:02:41 o/ 20:02:55 o/ 20:03:21 o/ 20:03:23 that makes 6 20:03:24 7 20:03:26 and 7 20:03:27 great 20:03:32 let's start with bcwaldon's topic 20:03:38 #topic Code for interfacing with proprietary systems 20:03:45 bcwaldon: want to lead this one? 20:03:52 matiu: and we already have a concept of sure 20:03:53 bah 20:03:55 yes 20:04:03 strike that from the record! 20:04:17 20:04:20 * jbryce strikes 20:04:21 thank you, ttx 20:04:23 and jbryce 20:05:01 assuming everyone didn't read the email I sent, the tl;dr here is 'do we accept code designed to interface with non-open source or paid-only systems'? 20:05:20 bcwaldon: what's the subject of the email you sent? 20:05:43 jeblair: it was in response to jbryce's 'Tomorrow's meeting' sent to openstack-poc 20:05:54 jeblair: https://lists.launchpad.net/openstack-poc/msg00552.html 20:06:01 ttx: thanks 20:06:02 bcwaldon: ah, mere mortals are unable to subscribe to that list. 20:06:13 jeblair: yes, I see that now 20:06:24 jeblair: thankfully ttx has your back 20:06:39 it doesn't seem bad, providing there is protection to ensure that openstack is only a decent platform with paid-for software (ie, open core).. But also.. the tests need to be finite.. nbody can be blamed if they break that support, if the tests pass.. 20:06:53 bcwaldon: you mean, accept in core, right ? 20:06:57 yes 20:07:09 the cost of supporting this code weighed against the benefit seems too high 20:07:25 does glance do this already? with s3 for instance? 20:07:25 o/ 20:07:32 bcwaldon: my 2c is that we should only accept code in core that we can test 20:07:37 bcwaldon: we certainly do in quantum. we have code that hits nicira solutions, cisco, and will be accepting code that hits NEC in F-3 20:07:38 for example, if I want to make a sweeping change to all of our glance store drivers, I need to test that I didn't break that 20:07:42 ttx: yes, thats what I'm getting at 20:08:02 our approach is that all unit tests should be able to pass even without the proprietary system being there. 20:08:03 jbryce: there are open-source implementations of the s3 api 20:08:06 (using a mock) 20:08:09 jbryce: so its kind of a special case 20:08:22 danwent: but is that code core ? Or a plugin ? 20:08:40 ttx: its a plugin, but its in the main repo... 20:08:46 maybe i'm confused by what you mean by "core" 20:08:47 our functional tests are a bit weak in glance right now as we depend on a functional system (amazon s3, rackspace cloud files) to be able to run them 20:08:54 danwent: into the openstack/glance repo 20:09:16 ok, yes, that's the same defintion I was using. Our plugins are in openstack/quantum 20:09:33 as would be nova code that hits vmware or hyper-v, I suspect 20:09:34 danwent: main repo, so your case would be in bcwaldon's scope 20:09:51 what is the alternative for where this code would live? 20:10:02 jbryce: in a separate plugin project 20:10:03 jbryce: hosted by the other side of the equation 20:10:03 seperate repo, I suppose 20:10:09 jbryce: or in a different openstack repo 20:10:27 the Hyper-V story shows that what we cannot test ends up breaking 20:10:36 but... 20:10:41 I don't think anybody wants to argue that this code can't exist, it's really just who should own it and be expected to support it 20:10:55 I'm not sure the line in the sand is about "interface to proprietary" 20:10:58 so separate and the user/distro is responsible for grabbing and integrating 20:11:10 jbryce: thats one idea 20:11:11 IMHO it's more about being given ways to test it 20:11:17 bcwaldon: agreed. for third-party code like this to be allowed to be in core, we require that a core dev signs up to maintain it. 20:11:30 ttx: agree 20:11:32 (otherwise its kept out of trunk) 20:11:43 danwent: I don't see how that would necessarily work in practice 20:11:56 danwent: if a different member needs to make a change to that bit of code, how can he move forward? 20:11:58 bcwaldon: My own take would be to allow it, but keep it in a contrib/ (or equiv) directory, and support it to the point that it's tests drive it (through mocks, fakes, or whatever). 20:12:16 so if we are given "stuff" that allows us to gate on tests that interface with a proprietary platform AND a commitment to maintain that code... not sure we should refuse it becuase it interfaces with "something you have to pay for" 20:12:23 bcwaldon: you might end up needing to yank it in the future if it bitrots through ignoring, but I'd personally lean towards inclusion. 20:12:34 bcwaldon: anyone can change the code… the point is that someone is responsible for answering questions about the code, figuring out why a test broke if its unclear, etc. 20:12:36 even if we aren't given tests, we just have to make sure it's isolated 20:12:53 danwent: ok, then we're back to the added cost to development 20:12:57 I suspect on one end of the spectrum you have Hyper6V, on the other end you have Nicira's plugin 20:13:32 bcwaldon: not sure I follow, but according to ttx, it may not be relevant, so i'll stay quite :) 20:13:38 quiet 20:13:47 danwent: please speak up! I'm not trying to shut anyone down here :) 20:14:24 so it doesn't sound like we have a single answer to the question here 20:14:35 I think I can move forward 20:14:55 bcwaldon: no worries 20:14:57 so let's move on if nobody else has anything 20:15:00 i think testability is a good delineator. also committed parties for maintaining. any additional features whether it's proprietary or not are going to have some added cost to the development 20:15:02 ok 20:15:11 jbryce: yes, all things I'm going to take into account 20:15:20 bcwaldon: my gut feeling is that stuff that cannot be freely tested by anyone should be out of core. If we are given ways for anyone on the community to test their code against a proprietary platform, that would still count as "freely testable" in my book 20:15:26 jbryce: +1 20:15:36 ttx: my gut feeling as well 20:15:43 ttx: good explanation of 'freely testable' 20:15:55 yes...i like that definition too 20:16:03 ok. moving on? 20:16:08 +1 20:16:10 #topic PPB to Technical Committee transition 20:16:13 bcwaldon: i.e. I would not consider an outside test platform that nobody has access to to count as "freely testable" 20:16:18 +1 20:16:51 you actually want random devs to be able to test that their code doesn't break yours 20:17:02 anyway, new topic 20:17:11 so i think there are 3 main things to discuss 20:17:47 first...if things proceed on schedule, the foundation would be operational in september. which will also coincide with our next regularly scheduled election for PTLs, etc 20:18:09 i propose that any time before the fall 2012 election that the TC needs to exist, the current PPB serves 20:18:40 it will probably be a matter of weeks that we're talking about and would be simpler than trying to run another ad hoc election for that time period 20:18:44 sounds fair, we don't really have an alternative solution anyway :) 20:18:50 jbryce: +1 20:18:54 +1 20:19:14 ok. that's what we'll write in 20:19:16 ttx: No, an openstack developer should have to touch non-free software unless they want to. The unit tests must be enough IMO, and those that care about it - fix up issues. 20:19:27 second and related to that 20:19:31 oh, i'm too slow. 20:19:49 Daviey: you live 5 min in the past. Must be painful sometimes 20:19:57 jaypipes and ttx were both elected to a 1-year term this spring 20:20:21 i would propose that their terms continue until the spring 2013 election 20:20:32 jbryce: I'd say that depends on the election mechanism. If it is staggered, that would probably be appropriate 20:21:17 especially if we renew the elected seats 2 by 2 or 2.5 by 2.5 20:21:27 ttx: it's the leap second throwing me off.. (sorry for the noise) 20:21:27 (PTLs+5 option) 20:21:37 well i think for any of the generally elected seats (whether that is all the TC or a subset) we should have staggered 1-year terms elected in our regular 6-month cycle 20:22:18 jbryce: I'm ok with it, but I probably shouldn't have voice on that ;) 20:22:22 haha 20:22:28 does anyone object? 20:23:00 ok 20:23:17 the final item is the big one... 20:23:41 9 generally elected or PTLs + 5 generally elected 20:24:07 i've gone back and forth on this several times. i think either can work and they both have pros and cons 20:24:49 in talking to non-PPB members and the emails on the list from non-PPB members, there does seem to be more buy-in to not automatically giving seats to PTLs 20:25:16 jbryce: i'm all in favor of simplicity and removing the need for additional bodies/committees 20:25:24 so i favor PTLs + 5 20:25:24 jbryce: I think it depends on whether the TC has oversight on the projects or not 20:25:32 but i know that several of the PTLs feel very strongly that it would disconnect the projects from the TC 20:25:52 jbryce: if it does, then I'd agree that the PTLs need to be there, so PTLs+5 20:26:20 If the PTLs still have final full control and can ignore TC... then 9 elected sounds better 20:26:23 if the TC doesn't have oversight on the projects, what is it's purpose? 20:26:50 heckj: defines what openstack is and is not. But can't tell a given PTL he is wrong 20:27:08 heckj: I agree with you that it should have that oversight 20:27:18 heckj: but so far, in the PPB setting, it never did 20:27:45 so that's a change. I'm all for it. And I'm ready to accept PTLs+5 if its clear that the TC has oversight 20:28:03 ttx: besides the swift release cycle, i would say that there are plenty of things the ppb has laid out that the projects have had to follow 20:28:14 I think PTL+5 is the best why to insure good communication of TC decisions to the different projects, though I admitly don't have a strategy around what happens as we get more and more core projects. If we think TC decisions are all that relevant for each ongoing project though, this may not matter. 20:28:21 not all of which have always been popular 20:28:28 jbryce: example ? 20:28:30 sorry, missing a NOT in my last sentence :) 20:28:38 new review system 20:28:49 github for code, launchpad for blueprints/bugs 20:29:19 jbryce: if those are representative of TC decisions, then I think PTLs should be involved. 20:29:39 if TC is more about letting a new project join, etc. then maybe they don't need to be involved. 20:29:51 and even with the release cycle, swift has had a release for inclusion in every openstack "release" and we didn't mandate that milestone all had to be coordinated 20:30:03 jbryce: I know we stopped from pushing for specific things precisely because the projects kept final call. Up to the point where we had to threaten to remove the "openstack" label from a given project 20:30:28 jbryce: but that's history. Looking ahead, I'd like to put that in the TC charter 20:30:45 and if everyone agrees with that, I'm fine with PTLs+5 20:31:15 (I still think it will suck as we add more core projects, but life is full of trade-offs :) 20:31:21 ok 20:31:36 do we have anyone else on the side of 9 generally elected seats? 20:31:46 jaypipes: ^ ? 20:32:28 ok 20:32:43 well let's edit the proposal to put these decisions in there as final 20:32:48 i think the only other thing is the election staggering 20:33:01 if TC is only about which projects join, then its scope is too limited to really be effective 20:33:18 if we go with PTL + 5, i'd rather just elect 2 general seats in the spring and 3 in the fall like we've been doing instead of having a .5 month term 20:33:28 .5 year term 20:33:36 .5 month term wouldn't be very long... 20:33:48 i'd volunteer for that one. = ) 20:34:14 lulz 20:34:24 jbryce: we also mentioned that we could have a rep from the user committee 20:34:26 jbryce: sounds reasonable though 20:34:34 so that would make 2+2 20:35:01 jbryce: i think we're just going to have a provision for the user committee to be able to add agenda items that the TC chair will need to recognize (can't just ignore indefinitely) 20:35:31 so we would just run our fall 2012 election with 3 seats for 1-year generally elected terms and jaypipes and ttx would continue to serve until the spring 2013 election 20:35:44 (hands of blue) 20:36:06 firefly! 20:36:41 jbryce: sounds simpler than my "3rd guy gets 6month" hack 20:36:46 ok 20:36:48 done 20:36:49 though it hurts my sese of symmetry 20:36:52 sense* 20:36:55 you guys are all really into this discussion, i can tell 20:37:24 i think that's it then 20:37:31 jbryce: I guess you just need to get to something more contentious... 20:37:36 we'll get these docs all updated 20:37:43 heckj: any suggestion ? 20:37:53 jbryce: I can draft the last version based on that 20:38:03 ttx: not today - saving it up for blowing stuff up tomorrow 20:38:03 ttx: awesome 20:38:12 haha 20:38:16 #topic open discussion 20:38:22 anyone have anything else? 20:38:26 negatory 20:38:29 good here 20:38:33 nope 20:38:36 I have 20:38:50 just under the wire...i was about to stopmeeting 20:38:55 jbryce: at the bottom of http://wiki.openstack.org/Governance/Foundation/TechnicalCommittee 20:39:06 Amendment section 20:39:20 should amendments to the TC charter be approved by the BoD ? 20:39:47 oops...missed that one 20:41:00 (Also there is a bit of choice in the election system, let me know if anyone has string opinions for/against STV/Schulze) 20:41:31 ttx: makes sense to me 20:41:44 ttx: this is not something that the bylaws currently requires 20:42:02 i can give you the wording from the latest draft (which i'm hoping to get on the wiki tonight) 20:42:12 "Except as expressly provided in these Bylaws, the Technical Committee shall determine its process and procedures, provided that such process and procedures must be published in a manner that they are readily accessible to all Members of the Foundation." 20:42:12 jbryce: I guess it depends if the BoD will have to power to dissolve the TC ot not 20:42:20 ttx: they do not 20:42:33 jbryce: I see you've been busy :) 20:43:03 ttx: oui 20:43:10 * ttx puts his collection of trade-offs back in the closet 20:43:25 ttx: i'd say the tc charter should be approved by BoD, but the BoD charter should also be approved by the TC 20:43:33 mutually assured destruction :) 20:43:48 devcamcar: looks like it will rather be mutually assured ignorance 20:44:21 jbryce: if that language stands in the bylaws, obviously amendments do not require BoD approval 20:45:06 ultimately, the membership as a whole (including individual members) could change the bylaws and change the technical committee however they want, but a bylaws amendment is not a board only decision 20:45:49 bylaws amendments in this area are a pretty high bar to cross 20:45:53 jbryce: oh, I see. BoD can't dissolve TC... but it can dissolve the bylaws tat created the TC in the first place. 20:46:13 ttx: no...the bod on their own cannot do that 20:46:19 it requires a special type of vote 20:46:29 works for me 20:46:48 it requires an affirmative vote of the individual members 20:46:52 ok, will remove that "option" at the end 20:47:00 to change the tc portions of the bylaws specifically 20:47:35 ttx: one final question 20:47:52 does it look like cinder is going to hit their f2 milestone requirements to be core in folsom? 20:48:18 jbryce: all lights are green 20:48:30 great 20:48:35 anything else from anyone? 20:48:57 thanks guys! 20:48:59 #endmeeting