20:01:30 <ttx> #startmeeting tc
20:01:31 <openstack> Meeting started Tue Dec 17 20:01:30 2013 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:35 <openstack> The meeting name has been set to 'tc'
20:01:37 <ttx> Last meeting for 2013 !
20:01:44 <ttx> #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee
20:02:01 <ttx> #topic Becoming a Program, before applying for incubation
20:02:07 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2013-December/022202.html
20:02:16 <ttx> Let's discuss this first, as suggested by sdague at last meeting
20:02:28 <ttx> So... the idea is to somehow bless the idea / scope / mission of a team or a project before it files for incubation
20:02:39 <ttx> That way it can actually attract enough contributors to pass our ever-higher technical barriers to entry
20:02:49 <ttx> Which solves the chicken-and-egg problem we had with various recent incubation proposals
20:02:52 <lifeless> o/
20:02:56 <ttx> Various solutions tossed in that thread:
20:03:05 <ttx> 1. Reuse "Programs" for that (original solution proposed on the thread)
20:03:13 <ttx> 2. Reuse "Programs" but make new ones go through a trial period ("emerging programs")
20:03:22 <ttx> 3. Bless teams/missions, but don't call them programs yet ("emerging efforts" badge)
20:03:30 <ttx> 4. Bless projects themselves rather than teams/missions ("emerging projects" badge)
20:03:39 <ttx> 5. Don't bless, just set up an "Emerging projects" page containing prose describing the TC feedback on it
20:03:47 <ttx> Comments / thoughts ?
20:03:56 <ttx> (personally I'm hesitating between (3) and (5) at that point)
20:03:59 <dhellmann> I'm starting to like 5 myself
20:03:59 <jeblair> i think the suggestions on the thread to make this a very light-weight endorsement sound good.  i think we should hold programs to a high standard, but if indicating that we think a project is a good idea and we'd like to encourage it helps, i think that's worthwhile.
20:04:05 <jeblair> so i think 5 fits the bill
20:04:13 <mtaylor> o/
20:04:19 <sdague> yeh #5 seems reasonable to me
20:04:25 <markmcclain> I like 5
20:04:32 <ttx> I'm fine with trying (5) as a first incremental improvement. I fear that won't generate enough visibility to make them reach critical mass, but we can revisit later.
20:04:38 <russellb> sure, it's a pretty light weight step in the direction
20:04:50 <russellb> yeah, we could do #5 for now, and more later if we feel it's necessary and justified
20:04:53 <vishy> o/
20:05:02 <lifeless> I don't think blessing something without substantial momentum makes sense
20:05:17 <lifeless> tripleo only applied for incubation when it was already attracting developers
20:05:25 <dhellmann> that's the difference between 3 and 5, right?
20:05:40 <dhellmann> 5 gives us a way to avoid having multiple groups going off and trying to do the same thing (ceilometer and healthnmon)
20:05:49 <lifeless> oh god yes
20:05:52 <russellb> lifeless: tripleo applied to be a program, not incubation ;-)
20:06:00 <ttx> dhellmann: yes, 3 in boolean, 5 is float
20:06:26 <markmcclain> 5 also doesn't necessarily pick a team only that the we like the direciton
20:06:31 <lifeless> russellb: actually, we started before programs existed; our application was part of the 'oh yeah, we should change this' discussion AIRI :)
20:06:37 <ttx> OK, I'll work on documenting the process around (5)
20:06:48 <ttx> Additional question: should we still auto-create programs for incubated projects, or should we wait until they graduate to being part of the integrated release ?
20:06:59 <ttx> It affects ATC/voting rights on one side, and what level of commitment we want "program" to actually mean on the other.
20:07:06 <lifeless> I don't think an incubated project without a program makes any sense
20:07:19 <dhellmann> I agree
20:07:22 <russellb> agreed
20:07:28 <lifeless> if the project hasn't attracted the attention it needs to also qualify as a program, thats a red flag to me
20:07:31 <dhellmann> the question of which program the project will be in should be part of the application
20:07:33 <ttx> status quo would be "you shoudl have a program attached, even if that means creating it at incubation request time"
20:07:33 <jeblair> yeah, keep programs for incubated projects -- it makes sense -- they are actively working on a deliverable and making measurable progress!
20:07:46 <ttx> OK, all clear to me
20:08:41 <ttx> I'll propose a change which adds a reference/emerging-projects page full of prose that will be published somewhere
20:09:18 <ttx> anything else on that subject ?
20:09:46 <markmcclain> so the program springs into existence when they project is incubated?
20:09:56 <markmcclain> or is the program incubated too?
20:10:05 * markmcclain isn't clear on the idea here
20:10:06 <ttx> markmcclain: unless the project is already part of an existing program yes
20:10:46 <ttx> we'd not have an incubation state for programs. We'd remove the program if the project fails to incubate
20:10:59 <lifeless> so what about
20:11:10 <markmcclain> ttx: thanks for the clarification
20:11:11 <lifeless> incubation requires a program that has been around for > 3 months
20:11:37 <lifeless> give the program time to get out of the float area and be real before incubating a project
20:11:43 <dhellmann> I thought we just said we don't want programs without real projects? and "real" means incubated or graduated
20:11:50 <ttx> lifeless: that means back to option (1) up there
20:11:55 <lifeless> ttx: does it?
20:12:04 <ttx> well 5+1 admittedly
20:12:15 <dhellmann> where do programs without projects come from?
20:12:25 <lifeless> 09:03 < ttx> 5. Don't bless, just set up an "Emerging projects" page containing prose describing the
20:12:28 <lifeless> TC feedback on it
20:12:31 <lifeless> oh, I see - emerging projects
20:12:37 * lifeless sits to think for a sec
20:12:44 <ttx> lifeless: you'd require that incubation wannabees ask for a program before filing for incubation
20:12:57 <ttx> which is what the whole thread was about
20:13:13 * mtaylor doesn't understand the point of emerging projects vs. programs
20:13:29 <mtaylor> both require the TC to say "yup, that workstream seems great"
20:13:39 <mtaylor> so both are a blessing, and we'll wind up wanting critera
20:13:41 <mtaylor> criteria
20:13:53 <mtaylor> we already have programs, and programs do not require any projects in the program to be incubated yet
20:14:05 <ttx> mtaylor: (5) is a feedback, not a blessing. It's not yes/no
20:14:12 <mtaylor> it's a blessing
20:14:17 <mtaylor> it will be seen as a blessing
20:14:28 <mtaylor> because it's official feedback from us
20:14:33 <lifeless> so - let me check constraints: programs that aren't /delivering/ something are problematic [what deliver means is open for debate]; new programs (implied by new projects) want blessing to ramp up interest faster; delivering something is then key; but we don't want to add things that aren't mature to incubation.
20:14:40 <ttx> mtaylor: except anyone can ask for that feedback and receive it
20:14:44 <dhellmann> editing a wiki page isn't a blessing, is it?
20:15:04 <ttx> mtaylor: see markmc's posts on the thread
20:15:22 <lifeless> ttx: ok so I think 5 is fine : it's enough recognition to help force a collapse of the wave function from multiples to one; and its where things stay until they are really mature enough for incubation.
20:15:43 <lifeless> at the point they are that mature there should be enough interest and multi-vendor collaboration to make a program non contentious
20:16:27 <ttx> mtaylor: 5 is different from 1-4 because the feedback is in shades of grey rather than black or white
20:16:36 <mtaylor> I think it's overhead with no benefit. but I don't feel strongly enough about it to hold this up
20:16:56 <dhellmann> I don't even think the TC needs to do anything for 5 other than direct people to how to edit the right page to list themselves
20:17:24 <ttx> mtaylor: also in the thread there was the concern of making sure a "program" came with some reasonable expectation of staying there
20:17:34 <ttx> so it should not be granted to lightly
20:17:38 <ttx> too*
20:17:45 <mtaylor> the problem as I see it is that designate does things that we clearly want, and it works, and it's participating to a degree - but it's not quite ready for incubation
20:17:59 <mtaylor> so letting designate tell people that they're working on things solves nothing
20:18:12 <mtaylor> and random feedback solves nothing
20:18:20 <ttx> in the new world order, they would ask for feedback to the TC, which would be "very interesting, we want you, just mature a bit"
20:18:26 <sdague> mtaylor: it doesn't? you don't think it drives people over there
20:18:37 <dhellmann> so this page wouldn't be something anyone could edit, then?
20:18:39 <mtaylor> the actual probelm is the chicken and egg problem of resources waiting for blessing and blessing waiting for resources
20:18:42 <russellb> a TC curated list of projects we like seems like a good page to be able to go to and see what's coming
20:18:46 <mtaylor> sdague: no. I do not
20:18:59 <lifeless> but there are two sorts of resources right?
20:19:04 <dhellmann> I thought the problem was groups not having enough publicity to gain enough contributors to meet incubation requirements
20:19:07 <dhellmann> what are we trying to solve?
20:19:08 <russellb> TC curated meaning at least we're keeping it up to date, and it doesn't have stupid crap in it
20:19:09 <mtaylor> I don't think it's publicity
20:19:10 <ttx> mtaylor: I agree with you. I /fear/ that (5) won't give them the visibility they want either
20:19:13 <lifeless> there are volunteers and there are foundation sponsoed
20:19:19 <ttx> but i'm fine with giving it a try
20:19:25 <mtaylor> most of our devs are corporate sponsored
20:19:27 <lifeless> e.g. more people hacking vs -infra support when things go pearshaped
20:19:39 <ttx> markmc: o/
20:19:40 <mtaylor> which means that most of them come from product efforts - we want those to wind up in good openstack things
20:19:43 <lifeless> to get more people hacking, as mtaylor says, it's a corporate engagement issue
20:19:49 <markmc> (sorry, family stuff)
20:20:15 <mtaylor> so if it's not "OpenStack" - the people providing the devs are less likely in some cases to pony up the people - I think we're seeing this more and more now that we have so many projects
20:20:16 <ttx> markmc: mtaylor was unconvinced by your prose page, and thinks projects want to be blessed
20:20:32 <mtaylor> hrm. why am I mtaylor?
20:20:37 <markmc> sure projects want to be blessed :)
20:20:42 <ttx> mtaylor: good question
20:20:55 <lifeless> mordred: I thought you were trolling us :)
20:20:56 <russellb> mordred: thanks, i was worried about you
20:20:58 <markmc> there'll always be some point we're not prepared to bless them though
20:21:16 * markmc likes the idea of giving concrete feedback rather than ever fine-grained levels of incubating status
20:21:35 <mordred> so, if it's not a mechanism for us to 'bless' an effort or a direction, I think it's a waste and we should just do nothing because I dont' think it will appreciably change what's going on
20:21:47 <mordred> and just adding overhead for the heck of it is the last thing we need
20:22:02 <ttx> markmc: like I said, i'm fine with giving it a try, just fearing it won't get the projects what they want, so they will continue to rush incubation requests
20:22:10 <markmc> people want to know what we think of e.g. Designate
20:22:13 <markmc> what's our answer?
20:22:17 <markmc> go read the irc logs ?
20:22:19 <ttx> and preserve the chicken-and-egg issue we are trying to solve here
20:22:31 <markmc> we might invent a "promising" status to give them and every other nascent project?
20:22:47 <mordred> I mean, hell - let's try it - I might be wrong - I just think it's not going to work any better than the last time we tried it
20:22:51 <lifeless> I think the real question is:
20:22:52 <markmc> people just want to know what we think of it, how it's likely to proceed, what we think it needs
20:23:04 <lifeless> - do we want other companies to compete with e.g. designate or
20:23:13 <lifeless> - do we want them to collaborate on e.g. designate
20:23:19 <mordred> we used to have a special category for ecosystem projects - atlas lb wound up there
20:23:22 <mordred> look at how that worked
20:23:25 <russellb> is the "emerging projects" page proposed with #5 something maintained through the governance repo?
20:23:25 <annegentle_> mordred: do you sense that designate is getting stalled because of the tc or other factors?
20:23:28 <russellb> or is it just a random wiki page?
20:23:28 <ttx> lifeless: the latter, at this point
20:23:34 <lifeless> And and *what point* do we signal to other companies that we want this to happen.
20:23:36 <markmc> lifeless, whatever gets us a viable project, in the end
20:23:38 <lifeless> Blessing is all about that.
20:23:40 <ttx> russellb: governance repo
20:24:08 <lifeless> markmc: ttx: It was a rhetorical question meant to frame discussion :)
20:24:13 <russellb> ttx: if it's in our repo, then it's sure going to look like a blessing to some degree, right?
20:24:13 <annegentle_> and I agree with lifeless's heart of the matter
20:24:28 <markmc> lifeless, rhetorical question means implied answer - you just got two different answers :P)
20:24:35 <lifeless> markmc: :)
20:24:46 <ttx> russellb: maybe.
20:24:46 <lifeless> So actually I think that shows up the issue
20:24:47 <lifeless> ...
20:24:50 <ttx> OK, let's try it
20:24:55 <lifeless> there are two big phases we go through for new projects
20:24:56 <markmc> lifeless, an issue, for sure
20:25:03 <lifeless> there is the thousand flowers blooming phase
20:25:09 <ttx> nobody says it's wrong, seom people think it's not enough
20:25:18 <russellb> fair enough.
20:25:18 <ttx> let's try it and see
20:25:21 <markmc> if we were sure designate was absolutely the way forward, why not incubate it?
20:25:24 <lifeless> where there are lots of independent attempts, some proprietary, some open and unaffiliated, some affiliated with openstack
20:25:27 <sdague> ttx: +1 - I say try, and try to fail quickly if it's wrong
20:25:29 <markmc> we're not - a community hasn't formed around it?
20:25:41 <lifeless> and then we incubate one and it all changes - it's a phase transition
20:26:02 <lifeless> I think the thing we're struggling with is just where we trigger the transition
20:26:05 <ttx> let's go to practical exercise now, Barbican.
20:26:25 <lifeless> And having reframed it this way, I'm now changing my opinion on what we should do :)
20:26:33 <ttx> ow.
20:26:50 <lifeless> ttx: go on, barbican ?
20:27:03 <ttx> #topic Barbican incubation request
20:27:16 <mordred> markmc: how many of our projects formed a community pre-blessing?
20:27:17 <ttx> lifeless: thought you were disagreeing with way forward
20:27:19 <mordred> markmc: honestly
20:27:21 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2013-December/020830.html
20:27:21 <lifeless> ttx: Oh I am
20:27:26 <ttx> #link https://wiki.openstack.org/wiki/Barbican
20:27:44 <russellb> and
20:27:46 <dhellmann> mordred: was there a blessing for ceilometer that I'm not aware of?
20:27:46 <russellb> #link https://wiki.openstack.org/wiki/Barbican/Incubation
20:27:59 <markmc> mordred, sure - that's what we want - and "blessing" becomes about recognizing that
20:28:14 <mordred> markmc: I'm saying I think it might be unreasonable
20:28:19 <ttx> lifeless: so should we continue to discuss it ?
20:28:33 <markmc> mordred, oh, I see - so, were we unreasonable not to bless designate?
20:28:40 <mordred> markmc: no - I'm not saying that
20:29:12 <mordred> I'm saying that we might have a expectation that projects are going to grow vibrant communities outside of our context, and I'm not sure we have much evidence that that ever happens
20:29:23 <mordred> as we are a lovely incubator for community formation
20:29:27 <jeblair> mordred: neutron, ceilometer, heat, trove, ironic, marconi, savanna, tripleo all formed communities before blessing.
20:29:33 <mordred> jeblair: I disagree
20:30:03 <mordred> jeblair: neutron was blessed by fiat back in the ppb days, heat was largely redhat, ironic was a nova splitout
20:30:49 <ttx> mordred: let's go back to this if there is tima at the end of meeting
20:30:56 <mordred> ok
20:31:04 <ttx> so, second session on barbican
20:31:14 <ttx> I don't think this week actually changed my view on this... quoting me from last week:
20:31:21 <ttx> <ttx> it looks like the scope of the project is well-defined and makes sense
20:31:28 <ttx> <ttx> there are some concerns about team size/diversity and some work to be done before filling all the current requirements for incubation
20:31:50 <russellb> though +1 for the team working quickly on the incubation requirements in the last couple of weeks
20:31:54 <ttx> I liked the recent discussions around whether it could belong to the Identity program or not -  really appreciated
20:32:15 <jraim> At this point, we've nailed down the technical reqs. Oslo.messaging has landed and after a rebase, pbr and global-reqs will land
20:32:20 <ttx> ultimately barbican / secrets management warrants its own program... separate from identity/auth.
20:32:28 <russellb> jraim: devstack-gate still pending right?
20:32:32 <sdague> the relatively concrete tasks on testing (testr & d-g jobs) aren't done yet
20:32:40 <jraim> russellb yeah, we needed pbr and globals first, which needed oslo
20:32:44 <jraim> so a bit of a house of cards
20:32:46 <russellb> k
20:33:06 <jraim> testr is done in branch, but we need to work through the implications on our existing testing
20:33:13 <jraim> should be soon (tm)
20:33:40 <ttx> if I were to write feedback in prose, I'd say "we want that, and really close to meet technical incubation requirements"
20:34:14 <ttx> but then, I have concerns with team diversity. And I fear not blessing them in any way won't give them an easy way to solve that one
20:34:28 <lifeless> so this is the bit mordred is talking about
20:34:33 <lifeless> and in a way me too
20:34:36 <jraim> I did ask some people that have expressed interest to say so on the list
20:34:48 <jraim> So we saw some traffic from RedHat, HP and Nebula
20:34:49 <russellb> it's cheap to express interest, though
20:34:53 <lifeless> I think by saying 'you know, you're /nearly there/' we're well past the point where we want to see more competition
20:34:54 <russellb> that doesn't mean a whole lot
20:34:54 <sdague> so we just went through making technical requirements for the bar you had to pass to incubate
20:34:58 <ttx> lifeless: yes, and why I think ultimately (5) won't give them enough visibility to reach critical mass
20:34:58 <jraim> and we have an active contributor from eValut that strated recently
20:35:06 <mordred> lifeless: ++
20:35:06 <lifeless> I think we're into the 'we want collaboration' phase of the lifecycle.
20:35:08 <annegentle_> the team diversity concern is why we are also discussing designate in a similar vein
20:35:28 <sdague> so I really think those a requirements to complete first, and the whole thing is sort of moot until that's checked off.
20:35:48 <lifeless> sdague: some of our requirements are more social than technical
20:35:49 <russellb> sdague: yeah but realistically they could have the rest of those requirements checked off by january
20:35:55 <mordred> we're not questioning if we want this thing, and I don't think we actually are afraid it's going to top having devs this instant - I _do_ think that we dont' want to graduate it without a bunch of things
20:35:56 <lifeless> sdague: and the team can't do /those/ on their own.
20:35:56 <russellb> and then we're back to the team diversity questions
20:35:59 <markmc> lifeless, honestly, if we're past the point of wanting to entertain any competition - it's time to incubate
20:35:59 <jraim> russellb that's our plan
20:36:09 <sdague> lifeless: sure
20:36:11 <lifeless> markmc: I agree
20:36:13 <mordred> markmc: ++
20:36:25 <lifeless> mordred: I was leading there gently ;)
20:36:26 <sdague> russellb: also, sure, but if today is an incubation vote, then it should be a clear "no"
20:36:26 <russellb> fair point
20:36:27 <lifeless> bah
20:36:29 <lifeless> markmc: ^
20:36:38 <russellb> so maybe the team diversity question should be more about graduation than incubation?
20:36:43 <lifeless> russellb: yes!
20:36:46 <russellb> sdague: yep, but might as well discuss
20:36:56 <jraim> I think we would be fine picking this back up in Jan once we've merged the last technical bits
20:37:01 <ttx> markmc, lifeless, mordred: so what you're saying is.. we should NOT have team diversity/size requirements in incubation requirements ?
20:37:15 <lifeless> ttx: Size yes, diversity no. IMO.
20:37:24 <sdague> jraim: yeh, realistically that's what I'm proposing.
20:37:25 <jraim> But as people have said, the team composition probably isn't going to change by then
20:37:26 <russellb> and add diversity for graduation, yes?
20:37:29 <mordred> russellb: ++
20:37:40 <russellb> that seems reasonable i think
20:37:48 <markmcclain> I think diversity should be part of incubation
20:37:53 <ttx> lifeless: could you expand on that in a way that would be fair to designate ?
20:37:53 <mordred> it takes time to grow team, and it takes a decent investment by devs to earn that team status
20:37:53 <jeblair> i think diversity is important for incubation and we should hold our standards there
20:37:54 <markmc> diversity is important, but more for graduation I think
20:38:01 <markmcclain> otherwise we'll have large entities apply based on team size
20:38:09 <mikal> Has anyone taken a look at if barbican is using all the bits of olso we think it should?
20:38:11 <lifeless> ttx: rationale: If a company sponsors a project that we are convinced makes sense for the project technically and scope wise, and they fund it to a sufficient degree... meet technical merits, and stability...
20:38:19 <russellb> well we'll have to look at relative contributions when looking at size
20:38:21 <jeblair> incubation means devoting limited openstack-project-wide resources to a project
20:38:34 <jeblair> and i don't think that's appropriate to do when a project has only managed to get contributors from one vendor
20:38:41 <ttx> lifeless: i'm easily convinced in my evenings
20:38:42 <dhellmann> jeblair: +1
20:38:45 <sdague> jeblair: +1
20:38:53 <markmcclain> jeblair: +1
20:39:06 <annegentle_> ttx: must be the dinner wine
20:39:09 <ttx> I'm with jeblair on that
20:39:22 <mikal> Has anyone taken a look at if barbican is using all the bits of olso we think it should?
20:39:22 <mordred> I think with some of the smaller projects we're not going to get contributors from other vendors until it's incubated
20:39:26 <lifeless> why not? Ignore the single vendor aspect for a second
20:39:29 <lifeless> If:
20:39:32 <lifeless> - we want the project
20:39:36 <markmc> I think there's a point between "single company dominated and controlled project" and diverse project
20:39:45 <lifeless> - we want collaboration at this point, not competition
20:39:46 <mordred> and also - I argue all the time that nobody should care that I work for HP
20:39:52 <jraim> mordred that's my concern
20:39:54 <lifeless> - it's the only one being offered up to us
20:40:05 <markmc> i.e. a "totally open and meritocratic, in excellent shape, crying out for others to come along and play" project
20:40:05 <lifeless> => how is it inappropriate?
20:40:33 <markmc> lifeless, diversity is important for long-term viability, is the point
20:40:36 <jeblair> lifeless: it could indicate a lack of viability
20:40:51 <ttx> lifeless: I guess it boils down to: do we want 2 stages of incubation (tech + social requirements met) or just one
20:40:56 <lifeless> markmc: totally agreed, but the chicken and egg problem ttx describes is /all about collapsing the competition function/
20:41:05 <jeblair> it might suggest there's something about how the project is run so that others are having trouble participating; or it could mean no one outside of that company is interested
20:41:18 <mordred> HP funded infra single-handedly for a while - did that make any of us think that infra was somehow less OpenStack worthy?
20:41:29 <dhellmann> right, if a project comes along in that state I wonder why that company hasn't *already* started trying to find other contributors
20:41:33 <mordred> or did it mean that HP was the only one with a person who was fighting to put employees on it
20:41:36 <lifeless> jeblair: it could, and thats the question. Monty doesn't see a lot - any - evidence that viability correlates with diversity pre-incubation
20:41:41 <lifeless> in fact, I would point at neutron
20:41:42 <ttx> mordred: I'd argue it's a bit of a corner case.
20:41:46 <markmc> lifeless, so, do we do that only after diversity is achieved or in order to encourage diversity - that's the question
20:41:53 <lifeless> and say that diversity is at best a weak predictor of viability
20:41:56 <mordred> ttx: I wouldn't - geting FTEs on a project is hard
20:42:02 * markmc is okay with using it to encourage diversity if everything else is in great shape
20:42:11 <mordred> ttx: it's even harder when companies do not see product potential
20:42:13 <lifeless> markmc: yeah, thats where I have circled around to
20:42:21 <markmc> and we believe the project is truly welcoming, meritocratic, etc.
20:42:22 <jeblair> lifeless: monty struck a number of projects from my quick list, but not all of them
20:42:23 <lifeless> we shouldn't go light on /technical requirements/
20:42:34 <mordred> and they have a BUNCH of openstack projects to contend with - so if they have to choose between putting people on barbican or on nova ...
20:42:49 <jeblair> i think we've switched back to the other topic.
20:43:03 <ttx> yes, let's stop for a sec
20:43:14 <ttx> I think we owe barbical an answer
20:43:18 <ttx> Barbican*
20:43:21 <lifeless> lol
20:43:24 <lifeless> I like the new name
20:43:41 <ttx> and I think it should be: come back to us when all tefchnical checkboxes are crossed, which should be anytime now
20:43:50 <sdague> ttx: +1
20:43:57 <mikal> ttx: I'd like to dig into oslo and barbican a bit more if I could
20:43:57 <lifeless> +1
20:43:59 <jraim> ttx That's fine with us
20:44:02 <ttx> rather than rush the decision today while they are not all crossed
20:44:24 <dhellmann> is there an official checklist they are working from?
20:44:33 <jraim> mikal If we take this back up in Jan, would that give you enough time to dig in a bit more?
20:44:39 <ttx> jraim: hopefully we'll have gotten our mind together on the spcoam aspect in the mean time
20:44:41 <sdague> #link https://wiki.openstack.org/wiki/Barbican/Incubation
20:44:42 <mikal> jraim: sure
20:44:45 <sdague> dhellmann: ^^^
20:44:51 <dhellmann> sdague: thanks
20:44:52 <mikal> jraim: mostly I want to dicsuss it and reach a concensus
20:44:52 <sdague> twards the bottom
20:44:52 <ttx> s/spcoam/social
20:45:00 <mikal> jraim: but that can wait, so long as we do it before voting...
20:45:22 <jraim> mikal that's fine. We're on #openstack-barbican if you have questions
20:45:23 <ttx> #topic incubation vs. recognition
20:45:37 <ttx> ok, back to the bazaar
20:45:42 <mikal> Heh
20:45:56 <ttx> so, like I said, it boils down to...
20:46:20 <mordred> tripleo was all HP when it got accepted, trove only picked up a second vendor because of internal herculean efforts by jcooley, savanna was questionable as to real diversity but we made a judgement call
20:46:27 <jeblair> mordred: i'm sensitive to what you're saying about getting companies to contribuet fte to a project; maybe you can help me understand how incubation helps there -- how does that make them see product potential and devote fte?
20:46:32 <ttx> should we care about diveristy at incubation time
20:46:45 <lifeless> mordred: we had sigificant rackspace and bluebox interest - even a couple patches IIRC
20:46:47 <mordred> jeblair: yes, it does
20:46:48 <ttx> jeblair says yes
20:46:51 <lifeless> mordred: + some early redhat fixes
20:46:51 <ttx> mordred says no
20:47:04 <lifeless> mordred: but we didn't have any non-HP -core.
20:47:07 <mordred> jeblair: because it makes them se that they're going to need to engage with the project coming down the pipeline
20:47:20 <markmc> could we be more explicit about long term viability - e.g. identify things that could prevent diversity ?
20:47:32 <lifeless> jeblair: I would say it doesn't help them see product potential.
20:47:34 <markmc> rather than making it a numbers game
20:47:42 <mordred> jeblair: also, it shows them that it's more costly to do internal private dev than to collaborate with openstack
20:47:47 <lifeless> jeblair: it helps them see where they need to collaborate vs wrap
20:47:54 <jeblair> markmc: a single vender changing their mind and retasking/laying off a team seems like a big risk
20:47:56 <mordred> without that, it's the question of collaborating with 'random-open-source' - which does not carry the same weight right now
20:48:13 <ttx> incubation triggers non-trivial support efforts from various programs in openstack... Should we require a minimum of diversity before granting those ?
20:48:14 <mordred> jeblair: right. which is why I think it's _ESSENTIAL_ for graduation
20:48:25 <lifeless> jeblair: the mindset many vendors have is 'we need X for our customers, is X part of OpenStack? No -> spin up a team and build it in-house. Yes? Collaborate'
20:48:31 <mordred> lifeless: ++
20:48:35 <markmc> jeblair, oh, it is - it's extremely important for graduation IMHO
20:48:51 <mordred> I think there is no dissent that diversity is required for graduation, actually
20:48:55 <jeblair> mordred: half of our development infrastructure is now devoted to helping new projects bootstrap themselves in our environment
20:49:01 <lifeless> jeblair: some orgs build it in-house and open source it (which is how e.g. designate came about AIUI)
20:49:04 <sdague> so we should probably be giving our existing incubating projects a report card on how they are doing there
20:49:06 <mordred> jeblair: that is true
20:49:12 <lifeless> jeblair: others build it in-house and sell it as part of their offering.
20:49:26 <annegentle_> I'm with jeblair on concerns about halving resources just to help out incubating projects
20:49:58 <lifeless> jeblair: either way, the lack of a 'this is part of OpenStack' creates a void, which for some companies is an opportunity, for others a weakness
20:50:02 * mordred still points out that other companies are welcome to contribute FTEs to Infra - which would help
20:50:08 <annegentle_> we've seen difficulty with large projects like neutron getting vendor support but not core support, so there's some nugget of concern about too much diversity too.
20:50:30 <annegentle_> jus' sayin'
20:50:39 <lifeless> annegentle_: +1. Though I wouldn't say 'too much diversity', I would say thats a cultural norm issue.
20:50:48 <sdague> annashen: I think that's a different issue
20:50:51 <annegentle_> I'm more leaning towards concerns about long term viability -- and user and operator uptake.
20:50:53 <lifeless> annegentle_: We want a norm of 'we're all building this together' within teams.
20:51:00 <sdague> lifeless: +1
20:51:12 <lifeless> not, a 'ok there is an API shuim and ALL MY GOODNESS IS PROPRIETARY'
20:51:16 <jeblair> annegentle_: i agree, it does suggest that it's more than just numbers we need to consider
20:51:16 <annegentle_> lifeless: yes I like collab models better than compete
20:51:25 <mordred> jeblair: ++
20:51:32 <mordred> or, annegentle_ ++ rather
20:51:59 <lifeless> jeblair: so concretely, what I'm suggesting is tht when we - the TC - /want/ the project [vs it being pushed onto us]
20:52:13 <lifeless> jeblair: that all the questions about infra resources etc are moot: we've already decided *we want it*
20:52:14 <ttx> One question is, would we punt projects from incubation because they fail to get more diverse ?
20:52:18 <lifeless> the questions that matter are:
20:52:37 <lifeless> - is it technically viable - all the stuff we seem to agree on
20:52:54 <lifeless> - and some thorny social assessment, do we expect it to play well with others and have good norms
20:53:17 <lifeless> All I'm saying is that we can't really assess the second via a hard rule of 'X vendors involved' because of the dynamics of how vendors get involved.
20:53:27 <lifeless> It's the heart of the chicken and egg issue.
20:54:17 <ttx> lifeless: would you say we rejected designate on a diversity argument, or a size argument ?
20:54:33 <ttx> mordred: ^
20:54:38 <markmc> I'd say both
20:54:45 <markmc> diversity definitely came into it, though
20:55:04 <markmc> if it was a larger team, it might have been a good discussion as to whether we could have passed on diversity
20:55:13 <ttx> OK, 5min left, we need to move on, let's push that to a thread
20:55:45 <ttx> mordred, lifeless: and since you seem to care about it, please participate to it
20:56:07 <ttx> because nothing in the thread posted last week actually let us anticipate your concerns
20:56:13 <markmc> heh
20:56:22 <ttx> since you didn't post to it.
20:56:36 <jeblair> looking at barbican's irc meeting logs
20:56:38 <jeblair> http://eavesdrop.openstack.org/meetings/barbican_weekly_meeting/2013/barbican_weekly_meeting.2013-12-05-20.01.log.txt
20:56:44 <jeblair> there are 78 lines
20:56:51 <ttx> #topic J naming determination process
20:56:57 <ttx> #link http://lists.openstack.org/pipermail/openstack-tc/2013-December/000444.html
20:57:02 <lifeless> ttx: I hadn't gotten to the heart of it before
20:57:06 <ttx> Unless there are objections, I'll follow the SurveyMonkey route with the 10 candidates mentioned on:
20:57:07 <lifeless> ttx: before the meeting it all sounded plausible.
20:57:08 <jeblair> how do we determine the viabality of a community based on so little evidence
20:57:14 <lifeless> ttx: then new data -> ideas -> changed opinion
20:57:17 <ttx> #link https://wiki.openstack.org/wiki/ReleaseNaming
20:57:29 <lifeless> jeblair: perhaps we don't; perhaps we make it easy to handle failures instead?
20:57:30 <sdague> ttx: +1 survey monkey
20:57:32 <ttx> lifeless: apology accepted :)
20:57:33 <mordred> ttx: ++
20:57:45 <annegentle_> Survey monkey ftw
20:57:48 <dhellmann> ttx: +1
20:57:52 <jeblair> ttx: wfm
20:57:54 <notmyname> let's please not name a release after other major open source projects (jekyll)
20:58:12 <lifeless> Jenkins!
20:58:14 <ttx> notmyname: I actually got the express authorization from Tom Preston-Warner
20:58:30 <ttx> that we can reuse jekyll in that context
20:59:00 <dhellmann> #link http://jekyllrb.com/
20:59:13 * dhellmann doesn't think there's anything static about openstack
20:59:26 <ttx> Nick Quaranto also agreed there was no namespace overlap
20:59:41 <ttx> both were fine with us reusing it for a release cycle na�e
20:59:44 <ttx> name
20:59:50 <ttx> #topic Other governance changes in progress
20:59:53 <ttx> quickly
20:59:57 <lifeless> 60 seconds
20:59:58 <ttx> Provide infrastructure for publishing docs to docs.openstack.org: https://review.openstack.org/#/c/61380/
21:00:05 <ttx> This one is more technical than governance, so I'm fine with approving it once infra / Anne vets it
21:00:12 <ttx> Attach extra ATCs to programs: https://review.openstack.org/#/c/62009/
21:00:14 <annegentle_> so I don't get it
21:00:17 <ttx> This one will be approved as soon as it reaches enough approvals
21:00:39 <ttx> annegentle_: ask question
21:00:50 <annegentle_> is the proposal to provide only sphinx/oslo infra for publishing docs? or to provide sphinx/oslo infa for publishing governance pages that are considered sources of truth?
21:01:09 <jeblair> annegentle_: one of the things we talked about when moving the tc motions into git was that we could publish what we produce
21:01:10 <ttx> the latter, I think
21:01:13 <annegentle_> that's at the heart of my comment about the commit message possibly being misleading. It made me read it twice.
21:01:24 <sdague> annegentle_: it is providing infrastructure so that we can publish contents of the repository to the web
21:01:24 <annegentle_> if it's the latter, then why not publish to the wiki?
21:01:24 <jeblair> annegentle_: so essentially governance is a doc repo only
21:01:27 <jeblair> annegentle_: so the latter
21:01:36 <sdague> vs. sending people to git urls
21:01:40 <sdague> which is what we do now
21:01:44 <ttx> annegentle_: because it's not really simpler
21:01:52 <annegentle_> I have concerns about publishing to docs.o.o: version tracking, keeping history, search capability, and where do bugs get tracked
21:02:01 <ttx> ok, time is up, move discussion to corresponding review.
21:02:08 <annegentle_> git is a perfectly good publishing system
21:02:08 <sdague> and I'm -1 to publishing to wiki automatically anyway, because a wiki is a rw medium
21:02:10 <sdague> and this isn't
21:02:20 <ttx> #endmeeting