20:02:53 <ttx> #startmeeting tc
20:02:53 <openstack> Meeting started Tue Sep 23 20:02:53 2014 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:02:54 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:02:57 <openstack> The meeting name has been set to 'tc'
20:02:59 <russellb> was reading about wormholes
20:03:03 <vishy> o/
20:03:13 <vishy> russellb: sounds dangerous
20:03:17 <russellb> quite
20:03:18 <ttx> Our agenda for today:
20:03:22 <markmc> pretty wormhole pictures
20:03:23 <ttx> #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee
20:03:32 <ttx> #topic Final pass on extra-atcs before PTL election roll generation
20:03:41 <ttx> We need to do final approvals on those as they will be used for election roll generation in a couple of days
20:03:54 <ttx> Also we'll probably need rebases to get them in, but i can take care of that once approval is given
20:04:02 <ttx> * Add Juno Compute co-authored-by authors to extra-atcs. (https://review.openstack.org/119666)
20:04:12 <ttx> All those are checked as valid, so just waiting for 7 YES
20:04:35 <ttx> * Adds Documentation co-authors as ATCs. (https://review.openstack.org/119757)
20:04:53 <ttx> Sebastian and Vinny are actually not Foundation members, but we are trying to get that fixed
20:05:06 <ttx> so feel free to pile up YES there as well
20:05:16 <ttx> I'll approve if we can straight them up
20:05:20 <jeblair> what will happen if it's not fixed?
20:05:25 <russellb> maybe ping TC list once it's fixed?
20:05:35 <ttx> I would ask Anne to submit a limited list
20:05:36 <russellb> happpy to +1 once that's confirmed ..
20:05:54 <ttx> ok, that will probably be tomorrow once we get another roundtrip with them
20:06:08 <ttx> so maybe keep that one out for now
20:06:11 <ttx> * Adds Telemetry Juno co-authors as ATCs (https://review.openstack.org/119794)
20:06:15 <ttx> All those are checked as valid, so just waiting for 7 YES
20:06:49 <ttx> The last two reviews are tooling which actually need some *code* reviews before they can make it in :)
20:06:53 <ttx> * Script to automate adding extra-atcs (https://review.openstack.org/121730)
20:06:56 <ttx> * Naive script to verify extra-atc foundation status (https://review.openstack.org/121696)
20:07:19 <ttx> ok I'll approve the compute one
20:07:31 <anteaya> I wonder why these are offered to governance rather than infra/config/tools
20:07:32 <russellb> "Naive script"
20:07:34 <russellb> way to sell it!
20:07:35 <russellb> :-p
20:07:49 <dhellmann> russellb: under sell, over deliver
20:07:52 <jeblair> erm.  it should have a license header.  :(
20:07:55 <fungi> i'll note that we'd previously resisted inserting atc-related scripting/tools in the governance repo (which lives in the infra config repo at the moment)
20:08:03 <anteaya> since our scripts usually need to be updated every election
20:08:23 <jeblair> fungi: good point, why not move it into an infra code repo?
20:08:32 <dhellmann> I was trying to include the script for testing the file in the repo where the file lives
20:08:43 <jeblair> dhellmann: cross-project testing is not a problem for us
20:08:44 <fungi> i'm fine either in an infra repo or in the governance repo, but they should live together wherever they end up
20:08:55 <dhellmann> ok
20:09:01 <ttx> fungi: where do the election generation tools live ?
20:09:11 <fungi> openstack-infra/config:tools/atc
20:09:16 <fungi> for the moment
20:09:34 <fungi> can be moved as needed of course
20:10:04 <ttx> ok
20:10:43 <ttx> #action ttx to ping TC members to get Docs extra-atcs in once their membership status is fixed
20:10:56 <ttx> anything else on that topic ?
20:11:43 <ttx> I'll take that as a no.
20:11:47 <ttx> #topic Recommendation to Adopt DCO as CLA
20:11:53 <ttx> #link https://review.openstack.org/120260
20:11:57 <ttx> jeblair: you're up
20:12:53 <jeblair> at the july meeting, the board started talking about this
20:12:58 <jeblair> mostly listening, actually, to presentation
20:12:59 <jeblair> s
20:13:15 <jeblair> but one thing that came up is that there were uncertain this was a real issue for our developer community
20:13:25 <jeblair> our silence on the subject was actually counter-productive
20:13:46 <jeblair> we had chosen not to bring up a resolution before in order to avoid 'spooking' the board
20:14:08 <markmc> right, I was explicitly asked to not propose a resolution to the TC in advance of that meeting
20:14:14 <jeblair> but it turns out they just thought that it was a minority point of view, eg, one person.
20:14:48 <ttx> As I said my only concern is to avoid appearing too adversarial (if that's a word), so I wonder if piggybacking on one of Mark Radcliffe's own options and "recommend" it would not be a better approach
20:14:51 <jeblair> so i think it would be helpful to let them know that this is a problem we would like them to address
20:15:01 <markmc> heh, slight exaggeration - but certainly some board members questioned how widespread a concern this is
20:15:15 <ttx> i.e. saying "of the options you get, w"e'd recommend you pick option 5 for this and that reason"
20:15:27 <anteaya> adversarial is a word
20:15:34 <jeblair> markmc: well, one person on the board suggested it was only one person's concern, but then, that one person is prone to exaggeration ;)
20:15:47 <markmc> jeblair, I agree, I think it would be helpful at this point to say the TC have listened, considered and concluded a ... conclusion
20:15:47 <reed> ditto
20:15:52 <jeblair> there were actually a number of -1s on my wording because it was too weasel-wordy
20:16:16 <jeblair> i tried to make it very diplomatic in saying that we are not demanding the board do this, but we are requesting they consider it (which is their perogative)
20:16:17 <markmc> jeblair, that person (if I understand you) suggested that it was purely a Red Hat concern
20:16:23 <jeblair> markmc: yep
20:16:37 <dhellmann> well, clearly that's not true
20:16:39 <jeblair> basically, i'm trying to provide the information that we care
20:16:47 <mordred> ++
20:16:47 <jeblair> and it is a broad concern
20:16:54 <devananda> jeblair: ++
20:16:56 <ttx> jeblair: technically we could propose a bylaws change. But if we just want them to consider the DCo as the "CLA" (no bylwas change) then yes, it's just for their consideration
20:17:06 <jaypipes> jeblair: I have no major issues with it other than a wording nit (see inline on patch review)
20:17:09 <bswartz> jeblair: +1
20:17:16 <zehicle_at_home> o/
20:17:59 <devananda> jeblair: and as I understand it, I think that's better than the TC specifically recommending one approach, at least at this point
20:18:30 <markmc> jeblair, I like it, I only haven't +1ed because of the suggested changes
20:18:36 <jeblair> ttx: i think the 'radcliffe option 5' approach would be okay; if we feel that's the better approach, i'm happy to change it
20:18:47 <jeblair> otherwise, maybe i should repropose fixing all the nits and we go with this?
20:19:04 <ttx> jeblair: I still think presenting like this would be more efficient: "we got Mark's presentation at the request of the board, see the various options, and recommend we folow 5 because..."
20:19:25 <ttx> it feels like we are part of the process rather than a new thing
20:19:39 <ttx> and it makes clear that we stabd united
20:19:42 <ttx> stand*
20:19:51 <ttx> (hopefully)
20:19:52 <jeblair> ya, to be fair, i wrote this before i knew we were getting a presentation :)
20:20:07 <jeblair> should we do a quick poll on the two approaches?
20:20:08 <ttx> it was an opinionated presentation for sure.
20:20:16 <ttx> but our pick is ont of the options
20:20:25 <ttx> so I would exploit that ;)
20:21:52 <dhellmann> that makes sense. Is option 5 really our preferred option?
20:22:14 <ttx> ok, let's call the current text "original" and the "recommend an option" approach "option"
20:22:45 <ttx> dhellmann: I think it's clearly the DCO as CLA approach yes
20:22:52 <ttx> quick informal poll, which approach do you prefer, original or option
20:22:54 <dhellmann> ok, I do agree it makes sense to propose a specific option from the existing menu, if we can agree on one that *we* like
20:22:55 <russellb> with no CCLA, as well?
20:23:02 <ttx> with no CCLA
20:23:05 <russellb> ok.
20:23:14 <ttx> that's how I understand it at least. markmc?
20:23:33 <russellb> basically, DCO with no ICLA and no CCLA, would be ideal :)
20:23:45 * ttx retrieves the wording
20:23:49 * devananda reviews mark radcliffes presentation, and
20:23:56 <devananda> "Adopt DCO Procedure for Individual/
20:23:56 <devananda> Corporate Contributors (ASL2 as contribution
20:23:58 <devananda> agreement)"
20:24:08 <ttx> "Option 5: Adopt DCO Procedure for Individual/Corporate Contributors (ASL2 as contribution agreement)"
20:24:19 <mordred> just for the record, I don't need the DCO either, but I support moving to it as our opinion
20:24:19 <jeblair> https://etherpad.openstack.org/p/37WKZ1igS2
20:24:25 <jeblair> ttx: ^
20:24:28 <devananda> ttx: heh, thanks. sorry for the bad line wrapping
20:24:34 <mordred> so, "DCO with no ICLA and no CCLA" ++
20:24:42 <jeblair> that's a quick copy/paste from the slide deck
20:24:49 <markmc> there was a leaning towards a preference for DCO+CCLA by board members
20:25:03 <russellb> markmc: sounds only marginally better
20:25:05 <mordred> that would solve nothing
20:25:05 <markmc> to me, the acceptability of that depends on the details
20:25:07 <ttx> markmc: I don't think that solves a lot
20:25:18 <mordred> I do not support that and would vote against it on the board
20:25:18 <markmc> if the DCO is all that is required/enforced for contributions
20:25:22 <devananda> if i understood mark's points on the call last week (and it's quite possible I don't) there seemed to be legal ambiguity about going to a completely-DCO-based approach
20:25:25 <ttx> okk quick poll, "original" or "option" ?
20:25:29 <markmc> and the Foundation encourages companies to sign the CCLA after the fact
20:25:31 * ttx votes "option"
20:25:35 <markmc> then it is still a big improvement, IMO
20:25:37 <russellb> markmc: sure that'd be fine
20:25:51 <russellb> encourage/allow, but not require
20:25:52 <russellb> fine
20:25:52 * mordred disagrees, being a member of a big corporating and having gotten CCLA's signed
20:26:12 <markmc> devananda, what was the abmiguity?
20:26:42 <ttx> devananda: legal is ambiguous by design
20:26:48 <devananda> markmc: IIRC it had to do with bankruptcy of corporate contributors
20:26:49 <devananda> ttx: indeed
20:27:34 <jeblair> to be fair, i think there are other options
20:27:52 <devananda> also, having seen the FUD inside of a big corporation around teh CCLA, I don't think it was helpful to the process of getting developers to contribute
20:27:53 <jeblair> the ones in radcliffe's presentation are just the ones that radcliffe has chosen to present
20:27:55 <devananda> even after it was signed
20:27:59 <markmcclain> devananda: right… I'm guessing that concern is also followed by the legal departments that assume a lawsuit of some for is inevitable
20:28:10 <ttx> jeblair: sure, but it includes the one we want, no ?
20:28:24 <jeblair> yeah, i'm just noting that because someone is pasting all of them in the etherpad i linked :)
20:28:38 <ttx> that's definitely not all the combinations proposed
20:28:39 <mordred> I would like to respond with what we want, not which of the chosen bad set we prefer
20:28:40 <devananda> markmc: so based on my experience, I'd agree with mordred - the foundation encouraging companies to sign a CCLA might still be enough to scare them off
20:28:53 <dhellmann> jeblair: yeah, I was doing that for the folks that didn't have the presentation handy
20:29:03 <markmc> devananda, it wouldn't be my preferred approach; but I do think it would be an improvemtn
20:29:08 <reed> devananda, I have no evidence that corporations are not scared of CCLA
20:29:13 <ttx> #startvote Which approach is the best to expose our case? original, option, dunno
20:29:14 <dhellmann> if there are others, we can add them for reference
20:29:14 <openstack> Begin voting on: Which approach is the best to expose our case? Valid vote options are original, option, dunno.
20:29:15 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
20:29:19 <markmc> devananda, for example, allowing us to take patches from operators under the DCO
20:29:23 <ttx> #vote option
20:29:33 <ttx> by popular request, the startvote bot is back
20:29:39 <russellb> #vote dunno
20:29:41 <russellb> i think they're both fine
20:29:42 <markmcclain> #vote dunno
20:29:47 <russellb> both  serve the purpose of saying "we care"
20:29:50 <russellb> so whatever
20:29:52 <dhellmann> #vote dunno
20:29:55 <devananda> markmc: yup. I agree that the DCO is definitely an improvement from a foundation-can-take-your-patch perspective :)
20:30:09 <markmc> #vote original
20:30:31 <devananda> ttx: is "origina' that we tell the board what we want, and don't pick from a specific option?
20:30:38 <vishy> #vote dunno
20:30:44 <ttx> devananda: yes
20:31:05 <devananda> #vote original
20:31:06 <markmc> original also spells out our rationale
20:31:09 <mordred> #vote original
20:31:14 * ttx sobs
20:31:24 <ttx> ok 30 seconds left
20:31:33 <markmc> which (if I can say) is a nice concise summary of the arguments richard and I were documenting
20:31:38 <devananda> russellb: but 'option' tells the board we endorse a specific solution
20:31:44 <ttx> #endvote
20:31:45 <openstack> Voted on "Which approach is the best to expose our case?" Results are
20:31:46 <openstack> dunno (4): dhellmann, russellb, markmcclain, vishy
20:31:46 <markmc> so, it's endorsing the rationale which was presented to the board in July
20:31:47 <openstack> option (1): ttx
20:31:48 <openstack> original (3): mordred, markmc, devananda
20:32:02 <ttx> I guess I lose, and will back the original.
20:32:12 <jeblair> okay, i will provide a link to info on the DCO
20:32:27 <jeblair> and i'll also implement jaypipes' suggestion too?
20:32:45 <jaypipes> jeblair: only if we're serious about this.
20:32:49 <jeblair> heh
20:32:52 <jaypipes> :P
20:32:57 <russellb> i seriously accept the suggested change
20:32:59 <dhellmann> jeblair: +1
20:33:05 <mordred> russellb: ++
20:33:07 <jeblair> okay, i'll have that up before the meeting is thru
20:33:17 <ttx> yeah, serious was a bit overboard
20:33:24 <russellb> seriously
20:33:29 <markmc> wait, this is the for serious TC meeting?
20:33:31 <markmc> huh
20:33:34 <ttx> I am a serious open source dev
20:33:34 * markmc got times mixed up
20:33:40 <ttx> FOSDEM is a serious conference
20:33:41 <markmc> not an amateur?
20:34:04 <ttx> #topic Testing interface update
20:34:07 <jeblair> markmc: should i link to here? http://ltsi.linuxfoundation.org/developers/signed-process
20:34:19 <ttx> I think we can collect +1s and get them approved today
20:34:24 <ttx> * Import the Project Testing Interface description (https://review.openstack.org/119872)
20:34:29 <ttx> This one needed one more YES last time I looked
20:34:38 <markmc> ttx, James Bottomley uses this: http://developercertificate.org/
20:34:41 <ttx> oh, it has 7 now
20:34:51 <mordred> ttx: the last in the chain needs discussion
20:34:52 * ttx approves
20:34:54 <jeblair> markmc: ack will do
20:35:01 <ttx> mordred: sure, we'll get to it
20:35:03 <mordred> kk
20:35:28 <ttx> * Two minor style cleanups (https://review.openstack.org/119873)
20:35:31 <ttx> Same here
20:35:51 <ttx> * Update testing interface to reflect reality (https://review.openstack.org/119874)
20:35:54 <ttx> This one has the required approvals
20:36:16 <ttx> That leaves us with:
20:36:22 <ttx> * Add a docs environment to the testing interface (https://review.openstack.org/119875)
20:36:29 <ttx> mordred: care to introduce it ?
20:37:02 <mordred> almost all repos have such an env ... but there is question about whether that's a good thing
20:37:16 <jeblair> the practical upshot of this is that we will open the door to projects adding non-standard build steps for docs
20:37:54 <jeblair> the current practice enforces that 'python setup.py build_sphinx' is the way docs are built; the new one is designed so that you can do something before running that
20:37:55 <markmc> these concerns aren't mentioned in the review, right?
20:38:01 <ttx> markmc: no
20:38:07 <russellb> yeah, the review concerns were trivial it seemed ...
20:38:10 <ttx> the -1s are about ordering I think
20:38:39 <dhellmann> jeblair: the reason I like the new env has nothing to do with extra steps: it's easier to tell someone to "tox -e docs" than "tox -e venv -- python setup.py build_sphinx" if they want to build the docs locally to test
20:38:44 <ttx> it's a bit orthogonal concern though
20:38:53 <jeblair> dhellmann: yeah, which is why most projects added it
20:39:00 <jeblair> and i dig that
20:39:01 <ttx> since refactoring it in the same commit would actually make 2 changes in one
20:39:01 <lifeless> dhellmann: maybe a makefile :)
20:39:02 <markmc> jeblair, why is that not a concern about 'python setup.py test' ?
20:39:15 <mordred> lifeless: no
20:39:17 <sdague> yeh, if this is about testing interface it seems fine
20:39:21 <jeblair> but the reason it's showing up here is that someone wanted to add an external build step
20:39:24 <dhellmann> markmc: because a bunch of projects are already doing non-standard things there
20:39:43 <jeblair> which i argued was unecessary.  i think we even came to the conclusion that the fact that they had to do that was a potential bug in pbr
20:40:19 * dhellmann would be interested in more details outside of the meeting
20:40:24 <jeblair> so anyway, i'm not -1ing on this, and am okay with it as it stands
20:40:35 <jeblair> but i want to make sure that it is really our intention to allow this
20:40:43 <dhellmann> I'm OK with infra asking us not to allow this
20:40:51 <jeblair> because not only does it technically permit it, but the description in the docs also says it is okay
20:40:58 <dhellmann> projects can still have the venv as a convenience
20:41:05 <lifeless> making distributors depend on tox to build docs might be weird for them
20:41:18 <lifeless> in fact, I think it would be bad for them
20:41:20 <mordred> they don't need to
20:41:39 <mordred> they can run the commands
20:41:40 <jeblair> we could also change the pti to use the docs build but just say that you shouldn't add any extra pre-build steps, if we wanted to do that
20:41:53 <lifeless> mordred: the implication jeblair is talking about - if allowed - will mean there isn't an interface they can use that doesn't involve setting up a venv
20:42:03 <lifeless> mordred: so they wil have to copy-the-code-from-tox.ini, no ?
20:42:25 <mordred> lifeless: I have stopped caring about that
20:42:25 <russellb> +1 to stating it's for convenience, and to not be wonky with it
20:42:43 <mordred> since they all patch out pbr for no reason
20:42:47 <markmc> could we perhaps get a summary of all of this in the review and come back to it?
20:42:56 <markmc> seems to be taking a bunch of time here for a pretty minor thing
20:42:57 <mordred> markmc: ++
20:43:05 <russellb> ++
20:43:16 <ttx> ack
20:43:47 <ttx> jeblair: could you collect that and comment on the review ?
20:44:10 <ttx> or anyone else?
20:44:24 <jeblair> sure
20:44:47 <jeblair> it's going to be a +0 though
20:44:53 <ttx> #action jeblair to clearly express the potential concern about innocent-looking https://review.openstack.org/119875
20:44:59 <ttx> #topic Other governance changes
20:45:04 <ttx> * Add openstack/designate-dashboard to the DNS Services program (https://review.openstack.org/119549)
20:45:26 <ttx> I don't think we should block this one. It's just a program creating another repo
20:45:39 <ttx> they need it to land a dashboard proptotype
20:45:41 <russellb> i'm just irritated that we're making them do this
20:45:58 <mordred> ++
20:46:06 <ttx> since horizon at the moment only accepts integrated projects
20:46:06 <mordred> I think it's crazy
20:46:06 <markmcclain> russellb: +1
20:46:11 <sdague> yeh, this is weird
20:46:15 <russellb> ttx: that's what i think is weird
20:46:17 <ttx> if mordred has its ways that will be a thing of the past
20:46:21 <mordred> ++
20:46:25 <dhellmann> the alternative is to ask horizon to accept the dashboard now?
20:46:30 <russellb> i think projects should be encouraging and accepting of integration with incubated projects
20:46:33 <ttx> I don't think we should block designate though
20:46:38 <russellb> that's the point of incubation time, isn't it?
20:46:40 <markmcclain> russellb: ++
20:46:40 <ttx> and we can have that discussion with horizon
20:46:59 <ttx> russellb: arguably not
20:47:11 <ttx> it's the point of integration :)
20:47:16 <zaneb> ttx: if mordred has his way, horizon will have guidance at all as to what to include (unless it's needed to run wordpress)
20:47:35 <zaneb> s/guidance/*no* guidance/
20:47:37 <devananda> fwiw, horizon has said the same thing to ironic
20:47:42 <russellb> well anyway, point taken that this is largely not an approval and just a document update
20:47:45 <ttx> horizon feels like it should include dashboards for integrated projects only, on the first cycle they are integrated
20:47:47 <devananda> not accepting dashboard panels until ironic graduated
20:47:49 <russellb> just something we should really follow up on
20:47:58 <russellb> if we can put it on our future agenda to discuss, i'll remove my -1
20:48:00 <jeblair> this is not reversible
20:48:04 <ttx> but that is an otrthogonal discussion, to be had with horizon folk
20:48:12 <jeblair> git repos are forever :/
20:48:21 <devananda> I do not see the problem with designate creating their panel inside of their existing repo
20:48:32 <russellb> right
20:48:34 <devananda> then moving the particular code tree to horizon when horizon will take it
20:48:38 <ttx> we did it for sahara-dashboard though
20:48:42 <zaneb> fwiw Heat's policy is resources in /contrib until graduation, then they move into the main part of the tree
20:48:49 <russellb> ttx: but it seems silly to do it again
20:49:02 <ttx> hmm
20:49:05 <russellb> incubation should be enough of a signal that projects should start working together
20:49:10 <SergeyLukjanov> ttx, ack, we've just finished moving our code to horizon
20:49:17 <russellb> make it off by default or whatever if needed
20:49:17 <bswartz> does horizon not have an "experimental" area?
20:49:25 <jeblair> sahara had like 5 repos, i didn't even notice one was for horizon :)
20:49:41 <bswartz> we face this issue with manila -- currently we have a fork of the horizon project with out horizon integration
20:49:52 <bswartz> s/out/our/
20:50:08 <jeblair> anyway, i'm not -1 on it; we move enough repos around as it is, but we should follow up with horizon and see if we can work something else out
20:50:09 <devananda> ttx: how "OK" is it for projects to create temporary repos, in general? and if that's not normally OK, why is it OK in this case?
20:50:25 <ttx> jeblair: the fact that git repos are forever goes a bit against our will to allow programs to organize code repos as they see fit
20:50:57 <ttx> if we consider that expensive, that means we'll be back at policing all the repo creations
20:51:02 <russellb> our criteria for graduation includes: must have completed integration work with other integrated projects
20:51:14 <mordred> jeblair: if we graft-merged, we could remove the repo, because we would keep all the history
20:51:36 <mordred> which is the no-delete concern
20:51:37 <jeblair> ttx: i disagree that it goes against our will;
20:51:55 <jeblair> ttx: we don't generally object to programs creating new repos as they see fit
20:52:15 <jeblair> ttx: we're objecting to creating a throw-away repo because of an arbitrary policy decision that we all find inconvenient
20:52:39 <ttx> hm.
20:52:42 <mordred> jeblair: ++
20:52:50 <jeblair> ttx: the marginal cost of this is low from a technical point of view.  from a process and developer experience point of view it is quite high.
20:52:58 <ttx> we also say that completing horizon integration is a first-cycle thing
20:53:08 <ttx> russellb: ^
20:53:14 <devananda> ttx: I think policing all the repo creations is acceptable, but taht's a discussion for the ML
20:53:14 <ttx> so we can read that however we want
20:53:21 <russellb> those seem to contradict :)
20:53:34 <russellb> it literally says includes dashboard integration
20:53:36 <jeblair> (not to minimize the cost to horizon of accepting any old thing in their tree; clearly a balance needs to be found, i think this just isn't it)
20:53:37 <ttx> OK, so we should ask Kiall if he could not live with a single repo
20:53:41 <russellb> * Project must have completed integration work with other integrated
20:53:41 <russellb> projects, as communicated by the TC when accepted into incubation (that
20:53:41 <russellb> includes Dashboard integration if applicable)
20:53:48 <russellb> ^^^ in "graduation to integrated"
20:54:02 <ttx> then see if Horizon feels ok with accepting incubated stuff in code
20:54:19 <russellb> so we mention it twice in our doc
20:54:28 <jeblair> russellb: wow, we already made the change that we all are thinking we should make :)
20:54:55 <russellb> yeah
20:54:58 <ttx> jeblair: I think half of us thought A, half of us thought B and we all got our stuff in
20:55:32 <ttx> the current reality is that Horizon includes dashboard for projects on their first integarted cycle
20:55:36 <ttx> we can change that
20:55:48 <ttx> but that's the current way it's always been done.
20:56:10 <ttx> but that's actually a separate discussion
20:56:12 <russellb> i really don't want to block designate ... my intention with a -1 was really to see if we could make life simpler for them
20:56:26 <ttx> the core of this discussion is "couldn't you se your main repo for temporary stuff"
20:56:29 <ttx> use*
20:56:39 <russellb> i think that's secondary personally ...
20:56:42 <ttx> I guess that's a valid objection.
20:56:42 <russellb> oh
20:56:57 <ttx> (deva's latest objection)
20:57:08 <devananda> I haven't seen anything suggesting they can't use the main repo ?
20:57:09 <russellb> yeah i guess that's one way to do it
20:57:17 <russellb> if it's a temporary staging area
20:57:21 <ttx> devananda: that's just not what they asked for :)
20:57:21 <devananda> russellb: basically what we did for nova's ironic driver
20:57:26 <russellb> right
20:57:35 <ttx> ok, moving on
20:57:39 <ttx> * Add keystoneclient-kerberos repo to Keystone (https://review.openstack.org/120310)
20:57:53 <ttx> This one is hopefully a no-brainer
20:57:59 <ttx> since it's not throw-away
20:58:07 <ttx> * Add ha-guide to Documentation program (https://review.openstack.org/121643)
20:58:32 <ttx> same for this one, will approve unless someone complains (anne +1ed it)
20:58:40 <jeblair> dolphm: can you review https://review.openstack.org/120310 please?
20:58:59 <ttx> * Propose guidelines for adopting new official projects (https://review.openstack.org/116727)
20:59:17 <morganfainberg> jeblair, dolphm has been hit and miss out. he may or may not be around for the rest of the day
20:59:19 <ttx> if this one doesn't take 22 comments into account, I guess we can abandon it
20:59:34 <ttx> zaneb: planning to do another patchset there ?
20:59:40 <morganfainberg> jeblair, i meant to poke him about it earlier but forgot, sorry.
20:59:43 <zaneb> I was working on one
21:00:00 <zaneb> but not sure if it will be superseded by the discussion that mordred started on the ML
21:00:02 <devananda> ttx, zaneb: that seems to echo a lot of the topics recently on the ML
21:00:09 <ttx> Oh, and https://review.openstack.org/#/c/119794/ just got rebased, so if you could pile up the +1s again i'll reapprove it
21:00:12 <devananda> zaneb: exactly...
21:00:21 <jeblair> i think it may be worth waiting to see how the big-tent discussion goes
21:00:33 <ttx> agree, maybe Workflow-1 it
21:00:39 <zaneb> ok, will do
21:00:41 <jeblair> i pushed up a new version of https://review.openstack.org/#/c/120260/ (dco/cla)
21:00:48 <ttx> #topic Open discussion
21:00:58 <ttx> Last thoughts ?
21:01:09 <jeblair> is this our last meeting?
21:01:10 <ttx> Those meetings are too busy, no time to discuss the TC dinner.
21:01:14 <zaneb> ttx: oh, I can't workflow -1 it
21:01:16 <ttx> jeblair:  no
21:01:24 <jeblair> ttx: when is that?
21:01:26 <ttx> zaneb: I did it
21:01:34 <zaneb> strange, I thought the owner could always do that
21:01:44 <ttx> jeblair: see my tc meeting announcement email to the -tc list
21:01:48 <ttx> we have at least one more
21:02:02 <ttx> and we could also run them during the election period, we've done so in the past
21:02:09 <ttx> which would add two more
21:02:21 <jeblair> ok
21:02:23 <anteaya> tc candidate questions are up on the wiki: https://wiki.openstack.org/wiki/TC_Elections_October_2014#TC_Election_Questions
21:02:30 <ttx> ok, time up
21:02:33 <ttx> #endmeeting