20:01:05 #startmeeting tc 20:01:06 Meeting started Tue Jun 21 20:01:05 2016 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:07 o/ 20:01:07 * Rockyg munches on a nectarine in the back 20:01:07 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:10 The meeting name has been set to 'tc' 20:01:14 edleafe: still trapped in your car ? 20:01:17 :D 20:01:18 Hi everyone... Our agenda for today is: 20:01:24 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:01:28 flaper87: Nope, not today :) 20:01:34 A few easy ones to start 20:01:38 #topic Add current house rules for reference 20:01:41 #link https://review.openstack.org/330442 20:01:50 Last meeting I signed up to document the current rules we follow to fast-track some specific changes 20:01:50 * thingee is about to step out of a taxi and run to the nearest desk ... might be MIA for a second 20:02:03 This is obviously a living document so feel free to propose subsequent changes 20:02:13 Has enough approvals to pass now, so will approve unless someone yells 20:02:39 ++ ttx 20:02:45 approved 20:02:52 #topic Update team tags for some projects 20:03:00 #link https://review.openstack.org/329327 20:03:20 This is your regular team diversity tag update, courtesy of flaper87 this time 20:03:23 I just ran the validation script and ttx helped out to double check 20:03:28 Also has enough approvals to pass, so will approve now unless someone screams 20:03:33 w00h000 20:03:50 I won't count that as a scream 20:04:05 you should clarify the type of scream next time, i suppose 20:04:09 it's pure joy coming out of my lungs 20:04:11 russellb: ++ 20:04:12 a scream of opposition 20:04:16 haha 20:04:23 russellb: can we write up a definition of screams and a categorization system for them? 20:04:27 approved 20:04:30 and tag them! 20:04:31 #topic Remove Packaging-Deb project team 20:04:34 mordred: sounds like the only way to move forward 20:04:36 #link https://review.openstack.org/329430 20:04:40 mordred: you might call it a scream catalog 20:04:43 jroll: ++ 20:04:46 scream:opposed-to-patch 20:04:48 So... I proposed this because Packaging-Deb is the only official project team without any visible activity 20:04:56 and we now require project teams to show some activity before we accept them 20:05:08 dropping to unofficial status seems reasonable 20:05:12 I understand that the team will need some infra support, and that being official facilitates prioritizing that up 20:05:12 until they have activity 20:05:16 I'm not in favor of removing this as the project team in question is currently in the middle of good-faith effort to implement the needed things 20:05:25 i also see no harm in keeping it if they're trying to mobilize 20:05:26 But I'm not (yet) convinced that infra support is a prerequisite before the team can start working on the OpenStack side 20:05:35 it would be super easy to re-add but i'll defer if someone says they are making the effort 20:05:36 which is the result of the discussions that were had on this very topic at the summit 20:05:41 mordred: any reason why the git repositories are not migrated from git.debian.org ? 20:05:51 I see there is a Mirantis server building packages from pushes to git.debian.org, I suspect it could read from git.openstack.org instead 20:05:54 * notmorgan assumes they are w/ the commit message and mordred's comment 20:06:05 mordred: any discussion on mailing lists? Any IRC meetings for the project? 20:06:06 because migrating them without the testing support would be a downgrade, and we're currently working on adding the things we've specced out to make that make sense 20:06:26 AJaeger: zigo and fungi have been working in the infra channel, also pabelanger and I have been involved 20:06:40 mordred: why would it be a downgrade ? I'm pretty sure the Mirantis CI can read from git.openstack.org just the same 20:06:41 it sounds like there's work here, it's just not easily visible because of where it's happening? 20:06:50 dhellmann: yah 20:07:02 it's work being done by the project team in question it's just happening in infra land at the moment 20:07:08 we can ping zigo to see what's needed i guess 20:07:08 If there's work going on, I'm good with deferring the removal for a bit longer 20:07:09 wfm then 20:07:14 I'm here. 20:07:14 dheI'd argue it happens outside of openstack, in git.debian.org 20:07:17 mordred: sure, but do we want something as an openstack project that doesn't have an artifacts in openstack git? 20:07:33 so - debian packaging is a bit of a beast 20:07:43 ooh there's detailed notes from zigo in the review 20:07:47 and getting infra able to have artifacts for it at all is non-trivial 20:08:00 mordred: I don't see that as a prerequisite though 20:08:03 the work required is understood and under way 20:08:10 what problems would it cause to the packaging-deb team if we approve this patch ? 20:08:17 right, i don't necessarily disagree with removal from the governance list (tc oversight doesn't really provide direct benefit to the work going on now, nor would it be hard to re-add later), but there is work being done 20:08:28 ttx: So, we would just use gerrit, but packages wouldn't be published? How do you expect to even try to install the produced packaged then? 20:08:31 Just want to lay out what the downsides of this patch for the debian team are 20:08:41 zigo: how is that different from the current situation ? 20:08:51 i think packages could also be published without it being in the governance list 20:09:07 ttx: I've explained it on the review. Currently, each git push produce a package, and then we can run a full all-in-one install of OpenStack and run tempest. 20:09:12 We don't have this in OpenStack infra. 20:09:15 I would actually not be in favor of openstack publishing packages without it in the governance list 20:09:35 We can only build openstack-pkg-tools, and because that one isn't published in a Debian repository, other packages can't use it as a build-dependency, and therefore cannot build. 20:09:36 zigo: My point is, today you're using git.debian.org and using Mirantis CI to build packages. Tomorrow you could use git.openstack.org and Mirantis CI to build packages, at least temporarily 20:09:38 mordred: i'm 100% behind that stance 20:09:38 I think that is not in keeping with how the other projects work - and distro packages by nature are things people will start to rely on no matter what we say 20:09:45 the reason we originally pushed to have this be "official" was that we were still in the days of the stackforge/ git namespace and infra didn't want to see a hundred repos need to be renamed to the openstack/ namespace once it applied to be an official project-team 20:09:56 mordred: not sure if I necessary agree with that. distributions can produce their own packages without our involvement 20:10:00 ttx: How would I trigger the build?!? 20:10:02 people are doing stuff, do we want to encourage those people to keep doing more stuff close to openstack? i think yes, so let's just leave it be. 20:10:04 although it would be nice to part of the community 20:10:14 thingee: I was responding to fungi saying that _We_ could publish packages for it without it being official 20:10:17 zigo: how do you trigger the build currently ? 20:10:17 zigo : how do you do it now? 20:10:18 thingee: i don't want *us* to publish packagses uniless they are official 20:10:18 you can't stop distributions doing their own thing 20:10:27 dhellmann: I have a git recieve hook. 20:10:28 notmorgan: ++ 20:10:35 notmorgan: so, debian publishes them ... 20:10:38 what am I missing? 20:10:40 thingee: thats all. not that it has to be official for someone to publish packages. 20:10:40 I'm all for having a better solution and move to gerrit *NOW* if someone has an idea. 20:10:54 well if you're not in the governance... sounds like you're not official 20:10:57 so - before we re-engineer the solution in this meeting 20:10:59 zigo: i think it's fine to defer the removal for now. 20:11:04 notmorgan: ^ 20:11:22 you're just like a lot of things. part of the ecosystem 20:11:24 Look, I totally agree with the endgame. I just don't get why you can't migarte teh git repositories now. Nobody answers that question 20:11:25 mordred : yeah, I was just trying to understand why moving would break things 20:11:29 As I said, if there's work going on, I think we could just defer the removal for a couple of months 20:11:42 thingee: if we have a project publishing packages under the auspices of openstack, i'd rather it be an official project than not. 20:11:43 ttx: I'm purposely not answering that question because at the moment there is a plan to get things migrated 20:11:45 dhellmann: +1 ... I don't think this has been answered yet 20:11:46 +1 to defer removal for now. but would like to hear a plan that works soon-ish 20:12:04 I don't think the removal would impact the work going on but keeping it for a couple of more months won't hurt for sure 20:12:09 (here, sorry I'm late) 20:12:10 notmorgan: totally, but you can't stop the world from publishing their packages 20:12:18 thingee: that's not what any of this is about 20:12:18 thingee: if it's just storing the data in git, sure, but this is more of a using infra to publish to an official repo. 20:12:22 it feels like a catch-22 if we're avoiding publishing packages unless the project is an official part of openstack, but avoiding making it official because work to build the current packages is happening outside openstack infra 20:12:22 notmorgan: so simply, you're official if you're in this governance list 20:12:27 if you're not, you're not official. 20:12:27 it feels like the work could happen on openstack side with no loss with just a s/debian/openstack/ on the Mirantis CI side 20:12:42 ttx: That's what I've been trying to do. I'm sorry if I'm not good enough at it using the current OpenStack infra, but I think everyone from infra can vouch for the fact I've been trying for the last 12 months 20:12:42 thingee: nothing is about stopping the world from publishing packages ... the question about package publication is about whether or not Infra publishes a package repo 20:12:48 mordred: ++ 20:13:07 mordred: thingee notmorgan can we go back to discussing the patch and not who can publish packages? 20:13:08 I do not believe that infra should publish openstack packages without the associated project being official 20:13:09 well based on ecosystem rules, infra could still be part of things. 20:13:13 I don't think this work is there yet 20:13:17 mordred: +1 20:13:23 mordred : +1 20:13:33 The thing about publishing packages is *NOT* about having them accessible for the general public. 20:13:38 mordred: we publish plenty of tarballs for projects not official 20:13:42 It's about having them available as build-dependencies to build other packages. 20:13:45 ttx: but we do not publish docs for them 20:13:52 and yes - what zigo just said 20:14:04 i agree that people will come to rely on whatever we publish, no matter what we say about it being unofficial, but people come to rely on tarballs and git repos of unofficial projects we publish today as well 20:14:11 we need a package repo available so that we can cross-test inter-dependencies of the packages with the rest of the things that are also in master 20:14:17 ttx: sounds like we may need to revisit things of infra's involvement then if there is some consensus around publish things and infra involvement 20:14:20 hmm, ok, I can buy that. I still don't understand why you can't migrate the git repositories today though. 20:14:35 mordred, zigo : I think the thing that bothers me here is that we have an official project using a bunch of private resources still, and that makes it impossible for someone not involved to see what's going on at all. Which, while I don't think anything untoward is going on, doesn't set a good precedent. 20:14:49 ttx: no hooks - he could if he watched the gerrit stream instead of the direct git hooks 20:14:59 it sounds like the mirantis ci doing continuous package builds would need some reworking to switch from some sort of web callback to consuming gerrit events 20:15:00 dhellmann: I TOTLALY agree and I would not do this this way if I had it to do over 20:15:03 notmorgan: Ah. I see 20:15:06 ttx: it is doable, but may be throw-away effort in the long term 20:15:13 dhellmann: but right now, I do not think it helps anything to temporarily remove the project from governance 20:15:14 notmorgan: ok, thanks you 20:15:21 ttx: since zuul/etc will handle that for him :) 20:15:30 dhellmann: So, mostly, you're saying we don't have enough visibility, right? 20:15:43 mordred: ok, morgan gave mae a good reason for deferring 20:15:47 mordred : I mostly agree. Still, it would be nice to see some sort of public activity. Where is the coordination of this work happening? 20:15:51 so my comment in the review of not immediately voting for things is because mordred has a history in the community of coming through with things. what is the timeline of things actually migrating? 20:15:52 dhellmann: would a status update on the ML cover it? 20:15:58 dhellmann: like... semi-regular? 20:15:59 mordred: dhellmann: I think there's a question there, is the project team doing stuff using private resources, or is that mirantis doing those things and the project team is working toward moving all of that? 20:16:04 I almost feel like it's the latter 20:16:04 dhellmann: right now in #openstack-infra 20:16:20 jroll : yeah, I think you're right. 20:16:35 jroll : it's just poor zigo doing all the work there :) (not mirantis!) 20:16:35 vs strictly irc, i'm ok asking zigo to provide progress/updates to the ML every so often so we have clear visibility to point at vs "irc logs"? 20:16:36 ultimately, i suspect a lot of this would be solved (or wouldn't have come up) if the governance change to add all those package repos had depended on a project-config change to create them first 20:17:01 fungi: possibly 20:17:02 fungi : yes, in future I think that's a good way to arrange things 20:17:06 dhellmann: ++ 20:17:08 we have more policy/process/expectatins around that now, but didn't back when that governance change was merged 20:17:13 er, expectations 20:17:31 notmorgan : yeah, some mailing list updates would help make the project seem more alive for those of us not reading #openstack-infra all day 20:17:34 zigo: would you mind sending a quick status update to the ML on this process every so often? 20:17:38 zigo: it would help :) 20:17:43 What you guys have to realize as well, is that what you call "mirantis CI" is just a git hook to build packages using Jenkins. So, we go in interrative ways with "git push" until it builds correctly on all target distros. That's *VERY* far from the Gerrit workflow, where things are checked, and then patch approved. I don't think we could just move from git.debian.org to gerrit without having the full blows and wissels 20:17:44 because of that. 20:17:50 yeah, that's a good point for next time, on the depends-on 20:17:54 zigo: and hopefully isn't too much extra effort while the -infra stuff is being worked on. 20:18:01 notmorgan: Ok, will do. 20:18:07 zigo: fantastic. :) 20:18:09 zigo : ok, well, it's pretty easy to make jenkins watch a git repo instead of using an in repo hook 20:18:28 zigo: there is a gerrit-jenkins plugin you can use to trigger jobs from the gerrit event stream, probably extrement similar to what you already have, but we can discuss that elsewhere 20:18:29 dhellmann: right - but then we're pushing untested commits into openstack repos 20:18:41 er, extremely 20:18:45 mordred : are they being tested in their current repos? 20:18:45 because the current process is to push and test and push and test until it turns green 20:18:50 dhellmann: only post merge 20:18:55 I see 20:18:58 mordred: zigo asks for an extension of the grace period until end of August, does taht sound reasonable ? 20:19:02 ttx: yes 20:19:07 ttx: yes 20:19:07 ttx: wfm 20:19:12 ttx: I think we can have made the progress we need by then 20:19:13 yes 20:19:14 yes 20:19:16 I can live with that 20:19:20 mordred: hi, still asking about the timeline for things to migrate? 20:19:21 from an infra perspective, seems like a reasonable request to me 20:19:21 +1 from me 20:19:21 \o/ 20:19:23 ok, well, I don't think we need to actually change anything aside from having some public discussion on the ML about where things stand, so zigo or mordred please post that 20:19:25 +1 20:19:45 thingee: luckily, even though there are a lot of repos, the process is the same for all of them, so once we have it done for one, we have it done for all 20:20:05 dhellmann: ++ 20:20:05 mordred: last famous words 20:20:06 #agreed grace period for Packaging-Deb extended to end of August 20:20:09 flaper87: :) 20:20:33 mordred : carved some time in your new gig for this? :) 20:20:33 #action zigo or mordred to update the list on status, if only to explain to contributors wanabees where to go to participate today 20:20:59 because ultimately that's my concern 20:21:01 dims: of course - debian packaging is very important to my new overlords :) 20:21:03 * amrith makes a note to take present for mordred to ann arbor next week 20:21:10 :) 20:21:12 mordred: heh 20:21:12 We say we have a team, but there is no clear way to join it 20:21:16 BTW, would you feel better if we moved out of OFTC in #debian-openstack to something in freenode under #openstack-something? 20:21:18 ttx: agreed 20:21:27 ttx : yep. agree 20:21:31 zigo : yes 20:21:34 zigo: that would definitely help 20:21:36 zigo: would be nice to be here on freenode. 20:21:36 zigo: that would be a good start 20:21:37 I can arrange that. 20:21:38 will have to do it anyway 20:21:42 What channel name do you propose? 20:21:49 #openstack-debian ? 20:21:49 #openstack-deb-pkg ? 20:21:49 zigo: openstack-deb-packaging ? 20:21:50 openstack-debian 20:21:57 anyof those 20:21:58 or what thingee said 20:22:00 Ok. 20:22:00 zigo: ++ 20:22:07 * fungi votes we just move the openstack channels from freenode to oftc instead 20:22:12 ++ 20:22:16 also duplicating/moving the content in that alioth page to the wiki or some doc repo would help too 20:22:16 LOL fungi 20:22:17 zigo: or at least have the channel you currently use documented in the governance repo 20:22:19 fungi: hehe 20:22:19 fungi: heh 20:22:23 stole it from mordred 300ms later 20:22:28 warning - we've hit a max at irc channel registrations and are still working on a solution to that 20:22:42 zigo : please add the channel to the team description in the governance repo when you have it set up 20:22:47 so, you konw, if the irc channel takes a bit to be fully integrated, it's also not zigo's fault :) 20:22:49 mordred: only for gerritbot, not for registeration overall 20:22:49 mordred: what's the max? 20:22:49 fungi: I can arrange help from the OFTC IRC ops if we move there! :) 20:22:50 mordred: a second bot! 20:22:56 mordred: :P 20:22:57 mtreinish: 120 20:23:05 OK, I'll abandon the review 20:23:06 notmorgan: yah. a second bot is, in fact, the answer 20:23:11 mordred: sadly =/ 20:23:16 IIRC there's even already a channel for it. 20:23:16 AJaeger: yah. that 20:23:17 freenode was not ready for the big tent 20:23:18 notmorgan: patches welcome ;) 20:23:20 zigo: yep, so can i (and we've talked to them before) but moving all of the openstack community is no small task. we've considered it more than once 20:23:22 That I already added... 20:23:52 * thingee misses the days of just openstack-dev 20:24:20 clearly we should self host a hip new chat thing 20:24:23 i recommend hanging out in the same channel on both oftc and freenode just because many in the debian community may expect to find you on oftc 20:24:33 anything else on that topic ? Anyone disagreeing on extending the grace period ? 20:24:35 russellb: i hear we should just use slack 20:24:43 russellb: actually - turns out hipchat and slack both have user max limits 20:24:47 ttx: let's change topic :) 20:24:47 that openstack is in excess of 20:24:50 * ttx empties a bucket of eels on notmorgan 20:24:51 i actually reside in equivalents of many of our more popular channels on oftc in case we ever need to make an emergency move 20:24:53 oh? 20:24:56 how about rocket.chat 20:24:58 russellb: yup 20:24:59 anyway, moving on 20:25:02 they max out around 2k users 20:25:10 weak 20:25:12 #topic Add 'type:horizon-plugin' tag 20:25:13 yup 20:25:14 mordred: pfffffffffffffffffffffffffffffffffff.... peanuts 20:25:22 focus, team, focus 20:25:26 #link https://review.openstack.org/329479 20:25:29 this seems like an easy +1 20:25:32 * dhellmann thinks of peanuts 20:25:32 TL;DR: This is a new type: tag for deliverables so that we can describe which ones are Horizon plugins. 20:25:42 russellb: don't jinx it. 20:25:44 +1 to this one! 20:25:45 was missing a couple +1s last time I looked 20:25:58 there are 7 now 20:26:03 tag very much appreciated 20:26:06 Looks like we have the number now 20:26:21 Alright, approved 20:26:24 ttx: should we propose similar tags for other plugin repos? (like devstack or tempest) 20:26:40 mtreinish: we looked into that -- there aren't enough to justify it right now 20:27:03 (from a release management perspective) 20:27:07 mmh, it's weird there aren't enough devstack plugins 20:27:12 I mean, surprising, mostly 20:27:14 if you count the repos that are both service and plugin then there are 20:27:14 shoudln't prevent anyone from proposing though 20:27:15 mtreinish : eventually, when there are more examples of each 20:27:39 david-lyle : from a release perspective, if it's in the same repo, we only care that it's a service 20:27:41 the problem is one repo is now being used for 3 things 20:27:51 ttx, dhellmann: well tempest has very few standalone plugins (most went in repo) but devstack should have a fair number of them 20:28:05 dhellmann, for release true, for anyone else it's confusing 20:28:06 david-lyle: I guess the tag describes deliverables that are standalone plugins 20:28:11 david-lyle : we're looking for ways to organize the content of releases.openstack.org to make it easy to find the deliverable you're looking for 20:28:31 mtreinish : are they in their own deliverables (not repos)? 20:28:43 Also the horizon plugin names were pretty inconsistent, so that makes sure users can identify them all 20:28:56 dhellmann: http://git.openstack.org/cgit everything that starts with devstack-plugin as a start 20:29:31 there might be others there too (I'll do a ctrl+f for devstack) 20:29:31 mtreinish : are those things that users want to download and use? or are they developer tools that aren't released? 20:29:50 for releases.o.o we only care about things that are actually being released 20:30:03 dhellmann: there was nothing in the horizon tag about releases (unless I missed that) 20:30:12 This is a bit orthogonal to the topic, maybe we can discuss that in open discussion if there is time left ? 20:30:15 this isn't about categorizing everything we have, it's about categorizing things that show up on the releases site 20:30:19 ttx: ++ 20:30:30 we should have some time 20:30:33 hopefully 20:30:34 mtreinish : interesting angle 20:30:43 #topic Add 'level playing field' requirement 20:30:49 #link https://review.openstack.org/329448 20:31:00 So... I think that the value "OpenStack" provides, as an open source organization, is to create workspaces where open collaboration across multiple organizations can happen 20:31:12 To recognize that, I'd like us to say that an official "OpenStack project" should be something anyone from any organization can join and contribute to as an equal 20:31:26 And if a project team is proposed in the future with such a scope that developers from a specific organization (or a closed set of specific organizations) have a structural advantage, we should not make it an official OpenStack project 20:31:41 It can be an unofficial project alright, but we should limit the "official OpenStack project" label to things that are level playing fields 20:31:41 I agree that goal and sentiment 20:31:46 +1 20:31:52 +1 20:31:54 yup 20:31:57 how does this apply to things like oslo.vmware or oswin ? 20:32:05 it applies per project team 20:32:06 now it's just a guideline, and we'll have to interpret it, but I think it's a statement we need to make 20:32:09 ttx:what sparked this? Anything specific? 20:32:14 so, to Oslo 20:32:16 not oslo.vmware 20:32:19 maishsk: no 20:32:22 +1 but sdague has a good question 20:32:31 maishsk: it's more preventive 20:32:31 russellb : right, that was my observation on the review 20:32:33 similar to it applying to Cinder overall, not Cinder drivers 20:32:34 I like russellb's take on that question 20:32:37 I think ttx replied to that on the review 20:32:42 sdague: I answered on the review 20:32:43 cinder and oslo are the projects 20:32:47 russellb: +1 20:32:51 ttx: is there any relationship with the single vendor diversity tag? 20:32:57 winstackers is a dedicated team 20:33:02 if oswin wants to be under big tent then they will run into trouble 20:33:09 https://github.com/openstack/governance/blob/7ef0cf16a761c947891504f15f5463adcf99cf07/reference/projects.yaml#L4183-L4208 20:33:14 sdague: ah, yes, that may get hit by this 20:33:15 sorry 20:33:15 mtreinish: I think that's just a result of giving your organization an advantage in a project? 20:33:18 oslo.vmware is part of Oslo which is a level playing field. We judge project teams, not specific deliverables 20:33:21 poor diversity 20:33:31 sdague: but are they all at microsoft and are microsoft people the only ones who really could conceivably join? 20:33:36 that would be my litmus test I tihnk 20:33:38 for some, not all 20:33:49 winstackers, yes, we'll have to look into that one if someone can point to an unfair advantage 20:33:56 http://stackalytics.com/?module=winstackers-group 20:33:57 i'm really not that concerned though 20:34:04 thingee: right, so does that mean having the tag mean it's not a level playing field? 20:34:13 you need windows licenses to be effective with it 20:34:13 it's clearly about windows integration, not creating a whole full project / API that only works on windows 20:34:17 some single-vendor teams are just single-vendor because nobody else happens to care- not because there is a structural advantage to people at the company in question 20:34:18 meh 20:34:25 mtreinish: I don't think so. I meant to say it *could* be the result of poor diversity 20:34:32 sdague: I'm not sure anyone in winstackers benefits from a structural advantage though 20:34:33 thingee: ah, ok 20:34:37 anyway, it's an edge, and it's fine to have judgment on edges 20:34:45 sdague: ++ 20:34:45 sdague: definitely an edge 20:34:46 sdague: I think it would be hard to argue that windows licenses are a scarce commodity, much as I don't personally have any 20:34:56 and yes - wonderful edge to discuss 20:34:59 sdague: probably the only one in the current project list on the edge 20:35:22 ok, it's close enough to nova, that I figured I'd raise it, as it's critical for hyperv support 20:35:27 mtreinish: I think poor diversity could also happen when one company has an interest in something in openstack, but none competitors/others aren't interested at the same time. 20:35:28 mtreinish: so that's an interesting question 20:35:29 I don't think this is a tag, it's a preventative measure to avoid a project governance application we wouldn't accept? 20:35:40 ttx : mordred : do we want to say "type:service"? 20:35:46 given that nova doesn't have out of tree driver support, but some of the in tree drivers use support libraries for complex logic 20:35:48 mtreinish: basically, most non-level playing fields are single-vendor as a result 20:35:59 annegentle: more, clearly defining grounds of why the application wouldn't be accepted 20:36:09 mtreinish: BUT to me it's a transient state, not an end goal 20:36:12 annegentle: less about "preventing", some maybe, but others would need assement 20:36:21 notmorgan: +1 20:36:25 oswin exists just to serve nova, cinder, etc 20:36:30 I talked ttx's ear off about this, that I personally find many many more social structures can prevent a level playing field, but if this is one measurable barrier to entry then I'm ok with documenting it. 20:36:58 annegentle: i think winstackers is the shining example of needing assesment (and probably would be ok) but could be hit at face value. 20:37:03 and they requested oslo as a home to start with and we declined 20:37:07 annegentle: yes, this one is about structural advantage to specific organizations due to the way the project team scope is set up 20:37:18 but there are other forms of discrimination 20:37:23 is the thinking that this is really what applied in the poppy situation? 20:37:34 sdague: for some of us yes 20:37:39 because unless you have a big CDN contract, the project isn't useful 20:37:57 sdague: this is about contribution, not usage 20:38:02 isn't this also in anticipation of the fallout from the neutron stadium dissolution? 20:38:18 dhellmann: is it? I guess that was part of my question for examples 20:38:25 sdague: nobody in the Poppy team had an unfair advantage against others 20:38:49 sdague: so it was a level playing field 20:39:12 sdague : maybe that's just me? I think having this sort of rule in place will be useful when all of those driver teams start thinking about what to do next 20:39:24 my concern is that the wording is so vague and subjective that this provides no real benefit over the current subject and vague criteria which is the TC makes a judgement call 20:39:31 dhellmann: IF the stadium dislocates and BigCorp wants to set up a project team to host the development of their driver which connects to pricy proprietary hardware... would fall into that new rules yes 20:39:42 ttx: right 20:39:55 I'm fine if this is about not having 20 official vendor specific projects for networking 20:39:59 ttx: you just answered the question I was typing :) welldone sir 20:40:03 sdague: ++ 20:40:04 but, I'd be more fine if we just said that 20:40:11 david-lyle : how would you make this more specific? 20:40:16 david-lyle: I'd very much like each one to be carefully decided on a case-by-case basis by the tc. 20:40:19 instead of the vague level playing field language 20:40:34 sdague: I think saying that openstack projects present a fair open collaboration space is useful 20:40:37 david-lyle, I don't believe it would be easy to make this more specific without calling out specific projects by name. 20:40:44 this language doesn't seem vague to me, I don't understand why it seems that way to others. 20:40:46 but I would love some alternate verbiage. 20:40:56 dhellmann: I agree 20:40:59 dhellmann: ++ 20:41:01 the language strikes me as pretty clear, and a very solid basis to interpre on. 20:41:20 yes, it is pretty clear wording. Thanks to amrith 20:41:31 thx ttx 20:41:36 the first iteration was much more vague 20:41:42 dhellmann: Agree 20:42:00 this is this is straight forward enough to cover basing decisions on it. 20:42:01 does this apply to fuel? or tripleo, which are the product installers for single companies? 20:42:02 imo 20:42:18 sdague: fair question. 20:42:20 sdague: that's a good question 20:42:23 sdague: do I need special stuff to contribute to fuel? 20:42:24 sdague: why would it ? 20:42:33 sdague : it would apply to any project driven mainly by one company where that company pushed contributors from other companies out in some way 20:42:37 "The project shall not benefit a single vendor, or 20:42:37 a single vendors product offerings" 20:42:38 in theory, from a technical standpoing, everything is there that you need 20:42:47 russellb: exactly 20:43:04 dhellmann: Not just pushed out, but provided barriers to even enter 20:43:05 sdague: you can take it and start your own Mirantis. No secret sauce 20:43:08 politics preventing cooperation more than technology 20:43:12 I don't think neither of them benefit a single product/offering. 20:43:12 mestery : yes, that 20:43:22 russellb : right 20:43:28 * amrith tries to parse flaper87's double negative 20:43:28 russellb : well, both 20:43:29 * dims listening intently 20:43:36 barriers to entry come in lots of forms 20:43:44 amrith: crap, I knew I shouldn't have done that! :P 20:43:46 sdague: I would expect the TC would make this argument as ttx mentioned if it was brought up. just like any other project on a case-by-case basis 20:43:52 ttx: does this patch landing mean any changes to the current projects list? I think not but want to be sure. 20:44:00 annegentle: not unless you propose one 20:44:02 annegentle: yes current list 20:44:06 amrith: thanks for pointing out. I was like: "either or neither... o well" 20:44:21 annegentle: but as ttx mentioned, it would have to be proposed and discussed 20:44:24 thingee: ttx ah. okay. 20:44:47 This has enough votes to pass if I vote for it. Anyone objecting ? I bet we'll have a fair number of abstentions waiting for the first case-by-case happening 20:44:58 does this force any additional conversation about how individual projects are governing their own drivers? 20:44:59 sdague : one barrier that i have heard is that "mirantis has all the fuel engineers, so i am not able to hire folks to work on fuel related stuff" 20:45:19 dims: that's pretty weak 20:45:22 Well, I like merging what we have as a good starting point, and see how we go 20:45:31 dims : that's only a barrier if those engineers refuse to work with anyone who doesn't work at mirantis 20:45:34 annegentle: that would be completely up to them and their relationship with the vendor/drivers 20:45:43 with their* 20:45:48 I still have a concern about interpreting the lack of driver example... 20:45:49 russellb : dhellmann : right, giving an example that i heard recently 20:45:57 I'm not abstaining, I'm still thinking... 20:45:59 some projects have made it pretty clear they want nothing to do with their drivers, and to focus purely on the interface they provide. 20:46:22 dims conversely if you wanted to contribute a fuel plugin, the fuel team is welcoming. so I submit to you that it is an open and level playing field 20:46:29 i wish we had a bit more consistency around driver approach, not sure why the battles have to be so different across projects 20:46:30 amrith : agree 20:46:32 but that's for another day ... 20:46:35 thingee: right. okay. 20:46:37 russellb : ++ 20:46:39 russellb: +1 20:46:45 OK, I'll approve it now 20:46:48 ttx: ++ 20:46:49 russellb: it isn't easy to understand from outside-in 20:46:56 russellb: so, yeah +1 20:46:59 unless someone else wants to formally register their vote 20:46:59 for sure 20:47:18 not easy to understand from the inside-in 20:47:33 alrigth approved 20:47:40 #topic Open discussion 20:47:47 I have 3 topics 20:47:50 no TC meeting next week? 20:47:52 So no meeting next week? 20:47:53 We'll have most TC members in Ann Arbor next week for the leadership training, so we'll skip that meeting 20:47:54 :) 20:47:56 for those interested, https://review.openstack.org/332465 will reflect the new type:horizon-plugin tag 20:47:59 (jinx) 20:47:59 Next meeting on July 5th 20:48:16 We have (ahem) a small delay in the P/Q naming process 20:48:16 ttx: i am going to probably skip jul 5th, fwiw. 20:48:22 +1 skip 20:48:32 and +1 to skip next week. 20:48:40 https://review.openstack.org/#/c/332193/ 20:48:49 I'll approve that delay since at this point it looks like a typo 20:48:50 july 5th is often a holiday in the US 20:48:54 depending on org 20:49:03 sdague: yeah and a lot of people may take the day off as well 20:49:07 sdague: food coma recovering from bbq 20:49:10 sdague: since it'll be a tuesday. 20:49:12 notmorgan: sure, that too :) 20:49:18 post a 3 day weekend 20:49:24 Let's skip next week and see if we should skip the week after over email as we've done in the past 20:49:25 or reattaching digits blown off by small explosives 20:49:26 sdague: ah. ok, please add yourself to the absentee list if you can't make it 20:49:32 ttx: will do 20:49:35 and I'll skip it if we can't have 8 people around 20:49:39 fungi++ 20:49:43 * gothicmindfood hands fungi a safety sparkler 20:49:53 gothicmindfood: they make safety sparklets? 20:50:19 notmorgan: they're safe as long as you don't stick them in your eye. 20:50:19 mtreinish: we can continue the discussion on other potential type:plugin* tags if you want 20:50:21 notmorgan ... https://play.google.com/store/apps/details?id=nl.anndroid.sterretje&hl=en 20:50:25 gothicmindfood: those sparks give a pinch feeling. that's not safe :( 20:50:37 gothicmindfood: what about eating them? 20:50:47 ttx: sure, we can 20:50:51 notmorgan: tastebuds are overrated 20:50:57 gothicmindfood: what about making your friend eat them? is that safe? 20:51:05 are tempest and devstack plugins likely to end up on releases.o.o? do they generally tag releases at all? 20:51:13 * jroll will not be celebrating july 4th with mordred and notmorgan 20:51:24 is the board meeting Tuesday of next week? 20:51:32 fungi: some tempest plugins do, like the designate plugin does 20:51:32 fungi: I'd suspect people will branch devstack plugins 20:51:32 jroll: there'll be PIE though 20:51:33 annegentle: yes 20:51:34 fungi : I think not, but I'm not opposed to having the type tags if others want them for some reason. 20:51:34 ttx, you had 3 things? 20:51:34 mtreinish: I guess what made type:horizon-plugin compelling is that it answered a question users had about deliverables, since those need to be found to de deployed alongside services 20:51:43 amrith: 3rd is ^ 20:51:44 annegentle: ruh roh - did we schedule training during a board meeting? 20:51:46 fungi: devstack plugins get branched normally (if people remember to) 20:51:50 gothicmindfood: yup 20:51:50 mordred: I'll need to eat and run then :D 20:51:54 only affects mordred 20:51:57 Yeah 20:52:03 gothicmindfood: might have been the other way around 20:52:13 mordred: sandwiches > than board meetings 20:52:19 gothicmindfood: +1000 20:52:21 truth 20:52:24 ++ 20:52:28 gothicmindfood: I HAVE EATEN ONE OF THOSE SANDWICHES 20:52:39 * gothicmindfood is looking forward to seeing leadership training attendees next week! 20:52:49 have fun you all at Ann Arbor. wish i could make it 20:52:50 ttx: was it? I think people have questions about all the things. Not just those which are deployed 20:52:51 mtreinish: tempest/devstack plugins are more dev-oriented so slightly less useful downstream. But I wouldn't object to them 20:52:54 * mordred is looking forward to seeing michigan in the summer 20:53:01 gothicmindfood: mordred I want one of those sandwiches 20:53:11 flaper87: you will eat at least one 20:53:11 gothicmindfood: mordred at least one 20:53:14 ttx: well I can propose something and we can bikeshed from there 20:53:32 ttx: are there other types of plugins besides those 3? 20:53:49 *others worth adding a tag for 20:53:51 mtreinish: I proposed that tag because I wanted to be able to answer that question on releases.o.o. Like dhellmann said, those tempest/devstack plugins are not really released so that doesn't help there, hence why I skipped them 20:54:01 fuel plugins ! :) 20:54:07 mtreinish: rally plugins maybe 20:54:34 gothicmindfood: anything to add about next week ? 20:54:46 dims: I've leave that tag to you :) 20:54:55 :) 20:54:55 gothicmindfood, ttx ... others ... is there any plan for a dinner as a group? 20:54:56 ttx: I can do a scan, and see how many things there are 20:54:59 ttx: not much new - I scheduled dinner for all of us for Tuesday night at Zingerman's roadhouse 20:55:01 * jroll invites anyone hanging around past thursday to come hang out in his 'hood, there's surely campgrounds and hotels nearby 20:55:37 gothicmindfood: how hot/humid is it? 20:55:39 also, mestery is unable to attend, last minute, so if there's someone who wants to book a last minute flight to come out and be our 20th, anyone can let me know! 20:55:51 annegentle: I will arrive tomorrow, but apparently there was a huge lightning storm last night! 20:55:56 annegentle: it's been 80s and fairly humid lately 20:55:57 jroll: comments on the weather? 20:56:06 annegentle: i'm not finding any recent board meeting reminders/invites posted to the foundation@ ml, but there's https://wiki.openstack.org/wiki/Governance/Foundation/28Jun2016BoardMeeting 20:56:06 sounds about right. 20:56:07 I'd certainly bring shorts 20:56:13 also Air France just decided not to strike on Monday, so I might actually make it 20:56:15 jroll: ok, good to know. Actually similar to Austin right now oddly enough. 20:56:24 ttx: eesh. 20:56:32 ttx: good stuff 20:56:34 annegentle: the difference is this is normal, not cold :P 20:56:37 fungi: I got a reminder this morning I want to say 20:56:39 we have more strike days than non-strike days currently 20:56:43 ttx: maybe they'll strike later in the week so you can hang with me in Ann Arbor longer! :) 20:56:46 looks like rain next week: https://www.wunderground.com/q/zmw:48103.1.99999 20:56:58 OpenStack umbrella! 20:57:04 :D 20:57:12 * flaper87 hates rain 20:57:14 For those who missed it, I recommend SpamapS's thread on Architecture WG 20:57:14 oh well 20:57:18 * annegentle loves Michigan 20:57:29 but yes, michigan is beautiful this time of year, if you can stay for the weekend I'd highly recommend it 20:57:35 annegentle: oh, yep http://lists.openstack.org/pipermail/foundation/2016-June/002395.html (just realized i was looking at the foundation-board@ archives instead) 20:58:43 thx ttx, have a good evening all ... 20:58:51 Alright. If nothing else... we can close with 2 minutes early 20:58:59 board meeting 6.28 20:59:02 nice! 20:59:13 have a good one, everyone 20:59:16 Thanks everyone 20:59:20 bye! 20:59:20 #endmeeting