20:03:22 <ttx> #startmeeting tc
20:03:23 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:03:27 <openstack> The meeting name has been set to 'tc'
20:03:32 <ttx> Our agenda for today:
20:03:39 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:03:51 <ttx> 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 <ttx> hmm, we don't seem to have haypo around
20:04:40 <ttx> I guess we can still discuss the issue, I'll play devil's advocate
20:04:45 <ttx> #topic asyncio: replace eventlet with trollius
20:04:56 <ttx> So this topic was raised by haypo at sdague's request
20:05:01 <ttx> (both of which are not present :)
20:05:14 <ttx> or is it both of whom? Damn English language
20:05:17 <annegent_> wait, who's haypo?
20:05:20 <russellb> if neither are here, doesn't seem urgent to discuss
20:05:24 <annegent_> heh
20:05:24 <ttx> that would be Victor Stinner
20:05:29 <annegent_> ok
20:05:43 <ttx> russellb: ok, let's table it until meeting end
20:05:48 <dhellmann> ++
20:05:49 <ttx> #undo
20:05:50 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x34a21d0>
20:05:57 <ttx> #topic Project structure reform
20:06:11 <ttx> * 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 <ttx> 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 <ttx> It primarily objects to using the openstack/governance repository as the home for the project tags
20:06:42 <ttx> 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 <ttx> s/but//
20:06:53 <mordred> 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 <annegent_> 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 <mordred> that isn't already information that exists either elsewhere or is purely an opinion
20:07:24 <annegent_> 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 <dhellmann> 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 <vishy> I think subjective tags have value
20:07:39 <ttx> I think reference information about projects has value
20:07:40 <annegent_> well "I" meaning, if I had time
20:07:42 <dhellmann> vishy: example?
20:07:47 <vishy> and there will most definitely be subjective tags for the board at least
20:07:50 <vishy> "core"
20:07:57 <ttx> "compute-base"
20:07:58 <mordred> 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 <dhellmann> ttx: yeah, I'm not sure it needs to be "tags" is all I'm saying
20:08:02 <ttx> "coordinated-release"
20:08:05 <dhellmann> vishy: core won't be a tag, though, right?
20:08:12 <zaneb> 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 <vishy> i believe it will be represented witha  tag
20:08:26 <mordred> core is a meaningless concept
20:08:27 <vishy> clearly it will be voted on by the board so the process is different
20:08:29 <dhellmann> "compute-base" can be discovered by looking at the dependency lists for projects
20:08:37 <zaneb> 1000 little objective tags just says that everything is important to somebody
20:08:39 <dhellmann> "coordinated-release" can be determined by looking at the release schedule
20:08:42 <ttx> 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 <zaneb> there's no useful information there
20:08:54 <mordred> ttx: useful to who?
20:09:02 <dhellmann> 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 <vishy> but aren’t we as the tc comittee responsible for providing some guidance to the community?
20:09:09 <ttx> dhellmann: we don't invent any new information with the tags, we just surface that information for our users
20:09:21 <ttx> think of it as reference metadata
20:09:29 <annegent_> I think that the current way you figure out what to run in production is quite word-of-mouth
20:09:32 <mordred> ttx: right. but we don't need to vote as the TC on reference metadata
20:09:32 <ttx> mordred: all our users ?
20:09:36 <jeblair> vishy: what kind of guidance should we provide via tags?
20:09:37 <annegent_> so a reference would be valuable
20:09:40 <vishy> as an operator I would generally like to know what the tc thinks of a given project
20:09:40 <dhellmann> 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 <ttx> mordred: that I would agree to
20:09:50 <mordred> vishy: we never have and probably never will express that opinion
20:09:55 <ttx> and I said as much to dhellmann on the thread
20:09:57 <mordred> vishy: if we WERE going to do that, I'd be with you
20:09:59 <vishy> imordred yes we have
20:10:13 <vishy> we called it “incubated” and “integrated” before
20:10:16 <annegent_> we have mordred from a historical perspective
20:10:23 <mordred> that was not our opinoin of the project
20:10:23 <dhellmann> vishy: right, but now we're explicitly doing away with those things
20:10:25 <ttx> 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 <mordred> that was our determination that a project met a process
20:10:32 <ttx> We might be actually agreeing
20:10:36 <mordred> our users, it turns out, don't care about that
20:10:38 <dhellmann> ttx: yes, that is my point
20:10:51 <russellb> integrated has been about more than process
20:10:54 <david-lyle> 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 <vishy> dhellmann: we are doing away with those specific tags
20:10:58 <russellb> we have guideless far more extensive than just process
20:11:04 <ttx> dhellmann: the proposal sayd: tags can be delegated to another group for maintenance
20:11:09 <vishy> but to say that we don’t ever need them seems a bit short sighted
20:11:13 <ttx> dhellmann: this may end up being all of them
20:11:18 <annegent_> 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 <ttx> dhellmann: I'm pretty sure it will be "most of them"
20:11:32 <dhellmann> ttx: that's fine. I still think we could "surface" this information by just writing down some product documentation somewhere.
20:11:43 <zaneb> 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 <jeblair> 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 <jaypipes> jeblair: ++
20:12:26 <ttx> 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 <mordred> 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 <jeblair> mordred: fully agreed there
20:12:57 <ttx> I don't think we should expect people to find out that reference information on their own
20:12:58 <mordred> 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 <ttx> that's what we currently do and it fails
20:13:08 <david-lyle> 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 <annegent_> ttx: +1
20:13:39 <ttx> So in summary, I totally agree that the TC shoud not be the body deciding all the tags
20:13:51 <ttx> I even agree that the TC should not decide most of the tags
20:13:57 <ttx> but I still think tags have value
20:14:05 <dhellmann> 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 <ttx> $and it's our responsibility to provide the framework to handle them
20:14:22 <vishy> I also agree that we shouldn’t be responsible for all tags
20:14:38 <vishy> objective ones can be verified independently
20:14:56 <annegent_> we can enable tags as self-service
20:14:58 <ttx> dhellmann: we tried to provide that info in the past, mostly through wiki landing pages
20:15:02 <vishy> but I’m not willing to state that we will never want some kind of subjective tagging
20:15:11 <mordred> vishy: I agree with that
20:15:12 <ttx> tags are just a way to express that project metadata
20:15:24 <vishy> and i don’t think people should just be able to throw in arbitrary tags as they see fit
20:15:25 <jeblair> 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 <mordred> 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 <vishy> they need some kind of review process
20:15:41 <mordred> vishy: but I'm very open to being wrong :)
20:15:43 <jeblair> 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 <mordred> ++
20:15:52 <vishy> mordred: I don’t have any to propose currently for sure
20:16:01 <dhellmann> 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 <annegent_> I think subjective tags are better than "so and so said this" :)
20:16:48 * mordred tags jaypipes as friendly
20:16:57 <markmcclain> ++
20:16:59 <ttx> jeblair: I think surfacing reference info has value. I agree that most of that inbfo already exists somewhere
20:17:13 <ttx> and that in most cases our group is not the best suited to update that info
20:17:24 <mikal> Oh, apparently I am here
20:17:26 <ttx> But let me take a step back
20:17:44 <annegent_> mikal: welcome
20:17:49 * sdague as well
20:17:52 <ttx> tags will also be used to answer some questions as the TC and those tags will be directly handled by us
20:18:15 <dhellmann> hmm, can you give an example?
20:18:22 <ttx> the (new) bylaws require that we provide subsets of projects that may be used in trademark license programs
20:18:34 <ttx> (a "TC approved release")
20:18:44 <ttx> the way I thought we would answer that question is through a tag
20:18:57 <ttx> think "OpenStack Storage powered product"
20:19:19 <dhellmann> do we need different sets of projects, or just a list of "put trademarks on these"?
20:19:26 <ttx> no no
20:19:58 <ttx> we need different subsets, which we allow the board to take a subset of for specific trademark programs
20:20:02 <ttx> sorry can't type faster :)
20:20:18 <ttx> 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 <mordred> and cheese
20:20:38 <dhellmann> so they want us to suggest which projects might go into which categories?
20:20:44 <russellb> right
20:20:45 <ttx> Board has new trademark program, call it "OpenStack inspired dream"
20:20:56 <ttx> we define a subset of projects that may be used to that effect
20:21:09 <ttx> and board picks from /that subset/ to establish the trademark program
20:21:18 <dhellmann> 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 <russellb> we'll be working on a process for this soon
20:21:20 <ttx> any or all of the subset we defined
20:21:34 <russellb> which might help clarify things
20:21:41 <ttx> 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 <dhellmann> 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 <ttx> I agree we could do it outside of the tag framework
20:44:38 <ttx> #topic Review openstack-specs approval rules
20:44:38 <ttx> Two weeks ago we (well, mikal) fast-approved the log guidelines cross-project spec
20:44:38 <ttx> dhellmann raised that we should have been using "normal TC voting procedures" for that repo
20:44:44 <ttx> 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 <ttx> 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 <ttx> But then I'm not sure how we can express that in Gerrit without removing everyone's ability to -1
20:45:19 <ttx> Basically, how do TC members say "NO" ? -2 is a bit of a veto, not a NO.
20:45:28 <dhellmann> jeblair was going to investigate gerrit config options, right?
20:46:06 <jeblair> dhellmann: yes, and i failed due to flying around to conferences and meetings too much :(  i am sorry.
20:46:06 <ttx> jeblair: should we table this until you get a chance to investigate that ?
20:46:07 <sdague> 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 <dhellmann> jeblair: np
20:46:40 <ttx> sdague: so you don't want classic TC approval rules
20:46:47 <sdague> because, really, if a TC member feels that strongly against it, that should stop this
20:46:49 <ttx> you want a tweaked version with veto possibility
20:46:54 <ttx> I'm fine with that
20:46:59 <dhellmann> sdague: my point was I think we want more than two +2 votes before approval
20:47:10 <ttx> it's just NOT normal voting rules, that's something else we need to define
20:47:30 <ttx> Could be at least 7 +2, no -2
20:47:31 <dhellmann> I'm less concerned with vetos, I guess.
20:47:55 <ttx> that would be easily impletable
20:48:00 <ttx> implement-able
20:48:01 <jeblair> if we can come up with requirements like "tc votes visible, tc can/can not veto" etc
20:48:02 <jeblair> that would help
20:48:23 <jeblair> we do have more options in gerrit than last time we looked at something like this
20:48:24 <ttx> dhellmann: would "at least 7 +2, no -2" work for you ?
20:48:29 <dhellmann> 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 <ttx> i.e. 7 approvals, no veto
20:48:35 <dhellmann> ttx: yeah, that sounds good
20:49:01 <dhellmann> 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 <ttx> 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 <dhellmann> yeah, I'm willing to go with that
20:49:37 <russellb> wfm, too
20:49:40 <mordred> ++
20:49:41 * dhellmann wonders if anything we do is actually "normal"
20:49:49 <sdague> yeh, I'm fine with that
20:49:57 <ttx> dhellmann: normal as in "carved in stone in the TC charter"
20:49:57 <jeblair> 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 <ttx> #agreed switch openstack-specs approval rules to  "at least 7 +2, no -2"
20:50:35 * jeblair is puzzled
20:50:45 <ttx> jeblair: we'll probably want to restrict Workflow+1 to tc-chair
20:51:24 <jeblair> i'm not sure how a tc member is expected to express dissent
20:51:35 <ttx> -1 ?
20:51:38 <sdague> jeblair: -1
20:51:52 <jeblair> and we are not concerned that is indistingushable from any other -1?
20:52:07 <jeblair> and are tc members permitted to -2?
20:52:11 <sdague> I'm not, we can read the votes
20:52:14 <ttx> well, since you need 7 YES for approval, not voting is pretty much the same as -1
20:52:16 <sdague> jeblair: yes
20:52:25 <ttx> jeblair: yes, to express veto
20:52:52 <jeblair> and we have no desire to make the tc votes visible as such?
20:53:14 <jeblair> and we _want_ the tc veto, that's not just a compromise based on current configuration?
20:53:25 <ttx> jeblair: that is how I understand it
20:53:39 <jeblair> 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 <sdague> I personally think the TC veto is important
20:53:50 <ttx> sdague said: "I kind of think -2 veto is a feature here"
20:54:02 <dhellmann> jeblair: https://review.openstack.org/150581
20:54:07 <sdague> 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 <mordred> jeblair: ++
20:54:16 <sdague> that means we failed somewhere else
20:54:25 <dhellmann> sdague: +1
20:54:39 <jeblair> sdague: i agree it means we failed, i do not agree that we should enable tc members to veto
20:54:43 <ttx> if we can't agree between us, how do we expect all PTLs to fall in line with the spec
20:54:44 <mordred> 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 <jeblair> we don't have a veto anywhere else
20:54:53 <jeblair> i don't know why we're adding it here
20:54:57 <jeblair> i would veto this suggestion if i could
20:54:58 <mordred> and I agree with jeblair that I think veto is not actually desired
20:54:58 <jeblair> but i can not
20:55:01 <mordred> jeblair: ++
20:55:03 <sdague> all the specs teams have vetos on it
20:55:06 <ttx> hah
20:55:10 <ttx> still time to
20:55:13 <ttx> #undo
20:55:14 <openstack> Removing item from minutes: <ircmeeting.items.Agreed object at 0x2d1f510>
20:55:21 <ttx> since we are not agreeing
20:55:30 <mordred> this is the TC - not a spec vote - we don't have a veto concept here
20:55:44 <dhellmann> but these *are* specs
20:55:46 <sdague> but it's a specs repo
20:55:59 <jeblair> and when things get contentious, i want us to be able to navigate a way out of it
20:56:13 <mordred> sdague: yes - but we don't approve things with any 2 +2's - we do it by majority vote
20:56:14 <sdague> yes, and running over members I don't think is that
20:56:31 <mordred> we can still have dissenting votes and often do have at least one or two
20:56:44 <sdague> mordred: that's a definition of the governance repo based on it replacing in meeting votes
20:56:47 <mordred> and I _do_ think it's important to capture and display that  TC member dissented
20:56:51 <ttx> hmm, looks like we can push this to a thread and clarify the requirements
20:57:00 <ttx> I'd like to cover one more thing in this meeting
20:57:04 <mordred> ttx: ++
20:57:13 <ttx> #action ttx to raise thread to continue discussion on openstack-specs approval
20:57:16 <mordred> just saying - there are more options available to us than we provide to other repos
20:57:27 <ttx> #topic Open discussion
20:57:31 <ttx> I'd like to start the L naming poll this week
20:57:36 <russellb> yay
20:57:37 <ttx> 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 <ttx> And we haven't received an answer yet
20:57:47 <ttx> Do you think we can wait until next week ? Or do we need the name now ?
20:57:54 <anteaya> I've emailed no response
20:58:02 <anteaya> first nations work on their own concept of time
20:58:22 <ttx> we can't wait forever, people started to complain
20:58:24 <anteaya> I don't haev much hope waiting another week will net any useful results
20:58:36 <ttx> Current set is Lizard, London, Liberty, Love
20:58:38 <anteaya> they haven't acknowledged my email
20:58:42 <ttx> 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 <jeblair> 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 <ttx> 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 <jeblair> (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 <vishy> i like all the options
20:59:26 <ttx> 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 <dhellmann> anteaya: ?
20:59:53 <anteaya> liberty is american
20:59:54 <fungi> anteaya: it only seems american. we don't _actually_ have any either
20:59:56 <mordred> I'm not thrilled with the list, nor that it's pre-culled
21:00:00 <ttx> 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 <anteaya> fungi: heh
21:00:09 <vishy> fungi: wp, wp
21:00:11 * dhellmann follows jeblair
21:00:13 <vishy> sure
21:00:17 <ttx> mordred: we plan to address that, I talked with jogo on clarifying the process
21:00:18 <vishy> i will vouch for liberty
21:00:27 <ttx> OK then
21:00:34 <ttx> And shall we wait another week ?
21:00:38 <mordred> 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 <mordred> and instead a function of our technical community
21:00:58 <mordred> that is, as it should be, fun
21:01:12 <vishy> is there any reason we can’t do a two phase poll with all options?
21:01:19 <vishy> is the issue trademark conflicts?
21:01:20 <ttx> We need to close the meeting ? Wait another week ?
21:01:24 <ttx> vishy: yes
21:01:29 <dhellmann> ttx: yeah, let's wait
21:01:33 <ttx> OK
21:01:37 <ttx> thx
21:01:41 <ttx> #endmeeting