20:03:22 #startmeeting tc 20:03:23 Meeting started Tue Jan 27 20:03:22 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:24 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:03:27 The meeting name has been set to 'tc' 20:03:32 Our agenda for today: 20:03:39 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:03:51 Note that I added Doug's recent thread to the agenda today, since it's very much related to the proposed changes on Project structure reform 20:04:16 hmm, we don't seem to have haypo around 20:04:40 I guess we can still discuss the issue, I'll play devil's advocate 20:04:45 #topic asyncio: replace eventlet with trollius 20:04:56 So this topic was raised by haypo at sdague's request 20:05:01 (both of which are not present :) 20:05:14 or is it both of whom? Damn English language 20:05:17 wait, who's haypo? 20:05:20 if neither are here, doesn't seem urgent to discuss 20:05:24 heh 20:05:24 that would be Victor Stinner 20:05:29 ok 20:05:43 russellb: ok, let's table it until meeting end 20:05:48 ++ 20:05:49 #undo 20:05:50 Removing item from minutes: 20:05:57 #topic Project structure reform 20:06:11 * Is the governance repository the long-term place for the project tags (http://lists.openstack.org/pipermail/openstack-dev/2015-January/055151.html) 20:06:21 dhellmann raised this thread just yesterday, but since it objects somehow to the proposed changes, I think it's worth discussing it first 20:06:30 It primarily objects to using the openstack/governance repository as the home for the project tags 20:06:42 While I still strongly support tags as a way to clearly describe code repositories, but I tend to agree that this all could live in a separate repository 20:06:50 s/but// 20:06:53 I'm with dhellmann ... try as I might, I cannot actually find a concrete example of a tag that I think provides useful information 20:07:01 I did talk to dhellmann yesterday some (in case you were wondering why I hadn't replied on a thread that directly mentioned docs) 20:07:19 that isn't already information that exists either elsewhere or is purely an opinion 20:07:24 I would love to do the data mining on current docs to see if that would be meaningful to devs/ops/users. 20:07:24 I have no strong opinion on whether tags are useful. I guess I'm +0 on having them? But none of the semi-useful ones I have seen so far are things that need us to vote on as a governing body. 20:07:26 I think subjective tags have value 20:07:39 I think reference information about projects has value 20:07:40 well "I" meaning, if I had time 20:07:42 vishy: example? 20:07:47 and there will most definitely be subjective tags for the board at least 20:07:50 "core" 20:07:57 "compute-base" 20:07:58 vishy: I think subjective tags have value in general, but I can't come up with a concrete example of a tag that has value 20:07:58 ttx: yeah, I'm not sure it needs to be "tags" is all I'm saying 20:08:02 "coordinated-release" 20:08:05 vishy: core won't be a tag, though, right? 20:08:12 I want tags to help project teams know what is important for them to work on (and to whom it is important) 20:08:14 i believe it will be represented witha tag 20:08:26 core is a meaningless concept 20:08:27 clearly it will be voted on by the board so the process is different 20:08:29 "compute-base" can be discovered by looking at the dependency lists for projects 20:08:37 1000 little objective tags just says that everything is important to somebody 20:08:39 "coordinated-release" can be determined by looking at the release schedule 20:08:42 mordred: if none are useful, then we won't add any. But I already know of 4 that I want to have and are useful 20:08:46 there's no useful information there 20:08:54 ttx: useful to who? 20:09:02 neither of those examples requires the governing body of the openstack developer community to approve them if we're giving projects the ability to define their own dependencies and release schedules 20:09:06 but aren’t we as the tc comittee responsible for providing some guidance to the community? 20:09:09 dhellmann: we don't invent any new information with the tags, we just surface that information for our users 20:09:21 think of it as reference metadata 20:09:29 I think that the current way you figure out what to run in production is quite word-of-mouth 20:09:32 ttx: right. but we don't need to vote as the TC on reference metadata 20:09:32 mordred: all our users ? 20:09:36 vishy: what kind of guidance should we provide via tags? 20:09:37 so a reference would be valuable 20:09:40 as an operator I would generally like to know what the tc thinks of a given project 20:09:40 ttx: it's fine to have them, but I don't think we need to vote on them as a governing body 20:09:43 mordred: that I would agree to 20:09:50 vishy: we never have and probably never will express that opinion 20:09:55 and I said as much to dhellmann on the thread 20:09:57 vishy: if we WERE going to do that, I'd be with you 20:09:59 imordred yes we have 20:10:13 we called it “incubated” and “integrated” before 20:10:16 we have mordred from a historical perspective 20:10:23 that was not our opinoin of the project 20:10:23 vishy: right, but now we're explicitly doing away with those things 20:10:25 mordred: I'm not sure we'll come up with a tag that needs to be solely decided by the TC, if that's your point 20:10:29 that was our determination that a project met a process 20:10:32 We might be actually agreeing 20:10:36 our users, it turns out, don't care about that 20:10:38 ttx: yes, that is my point 20:10:51 integrated has been about more than process 20:10:54 you are walking to toward a very tangled web, when there are no qualifications around which pieces work with which, which is what happens if you leave it up to individual projects 20:10:56 dhellmann: we are doing away with those specific tags 20:10:58 we have guideless far more extensive than just process 20:11:04 dhellmann: the proposal sayd: tags can be delegated to another group for maintenance 20:11:09 but to say that we don’t ever need them seems a bit short sighted 20:11:13 dhellmann: this may end up being all of them 20:11:18 now we want tags or some sort of indicator to enable more tight integration and specific use cases rather than "run the world" 20:11:23 dhellmann: I'm pretty sure it will be "most of them" 20:11:32 ttx: that's fine. I still think we could "surface" this information by just writing down some product documentation somewhere. 20:11:43 dhellmann: the problem with before was that we couldn't communicate different things to different audiences. The fact that we were communicating was not bad in itself 20:11:50 mordred: to be fair, i believe that in the past we have considered desirability of including a project in openstack when incubating or integrating it. but i believe that many of us think that is no longer a good idea 20:12:19 jeblair: ++ 20:12:26 dhellmann: I think there is value in presenting that reference information in some project browsing website. Have it live in some YAML file somewhere helps that website to exist 20:12:29 jeblair: sure. but the one that has been explicitly requested "is this ready for me to run" is one that we actually don't know the answer to until people decide to run it 20:12:37 mordred: fully agreed there 20:12:57 I don't think we should expect people to find out that reference information on their own 20:12:58 that's the only one that I think isn't just procedural or a collection of already existing data from the docs 20:13:03 that's what we currently do and it fails 20:13:08 for projects that build on other projects, heat, horizon, tripleO and ever expanding eco-system means limitations on how much how quickly we can support 20:13:23 ttx: +1 20:13:39 So in summary, I totally agree that the TC shoud not be the body deciding all the tags 20:13:51 I even agree that the TC should not decide most of the tags 20:13:57 but I still think tags have value 20:14:05 if tags had not come up in the context of the big tent discussion, would we have started doing that ourselves? or would we have, for example, asked the new product management group to help us with product documentation? 20:14:16 $and it's our responsibility to provide the framework to handle them 20:14:22 I also agree that we shouldn’t be responsible for all tags 20:14:38 objective ones can be verified independently 20:14:56 we can enable tags as self-service 20:14:58 dhellmann: we tried to provide that info in the past, mostly through wiki landing pages 20:15:02 but I’m not willing to state that we will never want some kind of subjective tagging 20:15:11 vishy: I agree with that 20:15:12 tags are just a way to express that project metadata 20:15:24 and i don’t think people should just be able to throw in arbitrary tags as they see fit 20:15:25 ttx: i'm willing to give them a shot and not disrupt the process we are on, but i also think dhellmann makes a good point that they may simply prove to be unecessary. 20:15:28 vishy: I think I'm just trying to say that I, so far, haven't heard any tag suggestions that I personally think have any value 20:15:29 they need some kind of review process 20:15:41 vishy: but I'm very open to being wrong :) 20:15:43 i'm certainly no longer willing to say tags are the answer to every question that comes up wrt the big tent :) 20:15:48 ++ 20:15:52 mordred: I don’t have any to propose currently for sure 20:16:01 vishy: if we have facts that we want to declare about projects, why does *this group* need to vote on whether they are true? 20:16:07 * jaypipes not a fan of subjective tags, but recognize that some audiences seem to want them 20:16:07 * mordred agrees 100% with vishy then 20:16:45 I think subjective tags are better than "so and so said this" :) 20:16:48 * mordred tags jaypipes as friendly 20:16:57 ++ 20:16:59 jeblair: I think surfacing reference info has value. I agree that most of that inbfo already exists somewhere 20:17:13 and that in most cases our group is not the best suited to update that info 20:17:24 Oh, apparently I am here 20:17:26 But let me take a step back 20:17:44 mikal: welcome 20:17:49 * sdague as well 20:17:52 tags will also be used to answer some questions as the TC and those tags will be directly handled by us 20:18:15 hmm, can you give an example? 20:18:22 the (new) bylaws require that we provide subsets of projects that may be used in trademark license programs 20:18:34 (a "TC approved release") 20:18:44 the way I thought we would answer that question is through a tag 20:18:57 think "OpenStack Storage powered product" 20:19:19 do we need different sets of projects, or just a list of "put trademarks on these"? 20:19:26 no no 20:19:58 we need different subsets, which we allow the board to take a subset of for specific trademark programs 20:20:02 sorry can't type faster :) 20:20:18 so superset is "all OpenSTack projects" 20:20:22 * dhellmann imagines ttx juggling a glass of wine, a pastry, and a keyboard 20:20:36 and cheese 20:20:38 so they want us to suggest which projects might go into which categories? 20:20:44 right 20:20:45 Board has new trademark program, call it "OpenStack inspired dream" 20:20:56 we define a subset of projects that may be used to that effect 20:21:09 and board picks from /that subset/ to establish the trademark program 20:21:18 it seems like it ought to be enough to say "this one should be a candidate for trademarks" and let the board decide which go in which programs 20:21:19 we'll be working on a process for this soon 20:21:20 any or all of the subset we defined 20:21:34 which might help clarify things 20:21:41 so I was planning to use TC-controlled tag for that, that would be an example of one tag direclty handled by tc 20:21:47 if a project ever fit into more than one category, would we ever say "use the trademark in category A but not B"? 20:21:53 I agree we could do it outside of the tag framework 20:44:38 #topic Review openstack-specs approval rules 20:44:38 Two weeks ago we (well, mikal) fast-approved the log guidelines cross-project spec 20:44:38 dhellmann raised that we should have been using "normal TC voting procedures" for that repo 20:44:44 The original decision on this repo was that any TC member has R+2/W+1 on that repository and could basically tally the votes and rubberstamp consensus 20:44:55 I'm fine with switching this to normal voting rules (7 YES, or at least 5 YES and more YES than NO) 20:45:04 But then I'm not sure how we can express that in Gerrit without removing everyone's ability to -1 20:45:19 Basically, how do TC members say "NO" ? -2 is a bit of a veto, not a NO. 20:45:28 jeblair was going to investigate gerrit config options, right? 20:46:06 dhellmann: yes, and i failed due to flying around to conferences and meetings too much :( i am sorry. 20:46:06 jeblair: should we table this until you get a chance to investigate that ? 20:46:07 so, honestly, I'm not sure why normal rules are bad. I can get behind stripping +A back to ttx if that's what we want, but I kind of think -2 veto is a feature here 20:46:23 jeblair: np 20:46:40 sdague: so you don't want classic TC approval rules 20:46:47 because, really, if a TC member feels that strongly against it, that should stop this 20:46:49 you want a tweaked version with veto possibility 20:46:54 I'm fine with that 20:46:59 sdague: my point was I think we want more than two +2 votes before approval 20:47:10 it's just NOT normal voting rules, that's something else we need to define 20:47:30 Could be at least 7 +2, no -2 20:47:31 I'm less concerned with vetos, I guess. 20:47:55 that would be easily impletable 20:48:00 implement-able 20:48:01 if we can come up with requirements like "tc votes visible, tc can/can not veto" etc 20:48:02 that would help 20:48:23 we do have more options in gerrit than last time we looked at something like this 20:48:24 dhellmann: would "at least 7 +2, no -2" work for you ? 20:48:29 jeblair: it sounds like we're circling around the rules we have now, but requiring more +2 before the workflow+1 is enabled 20:48:35 i.e. 7 approvals, no veto 20:48:35 ttx: yeah, that sounds good 20:49:01 I thought that's what we were operating with, just doing it by consensus rather than having the tool configured that way 20:49:21 the difference with "normal voting rules" is that a single -2 can block it, but then like sdague said, it's probably a goiod thing here 20:49:31 yeah, I'm willing to go with that 20:49:37 wfm, too 20:49:40 ++ 20:49:41 * dhellmann wonders if anything we do is actually "normal" 20:49:49 yeh, I'm fine with that 20:49:57 dhellmann: normal as in "carved in stone in the TC charter" 20:49:57 i'm pretty sure we can do that either way (veto or not veto), so decide based on what we want, not what our current rules are set up for 20:50:18 #agreed switch openstack-specs approval rules to "at least 7 +2, no -2" 20:50:35 * jeblair is puzzled 20:50:45 jeblair: we'll probably want to restrict Workflow+1 to tc-chair 20:51:24 i'm not sure how a tc member is expected to express dissent 20:51:35 -1 ? 20:51:38 jeblair: -1 20:51:52 and we are not concerned that is indistingushable from any other -1? 20:52:07 and are tc members permitted to -2? 20:52:11 I'm not, we can read the votes 20:52:14 well, since you need 7 YES for approval, not voting is pretty much the same as -1 20:52:16 jeblair: yes 20:52:25 jeblair: yes, to express veto 20:52:52 and we have no desire to make the tc votes visible as such? 20:53:14 and we _want_ the tc veto, that's not just a compromise based on current configuration? 20:53:25 jeblair: that is how I understand it 20:53:39 because i'm pretty sure we can set it up so that tc votes are distinguished from other votes and would not act as a veto 20:53:47 I personally think the TC veto is important 20:53:50 sdague said: "I kind of think -2 veto is a feature here" 20:54:02 jeblair: https://review.openstack.org/150581 20:54:07 I don't think that approving a spec over the strong objection of a TC member is a thing we want to do 20:54:12 jeblair: ++ 20:54:16 that means we failed somewhere else 20:54:25 sdague: +1 20:54:39 sdague: i agree it means we failed, i do not agree that we should enable tc members to veto 20:54:43 if we can't agree between us, how do we expect all PTLs to fall in line with the spec 20:54:44 yah - but we can make the category have -3 as a low bounds, still let TC members vote -2 to have it not be binding 20:54:48 we don't have a veto anywhere else 20:54:53 i don't know why we're adding it here 20:54:57 i would veto this suggestion if i could 20:54:58 and I agree with jeblair that I think veto is not actually desired 20:54:58 but i can not 20:55:01 jeblair: ++ 20:55:03 all the specs teams have vetos on it 20:55:06 hah 20:55:10 still time to 20:55:13 #undo 20:55:14 Removing item from minutes: 20:55:21 since we are not agreeing 20:55:30 this is the TC - not a spec vote - we don't have a veto concept here 20:55:44 but these *are* specs 20:55:46 but it's a specs repo 20:55:59 and when things get contentious, i want us to be able to navigate a way out of it 20:56:13 sdague: yes - but we don't approve things with any 2 +2's - we do it by majority vote 20:56:14 yes, and running over members I don't think is that 20:56:31 we can still have dissenting votes and often do have at least one or two 20:56:44 mordred: that's a definition of the governance repo based on it replacing in meeting votes 20:56:47 and I _do_ think it's important to capture and display that TC member dissented 20:56:51 hmm, looks like we can push this to a thread and clarify the requirements 20:57:00 I'd like to cover one more thing in this meeting 20:57:04 ttx: ++ 20:57:13 #action ttx to raise thread to continue discussion on openstack-specs approval 20:57:16 just saying - there are more options available to us than we provide to other repos 20:57:27 #topic Open discussion 20:57:31 I'd like to start the L naming poll this week 20:57:36 yay 20:57:37 We've been trying with Anita to add first nation names (lilwat or lilooet) to the mix, but for that we need explicit permission from the tribe 20:57:42 And we haven't received an answer yet 20:57:47 Do you think we can wait until next week ? Or do we need the name now ? 20:57:54 I've emailed no response 20:58:02 first nations work on their own concept of time 20:58:22 we can't wait forever, people started to complain 20:58:24 I don't haev much hope waiting another week will net any useful results 20:58:36 Current set is Lizard, London, Liberty, Love 20:58:38 they haven't acknowledged my email 20:58:42 I'd like to quickcheck that we have at least one TC member supporting every of those names, since the final short list is supposedly our pick 20:58:53 if the cross-project specs is a function of the tc, it should operate in the same way as the rest of the tc, otherwise i think it loses legitimacy 20:58:56 no need to put in the poll a name nobody would rather not have. I know London and Lizard have supporters, what about Love and Liberty ? I know some people hate those. 20:59:00 (sorry, i typed most of that before the topic change) 20:59:01 * dhellmann plans to vote London just to be confusing 20:59:07 * ttx supports Lizard 20:59:25 i like all the options 20:59:26 anyone up to support Love or Liberty 20:59:28 * russellb supports Love 20:59:29 * anteaya hates Liberty as it is american not canadian 20:59:45 anteaya: ? 20:59:53 liberty is american 20:59:54 anteaya: it only seems american. we don't _actually_ have any either 20:59:56 I'm not thrilled with the list, nor that it's pre-culled 21:00:00 vishy: do you like all the options enough to vouch for Liberty ? 21:00:01 * jeblair plans on calling it lemming anyway 21:00:02 fungi: heh 21:00:09 fungi: wp, wp 21:00:11 * dhellmann follows jeblair 21:00:13 sure 21:00:17 mordred: we plan to address that, I talked with jogo on clarifying the process 21:00:18 i will vouch for liberty 21:00:27 OK then 21:00:34 And shall we wait another week ? 21:00:38 ttx: I would like to not clarify the process as much as I would like this to not be a marketing exercise 21:00:50 and instead a function of our technical community 21:00:58 that is, as it should be, fun 21:01:12 is there any reason we can’t do a two phase poll with all options? 21:01:19 is the issue trademark conflicts? 21:01:20 We need to close the meeting ? Wait another week ? 21:01:24 vishy: yes 21:01:29 ttx: yeah, let's wait 21:01:33 OK 21:01:37 thx 21:01:41 #endmeeting