20:02:03 <ttx> #startmeeting tc
20:02:04 <openstack> Meeting started Tue Apr  7 20:02:03 2015 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:02:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:02:07 <openstack> The meeting name has been set to 'tc'
20:02:08 <dhellmann> o/
20:02:11 <ttx> Our agenda for today:
20:02:20 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:02:33 <ttx> #topic Give project teams still under consideration a derogation to be at the Design Summit
20:02:41 <ttx> Wanted to start with this first
20:02:53 <ttx> Basically I need to close the projects list this week to work on final Design Summit space allocation
20:03:02 <ttx> But we have a number of projects in the pipe, and I don't want to rush those discussions to meet that arbitrary deadline
20:03:14 <ttx> So my suggestion would be to give *all* projects in the pipeline Design Summit space, regardless of the state of their application
20:03:24 <ttx> That includes Rally, Security, Mistral and GBP.
20:03:35 <ttx> IMHO we have enough room in Vancouver to cover all of them without affecting "already official" projects.
20:03:45 <russellb> sounds reasonable
20:03:45 <ttx> Hpw does that sound?
20:03:48 <mikal> I think this is ag ood idea
20:03:50 <devananda> +1
20:03:53 <markmcclain> I think that's reasonable
20:03:57 <sdague> works for me
20:04:00 <ttx> that removes a bit of time pressure here
20:04:00 <dhellmann> +1
20:04:05 <annegent_> thinking
20:04:07 <ttx> OK... Anyone opposed ?
20:04:10 <jaypipes> ++
20:04:36 <vishy> +1
20:04:47 <annegent_> why even account for the pipeline though?
20:05:01 <annegent_> I'm not opposed, just making sure I understand
20:05:05 <ttx> annegent_: what do you mean by account for the pipeline ?
20:05:16 <ttx> You mean, why not close the list now ?
20:05:20 <annegent_> can't any project pipelined or not have some space?
20:05:37 <annegent_> and why now with the list we have?
20:05:38 <ttx> because space is finite ?
20:05:54 <ttx> and we have to split it among a set list of projects ?
20:05:59 <annegent_> sure but there's always trading in the last month. I mean I'm just checking with what I think will actually happen :)
20:06:15 <dhellmann> ttx: do we have any unorganized space this time, like the pods?
20:06:23 <annegent_> I can support drawing lines, sure.
20:06:35 <ttx> There will likely be /some/ unorganized space
20:06:54 <ttx> but not as much as usual, since we have work rooms now
20:06:55 <jaypipes> let the horse trading commence.
20:06:59 <annegent_> yeah
20:07:10 <annegent_> "space is still finite, time is still untravelable"
20:07:18 * mordred travels time
20:07:26 <dhellmann> annegent_: we all travel in time, we just can't steer
20:07:35 <ttx> ok, moving on
20:07:35 <mordred> we may all be dorks
20:07:37 <ttx> zehicle: around?
20:07:41 <annegent_> hee totally possible
20:07:53 <devananda> annegent_: as ATC status, and thus the pass to the developer summit, is tied to contributions to official projects, simply opening it up to all not official and not even slated to become official projects seems ... odd
20:08:10 <ttx> devananda: design summit space will be limited to "openstack" projects
20:08:17 <ttx> so +1
20:08:24 <devananda> ttx: that's what I thought. thanks for clarifying.
20:08:31 <dhellmann> ttx: is access limited to atcs? I can never remember if we actually do that.
20:08:37 <ttx> we have "ecosystem space" for related non-openstack projects
20:08:49 <annegent_> devananda: ttx: okay
20:08:51 <dhellmann> cool, that addresses projects that don't have proposals up yet
20:08:54 <ttx> dhellmann: no, full access pass holders can also enter
20:09:00 <dhellmann> ok, that's what I thought
20:09:13 <devananda> right, and with the ops track mixed in, we can't limit to just ATCs
20:09:39 <dhellmann> right, we don't want to, I was just trying to make sure that didn't mess with access for projects that wouldn't have scheduled time
20:09:55 <devananda> dhellmann: right :)
20:10:02 <ttx> annegent_: dhellmann: unfortunately some projects just miss the call
20:10:07 <ttx> ok, moving on
20:10:14 <annegent_> ttx: ok thanks for explaining
20:10:20 <dhellmann> ttx: yep, no problem with me with drawing a line somewhere
20:10:33 <ttx> for reference: https://www.openstack.org/summit/vancouver-2015/open-cloud-ecosystem
20:10:39 <ttx> tahts' for ecosystem projects ^
20:10:54 * ttx has some network trouble
20:10:58 <ttx> #topic Adding Rally to OpenStack
20:11:02 <ttx> #link https://review.openstack.org/169357
20:11:20 <mikal> ttx: did we skip over the defcore thing deliberately?
20:11:21 <ttx> boris-42: hi!
20:11:29 <ttx> mikal: if zehicle is not around...
20:11:36 <boris-42> ttx: hi
20:11:52 <ttx> let's discuss Rally first and give him a chance to join
20:12:20 <mikal> ttx: fair enough, just checking
20:12:22 <ttx> We are at 6 yes on that proposal already
20:12:25 <Rockyg> zehicle might be on the road.  Was in San Antonio this morning and the meeting ran an hour over.
20:12:42 <ttx> Questions from the remaining voters to clarify your view on it ?
20:13:02 <ttx> Rockyg: good to know. If he doesn't arrive we'll mention the topic with you
20:13:03 <markmcclain> ttx: effectively 8.. because mordred and jgriffith votes we're wiped by the update
20:13:06 <annegent_> Can I nitpick for an article for "a framework" and misspelled OpensStack in the commit message?
20:13:12 <markmcclain> s/we're/were/
20:13:20 * jaypipes notes he voted +1 for rally even though boris-42 said he hated him on the ML.
20:13:30 <annegent_> jaypipes: do you want a cookie? :)
20:13:33 <dhellmann> annegent_: I think we could fast-approve a follow-up grammar fix
20:13:37 * jaypipes tries not to anger The Boris.
20:13:44 <dims> lol
20:13:44 <ttx> markmcclain: since mordred is around he can reapply
20:13:51 <annegent_> boris-42: ok if I do a quick nit fix?
20:14:01 <ttx> We're actually at 7 now
20:14:06 <boris-42> annegent_: yep it's ok
20:14:07 <devananda> follow up patches to fix nits ++
20:14:30 <ttx> yes, follow up patch please, would hate to lose votes again
20:14:46 <ttx> 30 more seconds for eveyone to register their support
20:14:53 <dhellmann> ttx: I propose that annegent_'s patch falls under your housekeeping powers to just merge without debate
20:14:59 <sdague> dhellmann: ++
20:15:15 <ttx> I'll take that expansion of my vast powers and run with it
20:15:21 <annegent_> heh
20:15:40 <jogo> 'Rally tasks as a common language'?
20:15:41 <annegent_> patched
20:16:03 * ttx reapplies for form
20:17:11 * mordred has re-voted
20:17:17 <dhellmann> annegent_: oh, I expected a separate patch, but that's ok
20:17:22 <devananda> annegent_: oh, fwiw, I meant a separate dependent patch, not another revision. the history is cleaner that way.
20:17:29 <ttx> Alright, I applied discretionary power granted to me under exceptional conditions
20:17:31 * devananda also reapplies vote
20:17:33 <annegent_> dhellmann: devananda: ah sorry
20:17:33 <ttx> and it's approved
20:17:40 <devananda> \o/
20:17:45 <boris-42> WOOT
20:17:45 <dhellmann> ttx: ++
20:17:54 <dhellmann> congrats, boris-42 & team
20:18:02 <boris-42> thank you for support!
20:18:17 <ttx> That big tent is a much happier place than our integrated release cellar
20:18:28 * mordred dances around the tent
20:18:28 <russellb> had a question before my connection messed up ... was curious what you thought could help increase diversity in contributors
20:18:45 <russellb> aside from the obvious openstack git namespace issue
20:18:50 <annegent_> mordred: why are you outside the tent? get back inside right now
20:18:57 <boris-42> russellb: it helps a lot
20:19:01 <mordred> annegent_: *sorry*
20:19:10 <boris-42> russellb: many companies don't want to contribute in stackforge projects
20:19:13 <boris-42> =)
20:19:27 <ttx> #topic Adding the security team
20:19:29 <russellb> maybe we should just rename all repos and drop the prefix
20:19:47 <ttx> #link https://review.openstack.org/170172
20:19:59 <ttx> So this is a new horizontal team, which will cover the work of the VMT (currently under "Release Cycle Management" team) and OSSG (previously considered external)
20:20:01 <jaypipes> russellb: perhaps a demo from Boris and team in a webinar or recorded session -- tailored to OpenStack project devs -- would help to showcase how Rally can be a useful tool for functional integration testing in the projects themselves.
20:20:16 <ttx> I think the OSSG really structured its output lately (with OSSNs, security book, and bandit) so it makes sense to recognize it as "helping with the OpenStack Mission"
20:20:32 <ttx> And I also think it makes sense to move the VMT under a single "Security" team since the current split is confusing to everyone (except maybe VMT members)
20:20:48 <dhellmann> ttx: can you remind me what those acronyms stand for, please?
20:20:51 <annegent_> Happy to move the security doc repo under their team.
20:20:58 <devananda> I'm very glad to see Security becoming a recognized cross-project effort
20:21:09 <dhellmann> devananda: ++
20:21:12 <jaypipes> opestack security group, vulnerability management team
20:21:13 <ttx> VMT = Vulnerability Management Team, basically handling discovered vulnerabilities
20:21:29 <dhellmann> ossn?
20:21:32 <ttx> OSSG = OpenStack security Group, people working on improving the state of security in openstack
20:21:33 <dhellmann> notices?
20:21:34 <devananda> openstack security Notice
20:21:38 <dhellmann> k, thanks
20:21:42 <fungi> "note"
20:21:52 <ttx> OSSN = OpenStack Security Notes, random best practice and security advice
20:22:06 <ttx> OSSA = OpenStack Security Advisories, for patched vulnerabilities
20:22:10 <fungi> #link https://wiki.openstack.org/wiki/Security_Notes
20:22:19 <ttx> OSSG produces OSSN
20:22:26 <ttx> VMT produced OSSA
20:22:34 <russellb> does it really change anything about how VMT operates today?  just under a different team?
20:22:40 <devananda> fungi: ah, thx for the correction
20:22:44 <fungi> purely a governance change
20:22:54 <mordred> ttx: hyakuhei doesn't seem to be in IRC at the moment
20:22:56 <sdague> yeh, my only concern is that VMT still seems under staffed
20:22:57 <ttx> russell_h: changes nothing, just works under a new parent team
20:23:03 <fungi> same members as before, same workflows and policies
20:23:07 <russellb> ok thanks
20:23:15 <ttx> sdague: that doesn't help or hurt in that regard
20:23:16 <fungi> the vmt is surprisingly not understaffed
20:23:17 <dhellmann> if these teams all want to work together, it does seem to make sense to me
20:23:22 <sdague> it's not clear this helps, but I guess it doesn't hurt
20:23:35 <russellb> if the VMT is good with it, i'm good with it
20:23:39 <ttx> sdague: might help by exposing more sec folk to VMT work
20:23:44 <russellb> that was the only part i wasn't sure about, since it's different people really
20:24:04 <fungi> we keep the vmt intentionally small to limit information exposure, and then pull in security-oriented subject matter experts in specific projects as needed
20:24:05 <sdague> yeh, honestly, it seems all the people that care (being both vmt and ossg people) are for it
20:24:07 <ttx> yes, we had that discussion internally to the VMT and decided it was an improvement
20:24:17 <russellb> ttx: great thanks
20:24:19 <sdague> so it seems like a no brainer
20:24:34 <mordred> ttx: should we perhaps suggest or nudge that PTLs of things should be findable in irc ?
20:24:40 <fungi> so if we're short-staffed anywhere, it's actually on the individual projects/core reviewers end of things and not really so much the vmt itself
20:24:53 <ttx> mordred: we probably should
20:25:18 <ttx> mordred: with elections coming up and all, that could play a role
20:25:32 <ttx> we have 10 yes, I'll approve now
20:25:34 * mordred doesn't want a policy document or anything - but I think we should at least kinda send a friendly note or something
20:25:37 * fungi will prefer a security ptl candidate who uses irc
20:25:39 <sdague> fungi: yeh, I guess that's what I meant, in doing bug triage and finding a bunch of pretty old sec bugs that are languishing, as well as stuff that was made public a year ago and not fixed
20:25:55 <ttx> It's likely to conflict with previous merge anyway
20:26:04 <fungi> sdague: yep--we welcome more developers helping fix those bugs. they don't need to be in the vmt to do so
20:27:12 <ttx> ok approved
20:27:21 <fungi> if there are additional nova devs, for example, wanting to help with nova security bugs besides the ones who have already volunteered and given us a heads up, please send them our way
20:27:28 <ttx> +1
20:27:44 <mikal> fungi: I was intending to do a bit of a reboot of that list at the start of Liberty
20:27:55 <mikal> fungi: I didn't want to change it at this point in the release
20:27:56 <fungi> mikal: sounds great--thanks@
20:27:59 <ttx> #topic Tags
20:28:05 <ttx> * Apply the team:diverse-affiliation tag (https://review.openstack.org/168968)
20:28:22 <ttx> We have 9 yes... ready to approve
20:28:28 <ttx> Last minute comments/questions on that one ?
20:29:05 <annegent_> ttx: who takes responsibility for applying the tag to the latest application? The project itelf?
20:29:07 <annegent_> itself
20:29:18 <russellb> anyone who wants to
20:29:20 <russellb> *hand wave*
20:29:34 <ttx> yes, anyone can. I'll probably pick it up if nobody will
20:29:40 <annegent_> got it
20:29:53 <ttx> OK, approving in 20 sec
20:30:18 <ttx> approved
20:30:23 <ttx> * Add a two-organization rule to the diverse-affiliation tag (https://review.openstack.org/168969)
20:30:37 <ttx> Same here, approving in 30 sec
20:30:38 <sdague> yeh, I think we should just consider it like an oslo-sync
20:30:52 <sdague> the scripts are out there, someone just do it when it seems like it's gotten a little stale
20:30:55 <notmyname> o/
20:31:04 <ttx> yes, I'd like to set up a proposal bot for stuff that can be automatically updated like diversity
20:31:11 <mordred> look it's a notmyname
20:31:20 <notmyname> is there any worry that the script in https://review.openstack.org/#/c/168970/2/tools/diversity.py is based on stackalytics? is that "official" now?
20:31:31 <sdague> ttx: or just do it at milestones as a good trigger point
20:31:39 <russellb> notmyname: it was just easiest
20:31:49 <notmyname> russellb: I totally get that :-)
20:31:53 <ttx> sdague: +1
20:31:54 <russellb> heh
20:31:54 <mordred> notmyname: we've had a todo list item to pull it in to infra fora  while
20:32:02 <mordred> notmyname: but have just not gotten around to it yet
20:32:02 <sdague> notmyname: are there specific concerns with stackalytics?
20:32:04 <russellb> and i don't have any reason not to trust it
20:32:10 <notmyname> asking out of ignorance, is stackalytics open/auditable?
20:32:11 <ttx> notmyname: we'll point it to something else when we have something better to point to :)
20:32:13 <russellb> if so, we should figure those out
20:32:13 <mordred> notmyname: it is
20:32:15 <russellb> notmyname: yeah
20:32:19 <notmyname> ah, ok then :-)
20:32:19 <mordred> notmyname: it's in stackforge
20:32:29 <notmyname> all concerns addressed, then :-)
20:32:30 <ttx> notmyname: and you can actually patch it when it's insane
20:32:31 <fungi> there was some initial pushback, but there have been more recent interests expressed in mirantis not clutching it quite so tightly
20:32:53 <ttx> ok, approving now
20:32:54 <annegent_> mordred: the more we rely on stackalytics and not activity.openstack the worse off activity.openstack gets though?
20:32:55 <sdague> yeh, it would be nicer if it was in -infra instead of run by a single company
20:32:57 <mordred> jaypipes: we should really get around to getting around to that ...
20:33:00 <devananda> that it is in stackforge makes me happier with it
20:33:04 <fungi> so if we do want to move it over to become an infra project or something that seems more possible now than it was a few months ago
20:33:07 <devananda> mordred: but moving it to infra at this point would be good
20:33:14 <mordred> annegent_: I believe stackalytics won the stackalytics vs. activity battle a long time ago
20:33:19 <russellb> activity.o.o is not useful for this AFAIK
20:33:22 <sdague> annegent_: activity.openstack is very not good
20:33:25 <ttx> yes we need to have that discussion about activity reporting tools again
20:33:34 <annegent_> but the not very good is due to inattention?
20:33:39 <annegent_> that's what I'm wondering
20:33:49 <sdague> also, architecture / platform
20:33:52 <russellb> not sure it had much hope
20:33:52 <annegent_> ok
20:33:55 <mordred> annegent_: well, it's also not good due to being implemented in a way that's opaque to our community
20:33:56 <russellb> yeah, that
20:33:58 <ttx> approved.
20:34:02 <fungi> it's similarly maintained by one company right now, just one that's not an openstack member company at all
20:34:07 <ttx> * Add diversity helper script (https://review.openstack.org/168970)
20:34:14 <ttx> I think that's more on-topic
20:34:28 <mrmartin> fungi: we are moving activity.o.o under infra
20:34:36 <fungi> yep
20:34:45 <ttx> 5 yes, missing last 2
20:34:46 <jaypipes> mordred: agreed. offline convo.
20:34:50 <mordred> jaypipes: ++
20:34:55 <ttx> Any question on that that would help in voting ?
20:35:20 <ttx> I think a script is better than no script, so +1
20:35:21 <sdague> no, https://review.openstack.org/#/c/168970/ seems kind of crucial, as that's the tool to build the other reviews
20:35:44 <ttx> one more neded
20:35:44 <russellb> plenty that could be improved to automate more of it
20:35:55 <russellb> but that's how much i had done just for myself when writing the tag def.
20:35:58 <russellb> so seemed worth saving off
20:36:01 <sdague> there we go
20:36:10 <dhellmann> would be useful to have a tox environment to run it, with dependencies listed, etc, but that can come in another patch
20:36:14 <ttx> OK, approving now
20:36:31 <sdague> dhellmann: it only needs requests
20:36:36 <ttx> * Add "release:has-stable-branches" tag (https://review.openstack.org/169777)
20:36:37 <dhellmann> sdague: today
20:36:44 <ttx> So this one was created as a follow-up to the application of the other release tags.
20:36:58 <ttx> Application showed that we were putting in the same bag (tag) things that were releasing at the same time as the managed 6-month release (like Manila) and things that just had a stable branch cut from their last kilo release (like python-*client or Oslo libs).
20:37:11 <ttx> Both are useful pieces of downstream information, and both are actually distinct
20:37:23 <ttx> So creating a tag to describe "what has stable branches" (and keeping the release:at-6mo-cycle-end to really mean at the end of the 6-month cycle) allows to communicate both
20:37:37 <dhellmann> this seems like a good clarification to me
20:37:41 <ttx> Proposal creates tag and applies it, so that it's clear what it changes
20:37:51 <ttx> Although it will need a rebase
20:38:05 <ttx> Let me know on the review if you have additional questions on it
20:38:06 <annegent_> good thinking
20:38:34 <ttx> Although if it gets two more +1 I'll approve it now and rebase it for discretionary powers
20:38:43 <ttx> s/for/using/
20:38:56 <russellb> +1
20:39:11 <ianw> fungi: hey, could you get me a rax centos7 host?  i'm still debugging the glusterfs job.  i can not get it to replicate on a host i've created under my own account; even after running puppet and getting things looking pretty similar.  i want to check that i'm looking at the same kernel version, etc.  also i'm wondering if jenkins itself influences this
20:39:19 <ttx> Alright, 7 it has. Approved, althogh I doubt it will just merge silently
20:39:46 <ttx> #topic Defcore process discussion
20:39:50 <ttx> #link http://git.openstack.org/cgit/openstack/defcore/tree/process/2015A.rst
20:40:01 <hogepodge> Egle and Rob aren't able to make it
20:40:04 <ttx> zehicle is stuck somewhere but we have other Defcore people around
20:40:11 <ttx> zehicle asked for some time for us to discuss the approved defcore process
20:40:17 <ttx> It's not totally clear if the new bylaws require us to approve it (it mentions we need to agree with the board on thr procedure to follow to update the Defcore process)
20:40:26 <ttx> But in all cases it's better if we do not strongly disagree with it
20:40:41 <ttx> My only gripe with the process as laid out on 2015A.rst is that it's unclear that capabilities and required sections are drawn from the "TC-approved release" projects
20:40:49 <russellb> mostly i think we need to agree to the parts that require our participation
20:40:50 <ttx> (which is a requirement from the bylaws)
20:40:55 <russellb> otherwise, *shrug*
20:40:57 <ttx> So further clarification could be introduced to that effect, but the process does not look completely crazy as it stands.
20:41:00 * dhellmann needs to finish that tag definition proposal
20:41:14 <hogepodge> Updates were made to the doc this morning at a large meeting. https://etherpad.openstack.org/p/DefCoreScale.10B
20:41:36 <hogepodge> https://review.openstack.org/#/c/171335/
20:41:39 <ttx> Did TC member read enough of the proposed process to have an opinion on it ? Or should we wait until next week until everyone had a chance to dive into it ?
20:41:41 <Rockyg> ttx: suggest a patch to clarify
20:41:54 <russellb> if there are changes this morning, we probably need time to see what changed
20:41:57 <ttx> Rockyg: I probably will
20:42:07 * devananda has not read updated version yet
20:42:16 * dhellmann needs time to read the updated version
20:42:37 <dhellmann> hogepodge: is that etherpad what we should be reviewing, or is there a patch somewhere under review?
20:42:55 <ttx> Rockyg, hogepodge: could one of you clarify what Defcore means by "guideline" ?
20:42:56 * dhellmann notes the second link is a review
20:42:58 <hogepodge> #link https://review.openstack.org/#/c/171335/ consensus patch to update process document
20:43:06 <Rockyg> dhellmann: it's the patch hogpodge posted
20:43:21 * dhellmann nods
20:43:35 <ttx> hogepodge, Rockyg: or have an example of a "guideline" ?
20:43:36 <russellb> thanks for the link
20:43:52 <annegent_> is the process still to be defined for "PTLs Recommend Changes to Designated Sections"?
20:44:05 <annegent_> such as timing, to whom, how
20:44:11 <ttx> hogepodge: is it a set of Capabilities and Designated sections to cover a given mark ?
20:44:20 <Rockyg> Well, don't quote me on this, but guideline is the stuff the vendors have to do to qualify for mark
20:44:22 <hogepodge> ttx this is the latest guideline https://github.com/openstack/defcore/blob/master/2015.04.json
20:44:44 <hogepodge> so that's the test, as I understand it from the lexicon.
20:44:58 <Rockyg> And with the latest patch, the guideline will include designated sections
20:44:59 <ttx> hogepodge: thx, that makes much more sense now
20:45:13 * jaypipes being honest: doubts will be able to digest this defcore stuff.
20:45:39 <hogepodge> Yes, the defcore repository has a lot of information, with the desire to bring it under greater community scrutiny. #link https://github.com/openstack/defcore
20:45:46 <ttx> So my suggestion would be for TC members to have a look and if they feel strongly about it, intervene on the defcore ML and/or on the defcore reviews
20:45:59 <sdague> ttx: sounds reasonable.
20:46:02 <ttx> Since I don't think discussing this for 10 more minutes will get us anywhere
20:46:15 <ttx> then we can schedule some time to discuss it next week
20:46:15 <russellb> I think we should be looking to keep our involvement minimized, aside from what's required in bylaws, personally
20:46:25 <ttx> russellb: yes
20:46:29 <hogepodge> We also have a meeting tomorrow, 9 PDT, info on the mailing list.
20:46:57 <ttx> russellb: I want to clarify the famous procedure that the bylaws mandate we have and then let Defcore do their thing
20:47:01 <Rockyg> Yeah.  take a look at  https://review.openstack.org/#/c/171335/ and https://review.openstack.org/#/c/171338/ and I think it will lead you to more useful questions
20:47:03 <russellb> ttx: +1
20:47:41 <ttx> russellb: and as far as we are concerned the proceudre will mostly be on how to remove the "tc-approved-release" tag from some established projects
20:47:46 <Rockyg> You can ask the questions on the review so that the committee clarifies them.
20:47:47 * jaypipes thinks the DefCore group/team/project/repo should be renamed os-branding-requirements
20:47:52 <ttx> so it will be part of the tag definition.
20:47:56 <annegent_> Rockyg: yep did so
20:48:01 <mordred> jaypipes: ++
20:48:10 <russellb> ttx: cool, makes sense
20:48:15 <Rockyg> jaypipes:  ++
20:48:35 <ttx> OK, I propose we move on
20:48:51 <hogepodge> thanks.
20:48:56 <Rockyg> Thanks
20:48:58 * russellb has a tab open for this ... the ultimate todo list
20:49:12 <annegent_> thanks hogepodge and Rockyg
20:49:18 <mordred> ++
20:49:35 <ttx> #action ttx to propose to include tc-approved-release subsetting as a part of the process
20:49:50 <ttx> #topic Projects list housekeeping
20:49:53 <ttx> * Adds openstack/tripleo-common to TripleO... (https://review.openstack.org/166723)
20:49:57 <ttx> That one is the artist previously known under a confusing os-cloud-management name
20:50:06 <ttx> I think under its current form it's not confusing anymore
20:50:09 <mikal> Yeah, I appreciate the name change
20:50:16 <mordred> ++
20:50:20 <ttx> Will approve (since it has PTL +1) unless someone opposes it
20:50:52 <ttx> * Add new project puppet-pgsql_backup to infra (https://review.openstack.org/168117)
20:50:52 <zaneb> \o/
20:50:59 <ttx> Basic project addition, approved by PTL, will approve post-meeting unless someone objects
20:51:09 <ttx> oh actually has 7 yes now
20:51:12 <ttx> approving now
20:51:18 <mikal> One day someone will explain to me why each of these is its own repo
20:51:20 <mikal> But whatevers
20:51:30 <mrmartin> \o/
20:51:42 <dhellmann> mikal: the tripleo and infra teams are having a competition to create the most repos
20:51:47 <mordred> mikal: because we make them so that they can be reusable generally by puppet people broadly
20:51:47 <russellb> mikal: makes it easier to reuse them i think
20:51:50 <mrmartin> mikal: those modules were split apart from system-config in feb
20:51:57 <mordred> mikal: and the convention is git-repo-per-module
20:51:59 <ttx> * Update wording for Murano mission (https://review.openstack.org/168299)
20:52:15 <mikal> mordred: herm, I think I prefer the racing tripleo explaination
20:52:18 <ttx> More than enough +1s, approving now
20:52:24 <mordred> mikal: ok. it's because we're racing
20:52:38 <mikal> mordred: thanks for the honesty :P
20:52:43 <mordred> mikal: btw, I believe we're winning by a fair margin
20:52:45 <ttx> * Add 'regulatory' to congress service name (https://review.openstack.org/169480)
20:52:52 <ttx> So this one is to clarify usage of "policy" in Congress service name
20:52:57 <mikal> sdague: makes comments whcih confuse me here
20:52:58 <ttx> We can bikeshed a bit on the clearest wording
20:53:02 <dhellmann> mordred: infra is cheating by making more things than the rest of us ;-)
20:53:05 <mikal> Perhaps its because its 6am, but his regexp didn't parse for me
20:53:08 <ttx> I agree that anything but "policy" makes sense
20:53:08 <mordred> dhellmann: :)
20:53:27 <sdague> mikal: I was trying to replace out the use of naked policy use
20:54:00 <sdague> I think we need to scrub the world policy out of congress otherwise we're just confusing everyone
20:54:29 <dhellmann> ++
20:54:34 <annegent_> agreed
20:54:56 <ttx> we could make a "policy" tag and apply it to azll the projects that have some use for the word "policy" (all must be different)
20:55:08 * sdague glares
20:55:16 * mordred throws angry cow at ttx
20:55:19 <zaneb> rofl
20:55:24 <ttx> Maybe next year's april's fools
20:55:35 <dhellmann> ttx: or we could have a policy forbidding the use of the term policy in the description or name of any project
20:55:42 <mikal> Next year will be the year I translate nova comments to the queen's english
20:55:44 <ttx> that sounds a lot less funny though
20:55:50 <mordred> dhellmann: can that policy also abide by the policy?
20:56:00 <dhellmann> mordred: I accept your challenge
20:56:18 <ttx> I guess we should continue to bikeshed a bit on this one... it's far from having the required votes/support
20:56:32 <ttx> #topic Open discussion
20:56:37 <ttx> annegentle added the following topic to the backlog last week:
20:56:38 <sdague> anyway, alternative word smithing would be appreciated, that's the best I could add after last week's meeting
20:56:43 <ttx> * Need guidance for docs.openstack.org publishing and brand guidelines, especially for newest projects (http://lists.openstack.org/pipermail/legal-discuss/2015-March/000356.html)
20:56:48 <ttx> Not sure there is anything left to discuss there though ?
20:57:00 <annegent_> I met with Foundation lawyers and sent out a ML post
20:57:04 <ttx> annegent_: did you get the droids you were looking for ?
20:57:07 <ttx> ok
20:57:11 <annegent_> #link http://lists.openstack.org/pipermail/openstack-dev/2015-April/060710.html
20:57:19 <annegent_> so big tent docs, go
20:57:26 <ttx> What else...
20:57:47 <ttx> I'll be setting up some google form and spreadsheet to collect session ideas for the cross-project session, as mentioned on the -tc list
20:58:12 <ttx> Who is interested in crafting the session list ? Will require some availability in the coming weeks
20:58:18 <fungi> annegent_: did you manage to get clarification on cc-by declaration for documents and whether there needs to be an asl2 disclaimer for code samples included in them?
20:58:22 <ttx> I'll need at least a couple of people
20:58:31 <annegent_> fungi: not yet, will follow up once I have clarity
20:58:36 <fungi> thanks
20:58:41 <annegent_> fungi: ayup
20:58:44 <markmcclain> ttx: can help as long as it's not apr 16-27th
20:59:05 <ttx> markmcclain: that sounds pretty much the timeframe we'll work on that
20:59:29 <annegent_> ttx: I can help with cross project listing
20:59:37 <dhellmann> ttx: I can help
20:59:39 <Rockyg> ttx: be happy to help, but not sure I'm qualified
20:59:41 <ttx> we'll likely involve all TC on the voting part -- at this point I need partners in crime to help with the list
21:00:06 <ttx> OK, volunteers noted
21:00:17 <ttx> Anything else, anyone ?
21:00:51 <ttx> I'll work on the design summit slot allocation at the end of the week, hopefully will be able to give confirmation to every team on Friday
21:01:18 <ttx> Might ask the TC for advice if we end up needing to give some teams less than they asked
21:01:28 <ttx> but at this point it looks pretty good
21:01:43 <ttx> (i.e. we should be able to give everyone more or less what they asked for
21:01:56 <ttx> (still to be confirmed with newly-elected PTLs of course)
21:02:04 <ttx> OK, we are overtime
21:02:09 <ttx> #endmeeting