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