20:03:17 <ttx> #startmeeting tc
20:03:18 <annegent_> no one else wrote such an eloquent rsvp as mikal
20:03:18 <openstack> Meeting started Tue Mar  3 20:03:17 2015 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:03:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:03:21 <openstack> The meeting name has been set to 'tc'
20:03:39 <ttx> I must admit that was an eloquent absence note
20:03:48 <ttx> Our agenda for today:
20:03:52 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:04:02 <ttx> #topic openstack-specs final rubberstamping
20:04:07 <jeblair> can i put forward a motion to postpone the meeting?
20:04:37 <dhellmann> jeblair: grounds?
20:04:44 <jeblair> 20:02 < ttx> We have a number of members half-present due to concurrent board meeting
20:04:44 <ttx> jeblair: err... I guess? But next week is the ops summit which a few of us will attend as well
20:05:00 <ttx> jeblair: even counting half-present memebrs as absent we do have quorum though
20:05:22 <ttx> even if we don't count you
20:05:38 <annegent_> quorum is quorum is quorum
20:05:42 <jeblair> okay.  i just wanted to throw it out there for discussion.
20:06:05 <jeblair> i see how it is, thanks
20:06:06 * russellb certainly ok with skipping, but biased
20:06:07 <dhellmann> perhaps we can try to avoid this sort of overlap in the future
20:06:26 <ttx> dhellmann: it's not as if that meeting occurred at this hour for the first time
20:06:26 <dhellmann> I'd be ok with skipping, but I'm not sure we want to go 2 weeks without meeting
20:06:35 <dhellmann> ttx: do we have anything pressing?
20:06:36 <jgriffith> silly BOD, they know when we meet :)
20:06:42 <markmcclain> jeblair: is there something on the agenda that perhaps we should delay if we feel that slim quorum is not representative enough for discusssion?
20:07:02 <ttx> dhellmann: well, I'd like to make progress on a number of items, yes, especially if we skip next week
20:07:10 <jeblair> markmcclain: perhaps not
20:07:12 <russellb> what's next week
20:07:20 <ttx> russellb: ops summit
20:07:25 <russellb> ah
20:07:25 <dhellmann> ttx: yes, and to be fair the folks on both committees could have raised that but we are where we are so I'm ok with discussing a delay
20:07:48 <ttx> I think we have things to rubberstamp and we don't really need all members 100% attention to so that
20:08:01 <ttx> we have quorum so I'd prefer if we proceeded
20:08:01 <dhellmann> ttx: sure, let's do the easy things first :-)
20:08:04 <jeblair> okay.  i'm okay with meeting today and next week.
20:08:20 <ttx> so, rubberstamping
20:08:39 <ttx> jeblair: if there is anything you think where the decision should be postponed, I'm fine doing thatr
20:08:46 <ttx> But I seriously doubt there will be
20:08:51 <jeblair> ttx: sounds like a plan
20:08:53 <ttx> * Add TRACE definition to log guidelines (https://review.openstack.org/#/c/145245)
20:08:59 <ttx> I'd say this one has reached consensus and can be approved.
20:09:31 <ttx> feel free to pile up a few more +2s
20:09:49 <ttx> we have 6 if sdague posts his
20:10:13 <sdague> ttx: well I wrote it
20:10:13 <ttx> and 7 if markmcclain reposts his
20:10:19 <sdague> so it seems rude to +2
20:10:22 <markmcclain> done
20:10:42 <dhellmann> sdague: I think your +2 is assumed there :-)
20:10:45 <ttx> Any last votes or comments before I +1 it ?
20:11:13 <ttx> ok, approved
20:11:24 <ttx> #topic Definition of the release:* tags
20:11:29 <ttx> #link https://review.openstack.org/157322
20:11:38 <ttx> So.. there are divergent views on what the tags should be named, and I'd like to converge on one
20:11:46 <ttx> Original proposal was release:common, release:coordinated, release:compatible, release:free
20:11:54 <ttx> annegentle suggested release:independent instead of release:free
20:11:57 <annegent_> ttx: jaypipes asked about audience, downstream or upstream priority would be a good discussion to have here
20:12:01 <ttx> I agree with that and pushed a new patchset with it
20:12:05 <ttx> annegent_: getting to it
20:12:10 <annegent_> ttx: ok cool
20:12:11 <ttx> devananda suggested release:managed instead of release:coordinated
20:12:15 <ttx> I also agree with that
20:12:23 <annegent_> +1 on that too
20:12:25 <ttx> devananda / notmyname suggested we change release:common to something more descriptive or that doesn't imply majority share or anything
20:12:35 * notmyname lurks
20:12:43 <ttx> Yesterday jaypipes suggested we switch from a release model category approach (where you belong to only one) to an release model attribute approach (where you can combine multiple attributes)
20:12:50 <ttx> release-managed, release-periodic-6mo, release-with-milestones, release-independent
20:13:02 <ttx> Some of the one-liner proposed definitions for them appear to be exclusive while they are not meant to, so they probably need a bit of work
20:13:17 <ttx> I would also rename "with-milestones" to "with-shared-milestones" or "standard-cycle" or something, since that's the only milestones we currently have
20:13:47 <ttx> annegent_: to answer your question, I think they should be used primarily downstream
20:13:49 <jgriffith> ttx: so thoughts on dhellmann 's proposal for synchronzied vs jaypipes 's changes?
20:14:06 <annegent_> I like that rename too. -with-shared-milestones probably slightly better for the avoidance of "value" in "standard"
20:14:13 <ttx> but they should be precise enough so that upstream can use them to describe or organize their work too
20:14:23 * dhellmann wonders if it wouldn't be simpler to just let projects describe their release process in their own projects
20:14:30 <jgriffith> dhellmann: +1
20:14:42 <jgriffith> dhellmann: but you'd have to have consistent tags IMO
20:14:45 <ttx> dhellmann: that would make my job a bit difficult
20:15:02 <ttx> I need to put projects into buckets, I handle a lot
20:15:02 <dhellmann> ttx: in what way? just communicating downstream?
20:15:07 <dhellmann> ah
20:15:18 <devananda> dhellmann: + to describing how their teams work, - to not having any consistency across projects when it comes to release cadense
20:15:22 <ttx> I need to remember which one I handle, which ones use which model
20:15:39 <devananda> dhellmann: this also informs distro packagers in a significant way
20:16:04 <ttx> How do you all feel about an attribute based approach vs. a model based approach ?
20:16:14 <ttx> i.e. jaypipes AND style rather than my OR style
20:16:27 <jgriffith> ttx: can you expand just a little
20:16:37 <dhellmann> devananda: this goes back to my argument that we don't need a lot of these tags at all if we just go write things down in documentation
20:16:48 <ttx> jgriffith: so my approach was to dscribe a set of release models and ask projects to pick
20:17:01 <ttx> I would have one tag per model
20:17:02 <devananda> ttx: I can see benefits to both, but I'm still leaning towards the OR style
20:17:02 <annegent_> I think AND style is pretty accurate.
20:17:21 <annegent_> does put some cognitive burden on the tag reader
20:17:43 <ttx> Jay's approach is to describe attributes of release models (like "does a release every 6 months")
20:17:52 <dhellmann> ttx: are there a set of tags using Jay's approach that would meet your needs for bucketing?
20:17:56 <ttx> and then let projects dsecribe what they do by combining those attributes
20:18:17 <jgriffith> ttx: so I'm always a sucker for the simpler approach that still works
20:18:19 <ttx> dhellmann: I need to chefck that all the combinations are a supportable bucket :)
20:18:31 <jgriffith> ttx: in other words IMHO the OR model is a bit more clear and still gives benefit
20:18:38 <ttx> jgriffith: I'd not sure which is simpler, tbh
20:18:48 <annegent_> I think docs has a similar bucketing need
20:19:04 <jgriffith> ttx: well, only in terms of "me" having it in my head :)
20:19:06 <ttx> I'm fine taking Jay's proposal and checking that it works, and proposing definitions for those
20:19:18 <dhellmann> if we can identify the facets, the AND style seems simpler but if it produces combinations we don't want to support maybe that's reason enough to stick with OR
20:19:20 <ttx> just want to make sure that's your preferred solution
20:19:38 <notmyname> ttx: how is your tag bucket method (OR) different than "integrated" "incubated" etc?
20:19:41 <ttx> dhellmann: we could also describe exceptions to the OR rule
20:19:57 <devananda> ttx: I could see a project needing to have 3 of those 4 tags though
20:20:08 <notmyname> the AND method allows for more precise descriptions and flexible buckets
20:20:18 <jgriffith> devananda: that's where things get convoluted for me
20:20:23 <ttx> release-with-milestones and release-independent are exclusive for example
20:20:28 <jgriffith> but that could be just me
20:20:39 <devananda> ttx: no they're not?
20:20:57 <ttx> devananda: describe a project that would follow that ?
20:20:58 <notmyname> jgriffith: aren't tags AND anyway? ie if there are multiple tags on a project, they are AND
20:20:59 <devananda> ttx: a project could release its own milestones independelty from the sycnrhonized cycle, not managed by you
20:21:11 <devananda> ttx: stackforge/ironic-discoverd
20:21:19 <notmyname> jgriffith: IOW you'll always be composing tags in your head, even with the proposed OR release tags
20:21:28 <ttx> devananda: oh, I meant the with-shared-milestones renamed variant
20:21:31 <devananda> and python clients
20:21:45 <jgriffith> notmyname: sure, but I guess I might be viewing this wrong
20:21:55 <ttx> devananda: python clients do not follow milestones
20:21:56 <jgriffith> notmyname: the OR to me means "it's this one or that one"
20:22:10 <devananda> ah - of course
20:22:11 <jgriffith> notmyname: the AND means, there's this collection that all have different implications
20:22:22 <jgriffith> notmyname: and I have to decode what the end result means
20:22:33 <ttx> devananda: agree that you could invent a project that has milestones but not the shared ones
20:22:48 <ttx> not sure that would need a tag though (original-milestones)
20:22:49 <jgriffith> maybe not a big deal
20:23:08 <annegent_> devananda: ttx: yeah it's the commonality that matters due to assuming integrated testing?
20:23:17 <jgriffith> notmyname: could be the I'm over-complicating it :)
20:23:25 <lifeless> jeblair: I'm entirely happy with moving it
20:23:29 <lifeless> bah, sorry
20:23:53 <ttx> so what's your general feeling ? Should I scrap myu version and start again by iterating on  Jay's list
20:23:59 <ttx> ?
20:24:03 <devananda> i think we have two (maybe more?) orthogonal dimensions here: who manages the release? how often are releases (and their related artefacts) tagged?
20:24:28 <ttx> devananda: that sounds simpler, since we ahve a tag for describing that
20:24:48 <ttx> release:managed means release management is handled by the release mgmt team
20:24:58 <ttx> if you don't have the tag, then you do it yourself
20:25:13 <devananda> we don't need two sets of tags
20:25:25 <devananda> it reduces to (A || B) && (C || D)
20:25:37 <ttx> devananda: ?
20:25:48 <dhellmann> under ttx's definition, release:managed implies some of the other settings, though
20:26:11 <ttx> dhellmann: release:managed is the pet tag for the release management team describing projects we agree to handle
20:26:27 <dhellmann> right, and those follow the 6 month cycle, use milestones, etc.
20:26:38 <ttx> yes
20:26:48 <devananda> release mgmt (manages || does not manage) the release && release is (synchronized || not synchronized)
20:26:49 <dhellmann> so you wouldn't have a managed project not using milestones, but you might have an unmanaged project using them
20:26:49 <notmyname> timing is differnet than releasing right? as devananda said
20:27:03 <notmyname> *who is releasing
20:27:22 <dhellmann> notmyname: they are only separate if the release team is not managing the release, I think
20:27:27 <devananda> dhellmann: right. of the 4 possible combinations, only 3 are actually sensible
20:27:29 <ttx> notmyname: in theory yes, in practice, no
20:27:37 <devananda> dhellmann: and we dont need two sets of tags to represent that
20:27:47 <dhellmann> right
20:28:28 <devananda> ttx: I have convinced myself that we dont need the AND approach here
20:28:38 <jaypipes> sorry all, reading back...
20:28:40 <ttx> devananda: ah, interesting
20:29:21 <ttx> devananda: not sure how to proceed now. Whatever the direction I take, everyone seems to be unhappy
20:29:32 <devananda> heh
20:29:40 <devananda> names are hard
20:29:59 <dhellmann> ttx, devananda : I think you want a combination. A project is either managed, or it gets to pick a la carte from the other tags
20:30:27 <devananda> dhellmann: you'd have non-managed projects pick >1 tag to self-apply/
20:30:29 <devananda> ?
20:30:36 <ttx> dhellmann: although I guess we should support the corner case that the relmgmt team can opt to support an outlier
20:30:44 <ttx> heck, I did it for the last 4 years
20:30:53 <devananda> dhellmann: that seems more confusing
20:30:57 <annegent_> ttx: I think it's difficult not just for naming but for integrated release management being a limited resource?
20:31:31 <jaypipes> "there's a tag for that" <-- new OpenStack motto.
20:31:41 <ttx> devananda: I don't think the AND approach (Jay's approach) is more confusing
20:31:59 <devananda> ttx: i meant the combination of OR + AND that i think dhellmann just proposed
20:32:19 <devananda> either(release:managed) or(pick from list of other tags)
20:32:24 <ttx> devananda: consider handled-by-relmgt-team separately
20:32:24 <dhellmann> how about release:managed; release:periodic with attribute for period in months; release:independent (xor with release:periodic); release:uses-stable-branches
20:32:32 <ttx> it is separate from the others
20:32:52 * devananda ponders
20:33:30 <ttx> not sure what you mean by release:uses-stable-branches
20:33:43 <ttx> common stable branches like the 6-month ones ?
20:33:46 <devananda> dhellmann: so oslo would be release:independent + release:usesstable-branches ?
20:33:49 <dhellmann> ttx: some independent projects won't use stable branches
20:33:54 <dhellmann> devananda: right
20:34:18 <dhellmann> I don't know if swift uses stable branches, but if not it would just be release:independent
20:34:19 <ttx> dhellmann: I think it fails to describe the swift model
20:34:33 <ttx> it's not really periodic but they releae at the end of the cycle
20:34:50 <jaypipes> ttx: that is periodic, no?
20:34:54 <dhellmann> ttx: so add release:synchronized to account for that case?
20:35:01 <dhellmann> jaypipes: no, because they also release in between
20:35:17 <jaypipes> dhellmann: ah.
20:35:23 <dhellmann> swift might be release:independent, release:synchronized, release:uses-stable-branches
20:35:37 <dhellmann> oslo would be release:independent, release:uses-stable-branches
20:35:38 <jaypipes> dhellmann: what would release-synchronized denote?
20:35:45 <ttx> I prefer Jay's list, tbh
20:35:49 <dhellmann> a release at the end of a cycle
20:36:03 * dhellmann shrugs
20:36:33 <dhellmann> ttx: nothing on jaypipes' list describes oslo
20:36:37 <ttx> I'll think about it and propose a new one. jaypipes, dhellmann: I might get your a draft proofread
20:37:03 <dhellmann> ttx: sure
20:37:11 <jaypipes> dhellmann: release:independent describes oslo projects, no?
20:37:19 <annegent_> I think the cognitive overload is on independent AND synnchronized :)
20:37:32 <sdague> dhellmann: the stable branches for oslo are sort of an accident of our current test system though, right?
20:37:32 <ttx> annegent_: I blame swift
20:37:32 <dhellmann> jaypipes: we produce many releases during a cycle and one stable release at the end of each, so not realy
20:37:35 <ttx> (as always)
20:37:49 <dhellmann> sdague: no, we were doing them before this cycle
20:38:02 <sdague> dhellmann: right, but we weren't testing releases before this cycle
20:38:10 <sdague> the libs were all from git
20:38:25 <dhellmann> sdague: we were using alpha tags to avoid the problem that caps are  now being used to avoid
20:38:44 <jaypipes> dhellmann: gotcha. so perhaps release:periodic-6mo + release:as-needed?
20:39:18 <dhellmann> jaypipes: that 6month thing feels forced, but that's probably closer
20:39:21 <jaypipes> dhellmann: /me trying to come up with a pithy way of denoting "releases versions of libraries as needed"
20:39:22 <ttx> #action ttx to propose a new set of tags based on an release model attribute (AND) approach, and make sure that all projects can be acurately described in it
20:40:09 <ttx> Let's move on
20:40:28 <ttx> And I thought those ones were piece of cake
20:40:33 <ttx> #topic Other governance changes
20:40:44 <ttx> * Add ironic-lib to Ironic program (https://review.openstack.org/157757)
20:41:02 <ttx> We have 7 YES here and I think we can overrule mikal's objection since it's been addressed in further comments
20:41:27 <ttx> so... approving after meeting unless someone else objects
20:41:34 <ttx> * Add dib-utils as part of TripleO (https://review.openstack.org/158365)
20:41:51 <ttx> This one looks good to go, could use another +1
20:42:15 <ttx> approving after meeting unless someone else objects
20:42:20 <ttx> * Add mission statement for project 'Heat' (https://review.openstack.org/154049)
20:42:30 <ttx> One mission is better than no mission, so this one looks good to go too
20:42:57 <ttx> It has Heat PTL blessing, so will approve after meeting unless someone else objects
20:43:06 <ttx> * Adding Piet Kruithof as Horizon ATC (https://review.openstack.org/154271)
20:43:23 <ttx> 8 YES &I think we can overrule mikal's objection here as well since it's been addressed in further comments
20:43:34 <ttx> so will approve after meeting unless someone else objects
20:43:49 <ttx> #topic Housekeeping
20:43:55 <ttx> Even more intersting
20:43:59 <ttx> * Build list of teams from YAML file (https://review.openstack.org/125788)
20:44:09 <ttx> This is rendering the teams list for governance.o.o, not really a TC decision. I'll approve this postmeeting as housekeeping, unless someone posts a valid -1
20:44:18 <ttx> * Update the Infrastructure project homepage URL (https://review.openstack.org/158371)
20:44:26 <jeblair> i'm not opposed to this, but i sort of feel weird being the odd project out; i'd like to ask fungi more about his intent when he gets back from vacation
20:44:42 <ttx> This one could use jeblair's +1, but since it's housekeeping i'll also approve it post-meeting unless there is an objection
20:44:51 <dhellmann> that sounded like an objection?
20:44:56 <ttx> oh
20:45:00 <dhellmann> or at least a request to have it tabled
20:45:14 <ttx> I thought that was an objection on the Heat mission one
20:45:17 <jeblair> yeah, can we table it?
20:45:18 <jeblair> oh sorry
20:45:24 <ttx> sure, no hurry
20:45:27 <jeblair> was suggesting tabling the infra homepage change
20:45:50 <ttx> Heh, infra actually *has* a mission
20:45:59 <ttx> jeblair: sure, no pb
20:46:12 <ttx> #info tabling this one until we get PTL ack
20:46:20 <ttx> * Improve the doc build process (openstack-specs) (https://review.openstack.org/#/c/156715/)
20:46:26 <ttx> This one is housekeeping on the openstack-specs repo, will approve unless somone objects
20:46:38 <ttx> #topic Open discussion
20:47:13 <ttx> I wanted to mention I don't get a lot of support from TC members to push the new governance model
20:47:32 <zaneb> fun fact: the verb 'to table' has opposite meanings in English and American
20:47:32 <ttx> I know we all have our battles, but I kind of hoped we'd get more tag definitions proposed
20:48:24 <dhellmann> ttx: did you have some other tags in mind?
20:48:44 <ttx> dhellmann: well, Jay had a very long list
20:48:47 <jeblair> ttx: i was also wondering what's next for the change
20:49:04 <ttx> I'll work with Ops to make progress on maturity-description tags
20:49:32 <ttx> jeblair: I think we need to continue to decontruct the various meanings of integrated-release into separate tags
20:49:37 <devananda> ttx: I'll be happy to work with you on some more tags
20:49:42 <ttx> So what does integarted-release currently mean ?
20:49:54 <ttx> It does mean released-together, and we have a thread to cover that
20:50:03 <jeblair> ttx: it looks like most of the work items in http://governance.openstack.org/resolutions/20141202-project-structure-reform-spec.html are largely complete, except for tag related things
20:50:08 <ttx> It does mean tested-together
20:50:10 <jaypipes> ttx: sorry mate, I can try to submit some tag definitions in the next week or so. Apologies, I've been so swamped with other stuff :(
20:50:22 <ttx> It does mean kind-of-mature
20:50:34 <devananda> ttx: in particular, I'm interested in tags around the layers that mordred and I have talked about previously, but I haven't tried to write them up formally yet
20:50:37 <ttx> It does mean kind-of-produced-the-openstack-way
20:50:55 <ttx> we cover "kind-of-produced-the-openstack-way" with the new project teams requirements
20:50:57 <dhellmann> ttx: "mature" is too subjective and "openstack-way" is still a rule for all projects, right?
20:51:26 <dhellmann> devananda: the layers can be discovered by looking at the test matrix, can't they? do we need tags for those?
20:51:34 <ttx> dhellmann: sure "mature" (or "stable") is too subjective
20:51:49 <ttx> dhellmann: My plan is to reach out to ops tand see how we could describe that
20:51:53 <jogo> dhellmann: yeah I don't think we need 'formal' tags for layers
20:51:56 <annegent_> is anyone at the ops meetup to test usability of tags?
20:52:00 <devananda> dhellmann: the test matrix is evolving currently. in an ideal world, yes, it could be discovered from that, though I think having tags to self-describe is helpful
20:52:03 <annegent_> next week I think?
20:52:11 <zaneb> dhellmann++
20:52:17 <dhellmann> ttx: I hope they will blog or something. I don't know if it's a good idea for us to be trying to express that here.
20:52:47 <dhellmann> devananda: ok. I'm -1 on that because I don't want to have to have this conversation every time the project-config repo is updated. :-)
20:52:48 <devananda> dhellmann: ++ on not having "mature" or "openstack-way" tags
20:52:49 <ttx> I think we need to, though. Thats' what our downstream users want us to express
20:53:15 <devananda> also -- if a project isn't following "the openstack way" it shouldn't be in openstack/* namespace. so we dont need a separate tag for that
20:53:24 <ttx> we can't on one private side say "this thing is crap" and then leave our users discover that by themselves
20:53:28 <dhellmann> ttx: I understand the need to have the information. I'm not convinced this body is the right group to produce it. Isn't that the whole issue that led to the Big Tent discussion in the first place?
20:53:31 <devananda> ttx: ++
20:53:33 <annegent_> devananda: but stackforge could be construed as "opesntack way-ish"
20:53:54 <ttx> dhellmann: I'm not saying we would apply those tags ourselves
20:54:04 <devananda> annegent_: sure. ish :)
20:54:13 <annegent_> :)
20:54:23 <ttx> dhellmann: how about tags that describe adoption, based on user committee surveys and research they conduct
20:54:35 <ttx> they would apply that tag, not us
20:54:38 <jeblair> yes, projects are in stackforge because they want to operate the openstack way.  i think in the long run that means that there should not be a stackforge, and all of them should be in the tent
20:54:54 <dhellmann> ttx: why wouldn't people just read the user surveys?
20:54:56 <jogo> ttx: I have questions about the quality of the user survey data
20:54:58 <devananda> dhellmann: we could (and IMO should) delegate the application of tags to the bodies of people (outside the TC) who represent that sort of knowledge
20:55:11 <ttx> jeblair: not all of them fill all the boxes
20:55:23 <ttx> jeblair: the only box they fill is "use Gerrit"
20:55:29 <dhellmann> devananda: we don't need to give anyone permission to go write up what they think the state of projects are
20:55:44 <jeblair> ttx: they test, use the mailing list, irc meetings, etc...
20:55:49 <devananda> dhellmann: no, but providing a single point of reference is very helpful for people ...
20:55:53 <jeblair> ttx: they are there because they want to be part of the community
20:55:57 <ttx> jeblair: they don't all use the ML, far from it
20:56:01 <dhellmann> devananda: certainly. Is that really project governance, though?
20:56:08 <jeblair> ttx: there are easier code hosting systems out there, they aren't just here for gerrit :)
20:56:14 <ttx> jeblair: same with IRC meetings
20:56:21 <dhellmann> we're spending a lot of time on taxonomy that could be spent on negotiating some of the technical issues we have
20:56:24 <devananda> dhellmann: the providing of that location? yes. the curation of the content? nope.
20:56:30 <ttx> jeblair: a LOT of them use private calls/meetings/hangouts
20:56:31 <jogo> dhellmann: ++
20:56:33 <devananda> dhellmann: indeed
20:56:41 <jeblair> ttx: right, so projects that need nothing more than git repo hosting can find it elsewhere, and the folks that want to be part of the community can be
20:56:45 <devananda> I'd love to, for example, discuss out of tree drivers
20:56:55 <devananda> and how that's working really well for some projects, while others resist it
20:57:13 <dhellmann> devananda: most of the operators I'm familiar with look to their distro for the kind of information we've been talking about, not upstream to us.
20:57:24 * jogo wonders whats going on with neutron, and how nova-network isn't deprecated yet
20:57:25 <dhellmann> devananda: ++ to discussing how to manage drivers
20:57:28 <ttx> dhellmann: I still think it's our responsibility to describe our ecosystem of projects for our downstream consumers
20:57:34 <devananda> dhellmann: and distros look where?
20:57:35 <anteaya> devananda: the only project I know of doing it so far is neutron, and others are watching
20:57:44 <devananda> anteaya: ironic
20:57:49 <dhellmann> devananda: they test and make their own decisions, no?
20:57:51 <ttx> we can't just dump pioles of code and say it's someone else problem to figure it out
20:58:00 <devananda> anteaya: though our model is somewhat different than neutron's, it seems to be working quite well for us
20:58:17 <devananda> ttx: ++
20:58:26 <anteaya> devananda: then that is another data point for me
20:58:43 <ttx> someone has to do it, and we can't escape our responsibilities
20:58:54 <ttx> Anyway... I'll be at the Ops Summit in PHL next week. Anyone else joining ?
20:58:59 <dhellmann> I would whole-heartedly support someone creating a product guide or something that had this information in it. I do not think the TC should do it ourselves. We're not the only ones who can do it, and we have other things to address for which we *are* the only group who can address them.
20:59:03 <ttx> sdague is, I know that
20:59:04 <annegent_> ttx: oh good.
20:59:26 <ttx> annegent_: you're coming ?
20:59:37 <sdague> ttx: yep, I'll be there. mordred will as well.
20:59:46 <devananda> anteaya: ironic has explicitly supported out of tree drivers, though to my knowledge only a few exist, and they're not posted in obvious places yet
21:00:08 <ttx> dhellmann: the tags are the guide. We create the framework and people fill the blanks / apply tags
21:00:12 <devananda> anteaya: but the email re stackforge/proliantutils is a great example of what our interface enables
21:00:13 <annegent_> ttx: sadly, no. Matt Kassawara will be there for docs
21:00:13 <ttx> I'll lead a session on ops-driven tags definition.
21:00:21 <annegent_> ttx: great
21:00:24 <ttx> plan to discuss novanet vs. neutron, EC2 API support, DB downgrades, default config files and other upstream/ops pain points
21:00:34 <ttx> Since a number of us will be there I'd rather skip the TC meeting next week.
21:00:39 <ttx> If something comes up and a meeting is urgently needed, I'll fish for replacement chair to run it
21:00:43 <devananda> ttx: i wish i could make it, but E_RECOVERING_FROM_TRAVEL
21:00:50 <ttx> Last words ?
21:01:01 <dhellmann> "it'll be easy"
21:01:01 <jeblair> i think we should have the meeting next week
21:01:10 <annegent_> "words are hard"
21:01:13 <devananda> dhellmann: there's a tag for that
21:01:21 <ttx> jeblair: ok, we'll discuss that on the tc list
21:01:23 <ttx> #endmeeting