20:01:17 <ttx> #startmeeting tc
20:01:17 <openstack> Meeting started Tue Apr  4 20:01:17 2017 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:21 <openstack> The meeting name has been set to 'tc'
20:01:26 <ttx> Hi everyone!
20:01:30 <cdent> o/
20:01:30 <ttx> Thanks EmilienM for chairing last week
20:01:32 <flaper87> hello
20:01:45 <ttx> Although my plan to skip the meetign failed completely
20:01:47 * Rockyg is snuffling and sneezing as far away from everyone else as possible
20:01:59 * ttx blames DST
20:01:59 <EmilienM> ttx: my pleasure. I can do it anytime again
20:02:04 <ttx> Our agenda for today is at:
20:02:07 * flaper87 blames ttx
20:02:07 <mordred> o/
20:02:08 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:02:16 <ttx> #topic Renew & add Zanata dev members as extra ATC
20:02:22 <ttx> #link https://review.openstack.org/451625
20:02:28 <ttx> I had trouble matching some of those to active Foundation memberships
20:02:55 <ttx> Is it OK if I approve this as soon as I get the confirmation of active membership ?
20:03:03 <mordred> ++
20:03:05 <dims> +1 ttx
20:03:05 <ttx> Will be tight to include them to the TC election
20:03:06 <dtroyer> +1
20:03:13 <flaper87> ++
20:03:17 <mtreinish> ttx: ++, I'm fine with it once you sort that out
20:03:24 <fungi> yeah, i think we've generally fast-tracked extra-atcs changes as long as the ptl votes in favor
20:03:27 <johnthetubaguy> +1
20:03:29 <EmilienM> +1
20:03:30 <ttx> #agreed OK to approve once we clear out the question of active Foundation membership
20:03:48 <ttx> #topic Clarify project addition process
20:03:55 <ttx> #link https://review.openstack.org/452073
20:04:02 <ttx> The idea here is to make the process slightly more discoverable
20:04:12 <ttx> and encourage projects to engage early on with the Technical Committee on the question of scope match
20:04:19 <ttx> I did fix the comments that were posted
20:04:35 <ttx> Looks like we have quorum
20:04:35 <fungi> i like the word "adequation"
20:04:51 <ttx> It's a pretty common French word, but I checked that it existed in English before using it :)
20:04:56 <thingee> o/
20:05:10 <ttx> Alright, approved, thanks!
20:05:28 <ttx> #topic Propose the addition of an assert:maintenance-mode
20:05:32 <ttx> amrith: around ?
20:05:35 <amrith> yup
20:05:37 <ttx> #link https://review.openstack.org/449925
20:05:38 <amrith> hello
20:05:55 * ttx reads recent comments
20:06:20 <amrith> sorry, I was multitasking, let me shut down other tasks
20:06:32 <dhellmann> I made the same assumption dtroyer did about the purpose of this tag as an indication that a project is not necessarily healthy
20:06:38 <ttx> mtreinish: to answer your question, I think it's OK for a project with an otherwise-active team to declare a specific deliverable in maintenance-only mode
20:06:59 <amrith> dhellmann, that isn't the only situation where this would happen
20:07:20 <amrith> and I expect that there are times, and I certainly see this with trove moving forward where a specific deliverable may become maintenance mode
20:07:21 <mtreinish> ttx: sure, but I think maintenance mode means something different to me then the core team is AWOL
20:07:28 <dtroyer> I think the distinction between 'entire project' and 'deliverable' is important here
20:07:34 <mtreinish> which is what the tag is written as
20:07:37 <amrith> one of the things I want to do with trove is to split the deliverables to make the project more modular
20:07:37 <dhellmann> well, we have lots of deliverables that don't see many changes but that are actively maintained. I'm not sure we would want to apply this to them except as an indication of a possible problem.
20:07:55 <amrith> currently we have all databases in a single deliverable, trove
20:07:59 <flaper87> dtroyer: 'entire project' is the team
20:08:06 <amrith> I'd like to split that and make it per deliverable database
20:08:10 <ttx> dhellmann: you mean, there is no value in describing a project that is in maintenance-mode ?
20:08:24 <johnthetubaguy> dtroyer: this does feel a bit per deliverable
20:08:27 <dtroyer> flaper87: it is also the set of all fo the deliverables, which is not people
20:08:33 <dims> should be able to do either at the project or deliverable level
20:08:37 <dhellmann> ttx: the only reason I could see to declare that is if we think that state is either good or bad. Otherwise, it's just normal, right?
20:08:43 <amrith> dhellmann, ttx, I have removed the project wide maintenance mode notion
20:08:48 <ttx> It feels like communicating to users that a project will not grow new features at the moment, is a useful thing to communicate
20:08:54 <thingee> dims: ++
20:08:54 <ttx> amrith: good
20:09:05 <dims> this is a signal to outside world to set expectations
20:09:17 <flaper87> dtroyer: I meant to say that project team covers that, people and set of deliverables.
20:09:19 <dtroyer> amrith: ++  although there may be a shred or two of that still present
20:09:25 <flaper87> ttx: ++
20:09:34 <ttx> dims: I'd rather keep tags applied at team OR deliverable level, not AND
20:09:35 <dhellmann> ok, I guess I can see that. The oslo libraries we have that might otherwise fit this description aren't being prevented from having new features, they're just sort of done.
20:09:36 <amrith> the ONLY thing that can have maintenance mode is a deliverable. now, if you set all deliverables to maintenance mode, you are signaling something is not good with the project.
20:09:39 <mriedem> if i applied this to the sqlalchemy-migrate library, can i stop getting a bunch of random useless pep8 and typo fix patches?
20:09:40 <sdague> so, while it was removed, just for the record I'd be fine with project wide maintenance mode tag
20:09:49 <dims> ttx : yep, OR is good
20:09:54 <sdague> mriedem: I thought we -2ed most of those :)
20:09:54 <amrith> sdague, YES
20:10:06 <mtreinish> mriedem: heh, isn't that maintenance?
20:10:08 <amrith> I am hoping that with this, I can get some of that.
20:10:21 <dhellmann> mriedem : we should definitely apply this tag to sqlalchemy-migrate
20:10:22 <ttx> mtreinish: yes
20:10:26 <sdague> dhellmann: ++
20:10:31 <dims> ++ mriedem
20:10:36 * amrith steps back and lets the tc deliberate :)
20:10:43 <mriedem> you know the patches will continue to come,
20:10:46 <ttx> The idea of the tag is to communicate the effect to the user
20:10:48 <mriedem> because no one will read the tag first
20:10:49 <flaper87> I think this tag makes sense, FWIW. I like what it communicates and how it communicates it
20:10:55 <ttx> not to make a statement on the team state
20:11:04 <dims> mriedem : we are not going to stop people from posting patches
20:11:07 <amrith> flaper87, ++ I agree, a well written proposal
20:11:14 <amrith> :)
20:11:16 <thingee> ttx: seems like a side effect
20:11:19 <flaper87> amrith: rofl
20:11:21 <ttx> *if* a team is so abandoned that it can't do basic maintenance, then yes it should die
20:11:29 <dhellmann> amrith, ttx: the use of the term "transient period of low activity" makes me think you believe this would be a temporary situation for a deliverable
20:11:34 <fungi> we've sort of got the same situation with a number of infra deliverables, where we really don't want to add new features/complexity to them but contributors seem to take that message as a hostile rejection of their right to innovate
20:11:37 <thingee> for some teams that don't have much deliverables
20:11:59 <ttx> dhellmann: I think the idea there was to say that it's something you could recovber from. I agree it's slightly unlikely though
20:12:02 <amrith> dhellmann, yes. transient is the operative word
20:12:05 <flaper87> dhellmann: that's how I read it, yep.
20:12:07 <sdague> dims: well, we could always have maintenance bot which replies "this project is in maintenance mode, most patches won't be accepted." just so that there is some feedback to contributors that don't realize
20:12:09 <dims> ttx : +1 to basic maint else die
20:12:18 <dims> sdague : true
20:12:22 <dhellmann> amrith, ttx: I'm reading your responses to my question as not being aligned.
20:12:24 * ttx reads latest patchset
20:12:27 <amrith> dims, ++
20:12:29 <dhellmann> well, I guess you are.
20:12:39 <amrith> dhellmann, let's look at them specifically
20:12:41 <amrith> I think we are
20:12:42 <dhellmann> it seems like we're talking about 2 slightly different things
20:12:48 <ttx> dhellmann: I'm fine withthe wording, but could support its removal :)
20:12:49 <amrith> but if I'm conveying the idea that I'm not, let's clarify
20:12:53 <dhellmann> either the team is moribund or the deliverable is "done"
20:13:06 <dhellmann> having a "done" deliverable, as unlikely as that seems, is a good thing
20:13:11 <dhellmann> having a moribund team is less good
20:13:12 <mtreinish> dhellmann: that's the distinction I was tring to get at before
20:13:27 <amrith> dhellmann, there are two use cases; yes.
20:13:27 <ttx> dhellmann: is there value in discerning between the two cases, from a user perspective ?
20:13:28 <mtreinish> and the way the proposal is written is more for the former
20:13:39 <ttx> mtreinish: the intent was to keep it positive
20:13:47 <dhellmann> so if we're going to say "this project is not receiving new features" then let's focus on that, rather than all of the "not guaranteeing to be responsive with feature reviews" phrasing
20:13:50 <amrith> in the short term, I would like to mark all trove deliverables to be maintenance mode; that use-case is the indication that the project is in a 'not good' state.
20:13:50 <jroll> we've talked about bugfix/stability cycles, too, that seems like it could apply here (but not sure it would be a useful way to communicate that)
20:13:56 <sdague> personally, it feels like maintenance mode is very in line with graceful step down. It is signaling honestly that some bit of things has wound down. That can be data for people that care to step up, or for people that deploy things that are concerned about features to consider what they are going to do next.
20:13:56 <amrith> but I believe that this is transient
20:13:57 <flaper87> ttx: I think there is. If the team is moribund then all its deliverables might be affected
20:14:04 <amrith> there are things I'm working on to get us to a better state.
20:14:16 <amrith> but once we remove the tag on all deliverables, I would like to split the project
20:14:18 <dhellmann> sdague : that's what I thought, but I don't think that's what amrith and ttx actually mean
20:14:36 <amrith> into multiple deliverables, like trove-mysql, trove-mariadb, trove-mongodb, ... and so on
20:14:43 <sdague> dhellmann: ok, I could be misreading and putting a lot of my expectations in there
20:14:46 <amrith> if that happens, different 'drivers' could be in different states of done'ness
20:14:56 <dhellmann> sdague : my expectations aligned with yours, which is why I'm trying to clarify
20:14:59 <sdague> amrith: I get, in the trove case would it make more sense to just deprecate a bunch of those dbs
20:15:10 <sdague> s/I get/I guess/
20:15:17 <amrith> sdague, i don't think so
20:15:19 <amrith> consider this
20:15:25 <amrith> in mysql there are two kinds of replication
20:15:30 <amrith> binlog and guid
20:15:32 <ttx> I guess the question is whether we want to conflate things that are maintenance-only because they are done, with things that are maintenance-only because their team is in low-activity mode
20:15:45 <ttx> The tag conflates the two cases
20:15:47 <dhellmann> ttx: I don't think we do
20:15:48 <amrith> if I went to the place I want to, I'd have trove-mysql-binlog-replication as a deliverable (not the best name)
20:15:48 <dhellmann> yes
20:15:55 <dhellmann> I think "low activity team" is another tag
20:15:58 <dtroyer> ttx: do we need status:done or status:mostly-done?
20:16:00 <flaper87> ttx: team status should be specified at a team level, I think
20:16:02 <amrith> and I could mark that in maintenance while -guid would remain active
20:16:08 <amrith> sdague ^^
20:16:09 <dhellmann> I'm not sure what the trove case is, but I think it's "low activity team"
20:16:21 <dhellmann> flaper87 : ++
20:16:37 <amrith> dhellmann, yes. now it is, to paraphrase someone, a 'low energy team'
20:16:40 <ttx> flaper87: why ? Corner case a moribund team would place most of its deliverable in maintenance mode to focus on one
20:16:50 <dims> dhellmann : they way i saw it, if it was set a deliverable level then that thing is in maintenance, if applied at project level then team is going away
20:17:08 <amrith> hopefully soon, the project would go to a different place where the current unwieldy deliverable is replaced my many deliverables
20:17:19 <amrith> and individual deliverables could be pushed to maintenance mode
20:17:20 <dhellmann> amrith : I don't know how valuable it is to say that driver X is only being maintained and not seeing new features. I do see it as valuable for a whole project, or for a team.
20:17:28 <fungi> or at best the team is in stasis with a hope of eventual recovery
20:17:41 <amrith> dhellmann, the latter (whole project or team) is the current use case
20:17:45 <amrith> so let's focus on that one for now
20:17:53 <Rockyg> rather than status done, how about complete?  it has all the features that it's going to have. Any changes are bugfixes now.
20:17:54 <dhellmann> dims : yeah, we want to describe those cases separately, though, and it's easier to think of tags as having one scope or another
20:17:58 <flaper87> it's not the same. As unlike as it may sound a team that used to have drivers might merge everything into a single repo and mark the drivers as maintenance mode
20:17:59 <ttx> fwiw I'm not attached to the current (conflating) version, just trying to explain why it ended up in that place, since I reviewed an early draft and influenced it :)
20:17:59 <cdent> I think the ambiguity between a project being done and a project (or deliverable) being unattended  is bad here. Because "being done" should be considered not just a good thing, but a goal.
20:17:59 <amrith> it is the stated intent to mark all of trove's deliverables as maintenance mode right now
20:18:04 <johnthetubaguy> is "no-new-features-now" the flag we want here? there do seem to be lots of overlapping things here.
20:18:13 <dims> don't want too many tags either...
20:18:13 <flaper87> probably not the best example (ttx see my prev message)
20:18:17 <dhellmann> cdent : ++
20:18:21 <johnthetubaguy> cdent: I am leaning in your direction here
20:18:47 <amrith> OK, all, could we assert that for the purposes of this tag, we only discuss the 'team is low energy for now' use case
20:18:54 <amrith> and ignore the per-deliverable maintenance mode?
20:18:56 <dhellmann> amrith, ttx: I feel like the case we have right now is not well covered by this tag because of the conflation. Do you want to modify the definition to focus on the team aspect?
20:18:59 <jroll> cdent: agree. I can't decide if "maintenance mode" here means "slow" or "unattended". the latter implies a lack of maintenance.
20:19:02 <ttx> OK, so it sounds like we should rewrite this in a way that makes it more of a team tag, like team:low-activity
20:19:04 <cdent> amrith: in that case maintenance is the wrong word
20:19:13 <cdent> ttx++
20:19:18 <dhellmann> amrith : make a team:low-activity tag
20:19:19 <dtroyer> amrith: I think we should look at those as separate things (team vs deliverable)
20:19:19 <ttx> basically describe minimal activity levels before removal
20:19:24 <dhellmann> right
20:19:27 <dims> designate would qualify as well
20:19:29 <amrith> cdent, I'm happy to pick another word. and make a team flag
20:19:40 <amrith> happy to leave name choice out for now
20:19:45 <ttx> amrith: sounds like that's where the majority lies
20:19:48 <amrith> and focus on the theme cdent dhellmann
20:19:55 <amrith> the proposal is to come up with
20:19:57 <EmilienM> ttx: would this tag considered an official step before retiring a project?
20:19:58 <amrith> (a) a team tag
20:20:03 <ttx> EmilienM: no
20:20:05 <amrith> (b) indicates that the team is in a low energy mode
20:20:11 <amrith> (c) is expected to be transient
20:20:24 <amrith> EmilienM, or reviving the project
20:20:26 <dims> why (c)?
20:20:26 <jroll> amrith: s/expected/hoped/? :)
20:20:31 <mriedem> ttx: why not?
20:20:32 <ttx> EmilienM: I think it's good to say that the minimal activity requires releases, security bugs watch etc
20:20:35 <amrith> dims, the idea is that this is transient
20:20:37 * flaper87 things there's room for both a team level and a deliverable level tag
20:20:38 <dhellmann> amrith : and then this would be a tag a team asserts about itself or the TC attaches to a team if the team fails to participate over the course of a cycle (I don't know where the minimum bar would be, but 0 releases should be in there somewhere)
20:20:47 <EmilienM> ttx: I agree with that statement
20:20:52 <ttx> EmilienM, mriedem: some projects will just go directly to sub-minimal
20:20:52 <dims> (c) will imply someone will have to curate the tag periodically
20:20:58 <amrith> dhellmann, Yes
20:21:05 <dhellmann> amrith : I wouldn't focus on the transient aspect. We're all just dust in the wind, after all.
20:21:07 <Rockyg> ++ flaper87
20:21:08 <ttx> Like if a project doesn't do releases at all, it should not get the tag
20:21:17 <dims> dhellmann : ++
20:21:20 <mriedem> if activity is low enough that you can't even land the security fixes through the gate, then it's time to retire...
20:21:30 <amrith> dhellmann, ok. with that, the proposal would be (a) and (b) stated above
20:21:33 <dims> ttx : ++
20:21:37 <flaper87> ttx: mriedem EmilienM and there's also the project team and deliverable distinction, which is important
20:21:38 <amrith> with the prerequisites as stated in the proposal
20:21:44 <dhellmann> ttx: if they do no releases they should *not* get the tag?
20:21:56 <amrith> dhellmann, they WILL do releases
20:21:56 <dims> should get the low tag :)
20:22:00 <amrith> that is a stated expectation
20:22:00 <jroll> ttx: +1
20:22:08 <fungi> seems like there's a bit of subjective fuzzyness regardless. i expect most teams have more work to do than they can reasonably expect to get through and leave some on the floor
20:22:16 <ttx> dhellmann: the tag basically describes the minimal activity level
20:22:22 <amrith> dhellmann, see line 65
20:22:36 <dhellmann> ttx: so in that case all teams will have it, because they're doing the minimal amount of work?
20:22:40 <Rockyg> separate the deliverable tag from this proposal.  Keep this just team
20:22:40 <ttx> minimal acceptable activity level includes doing releases
20:22:42 <dhellmann> or at least the minimum
20:23:01 <ttx> dhellmann: it also describves a list of things that those teams will not commit to do
20:23:07 <johnthetubaguy> but if there are no patches? we still need the release to bump requirements?
20:23:09 <dhellmann> I think we want this to work like the single-vendor flag. If you fall below a threshold, you get the tag.
20:23:15 <fungi> yeah, no point in fixing security vulnerabilities if you don't make releases to include/distribute them
20:23:19 <jroll> dhellmann: there's three levels, AIUI: 1) active, no tag; 2) low activity, does bare minimum, yes tag; 3) no activity, no tag, pls retire
20:23:26 <dtroyer> dhellmann: that's how I read it
20:23:31 <ttx> dhellmann: right. It describes that threashold, but also the threshold under which you should not fall
20:23:42 <ttx> lest you shalt be removed
20:23:48 <dhellmann> jroll : if a team is so low activity to not even apply for the tag or do a release, I think we would just retire it, no?
20:23:53 <amrith> maybe one thing to do is to have a couple of passes at defining a metric which we can assess programmatically like the single vendor tag. I'll take the action item to do that if y'all would like
20:24:06 <dhellmann> ttx: ok, the threshold to stay official should be documented separately
20:24:10 <jroll> dhellmann: yes
20:24:12 <ttx> OK, looks like amrith has the feedback he needs now
20:24:19 <sdague> amrith: honestly, a metric seems less useful here than the team itself asserting it
20:24:20 <amrith> ttx, yes I do
20:24:25 <sdague> I wouldn't want to figure out a crazy metric
20:24:28 <dhellmann> sdague : I think I agree with that.
20:24:30 <ttx> dhellmann: probably yes
20:24:34 <dims> am with sdague, wanted teams to self-apply
20:24:39 <jroll> sdague: ++
20:24:42 <flaper87> sdague: ++
20:24:55 <amrith> so, this may be premature, but I'm hoping that by the end of the week I can tell you that trove won't need the tag after all. but no promises on that.
20:24:57 <dims> don't want to broker or judge or check periodically
20:25:11 <ttx> sdague: dhellmann said that it should not be an assert, as those are desirable behavior. I kinda agree
20:25:15 <dims> amrith ++
20:25:27 <ttx> But can be self-influcted team tag in 99% of the cases
20:25:32 <ttx> inflicted*
20:25:36 <jroll> I think the TC may need to encourage teams to take the tag now and then, though
20:25:37 <ttx> OK, I think we can move on
20:25:45 <dims> jroll : that's fair
20:25:47 <EmilienM> amrith: we look forward to know
20:25:48 <dhellmann> ttx, sdague : let's call this team:low-activity and let teams add it themselves or have the TC add it based on subjective judgement
20:25:55 <ttx> dhellmann: ++
20:25:58 <amrith> EmilienM, you and me both :)
20:26:00 <johnthetubaguy> well if the teams not doing anything, will the remember about the tag? I guess thats what jroll said
20:26:03 <fungi> i think if the tc needs to apply the tag, it's something worse than warrants that tag
20:26:10 <ttx> I think it's a great tool to signal teams taht are struggling and need help
20:26:10 <jroll> johnthetubaguy: right :)
20:26:20 <EmilienM> amrith: what is the key factor here?
20:26:23 <dims> johnthetubaguy : its a bat signal for, we need help here too right?
20:26:26 <dhellmann> johnthetubaguy : right, if a team is so inactive as to not even think about this tag, it's probably on its way to being moribund enough that we would just retire it
20:26:38 <dims> ah ttx beat me to it
20:26:43 <johnthetubaguy> dhellmann: possibly yeah
20:26:44 <mriedem> fwiw i'm in an active team and never think about our tag status
20:26:46 <amrith> EmilienM, I don't follow your question
20:26:48 <jroll> I don't think teams often think about tags
20:26:50 <jroll> mriedem: ++
20:26:51 <fungi> ttx: dims: if there are bat signals for that, let me know. infra could use a few ;)
20:26:56 <mriedem> b/c there are so many tags and i'm separated from them
20:26:59 <EmilienM> amrith: what happens this week? I might have missed something
20:26:59 <ttx> Alright, let's move on
20:27:00 <dims> :) fungi
20:27:12 <ttx> amrith has everything he needs for next rev
20:27:14 <dims> mriedem : yep
20:27:20 <amrith> EmilienM, time is up, ttx says move along :)
20:27:30 <EmilienM> amrith: well done ;-)
20:27:32 <amrith> thanks all, I have the feedback I need for now
20:27:44 <ttx> Thanks for pushing this amrith
20:27:49 <ttx> #topic Use case analysis for Golang addition to Openstack
20:27:51 <amrith> but if things don't work, I'll blame dims
20:27:56 <ttx> #link https://review.openstack.org/451524
20:28:02 * dims bows
20:28:02 <ttx> is thiago here ?
20:28:05 <tdasilva> hello
20:28:10 <notmyname> hello
20:28:13 <ttx> tdasilva: oh, hi!
20:28:17 <flaper87> tdasilva: notmyname yo yo!
20:28:19 <tdasilva> ttx: o/
20:28:26 <ttx> Looks like exactly what I had in mind for a "Step 1"
20:28:31 <dhellmann> this is a nice write up, thanks for putting it together
20:28:40 <ttx> but then I didn't write /that/ process
20:28:46 * flaper87 is happy to see this moving forward
20:28:52 <tdasilva> dhellmann: thanks
20:28:52 <ttx> That was flaper87's
20:28:59 * flaper87 looks around
20:29:17 <ttx> Any last-minute question before I approve ?
20:29:30 <tdasilva> not from me, thanks everyone for reviewing
20:29:45 * flaper87 was about to make a terrible joke... holding back
20:29:50 <ttx> alright then
20:29:51 <flaper87> no questions
20:29:51 <fungi> last-minute +1 from me. looks great
20:30:01 <jroll> flaper87: meetings are prime for terrible jokes
20:30:10 <thingee> amazing ps1 merge
20:30:11 <jroll> this is a great write-up, thanks tdasilva :)
20:30:12 <ttx> approved
20:30:19 <flaper87> jroll: :P
20:30:20 <ttx> flaper87, dims: Now it's approved, does that mean we need to start working / finalize the work on step 2 now ?
20:30:22 <thingee> achievement unlocked
20:30:28 <ttx> As a reminder, step 2 means setting up the CI pipelines, define how the deliverables are distributed, how dependencies will be managed...
20:30:34 <ttx> Define how stable maint, i18n & docs will work, define a way to share code/libraries, and guarantee compatible functionality for the base common libraries.
20:30:45 <dims> ttx : yes, i'd like to see some work on the common libraries etc
20:30:46 <flaper87> yes, it means all that needs to happen :)
20:30:49 <EmilienM> flaper87: can you pm the private joke?
20:30:50 <ttx> Feels like we already started that
20:30:56 <dtroyer> ttx: we have
20:31:06 <dtroyer> some of it at least
20:31:27 <fungi> are there any ci jobs building/testing gocode yet?
20:31:30 <dims> ttx : we have brought up a lot of infrastructure already. but a lot more work needs to be done
20:31:34 <dims> fungi : yep
20:31:38 <fungi> awesome!
20:31:38 <flaper87> I'm happy to help and follow-up on the process aspects of this work
20:31:44 <dtroyer> fungi: golang-client has a small unit test job
20:31:52 <flaper87> if there are questions about the expectations, do let me know
20:32:04 <fungi> one small step for golang-client, one giant leap for the ecosystem
20:32:05 <flaper87> tdasilva: and myself had a convo about this at the PTG, tho
20:32:09 <ttx> flaper87: cool, just want to make sure we cross all the T's based on your process description
20:32:10 <dims> fungi : i was just poking at devstack+k8s+k8s-e2e tests (http://logs.openstack.org/53/453253/2/check/gate-k8s-cloud-provider-golang-dsvm-conformance-ubuntu-xenial/80726c8/console.html)
20:32:31 <fungi> nice
20:32:53 <dtroyer> the dependency mirroring bits for CI are going to take some work
20:32:54 <ttx> alright, anything else to discuss on this topic ?
20:33:06 <tdasilva> in terms of CI jobs I noticed a jenkins job for golang, but not sure where that is being used yet
20:33:11 <dims> tdasilva : can i expect swift team to help with the golang commons library?
20:33:25 <fungi> dtroyer: consider retrieving deps through our caching proxy as an alternative maybe?
20:33:35 <dims> tdasilva : y, ping me later on openstack-golang, and will walk you through what is there
20:33:41 <ttx> I'd rather say "members of the Swift team", don't think everyone needs to jump in
20:33:42 <tdasilva> dims: sounds good
20:33:49 <dims> ++ ttx
20:34:00 <dtroyer> fungi: expect questions tomorrow
20:34:00 <fungi> dtroyer: though could get similarly complex since it sounds like there's no central host for go deps
20:34:07 <dtroyer> right
20:34:30 <ttx> yes the dep situation still needs to be clarified a bit
20:35:08 <ttx> From a release management perspective, the fallback will be to publish signed tarballs, but ideally we'd like to support whatever makes the most sense in this world
20:35:24 <ttx> which is *not* signed source code tarballs apparently :)
20:35:27 <dhellmann> ++
20:35:38 <mtreinish> ttx: heh
20:35:39 <dtroyer> ttx: the biggest thing I'm worried about for releases are the genrated files and how to include those
20:35:58 <mordred> dtroyer: I gave in an committed them to the repo in oaktree
20:36:09 <mordred> dtroyer: I still feel dirty and wrong - but it's how go works
20:36:09 <ttx> mordred: boo
20:36:13 <dhellmann> fungi, dtroyer : I wonder if we can learn anything about mirroring build dependencies from some of the distros. I know RH doesn't like to have a build depend on outside servers, either.
20:36:14 <fungi> the gocosystem seems perfectly happy with git tags (or even just random git commit shas from arbitrary foks on github at times?) sounds like
20:36:24 <mordred> ttx: there is literally no other choice when the consumptoin model is only via git
20:36:46 <ttx> mordred: what's next. Jars deployed with maven ?
20:36:53 <dims> ttx : so question for you, what's the next check point before we allow an official release of a go based deliverable?
20:36:58 <dtroyer> that's where tools like glide are helpful, as an indirection step to setting up the GOPATH dirs
20:36:58 <ttx> All my certainties are gone
20:37:06 <mordred> ttx: :)
20:37:19 <mordred> dtroyer: this is true - although once you get in to things like generating protobuf code from .proto files ...
20:37:30 * flaper87 looks at ttx and mordred suspiciously
20:37:44 <ttx> dims: I think we can add stuff in now, as long as the step 2 work is in progress and we are pretty confident the work will be completed
20:37:45 <dhellmann> ttx: time is circular
20:37:51 <ttx> But then flaper87 designed that process
20:38:06 <dims> ack ttx
20:38:17 <ttx> so I'm happy to defer to him on when time is right
20:38:32 <ttx> OK, let's move on
20:38:35 <flaper87> dims: As far as release go, the step 2 should be completed
20:38:45 <flaper87> but that doesn't prevent projects from being created
20:38:46 <dims> flaper87 : ack on that
20:38:50 <dims> right
20:38:54 <ttx> Like I said, for release management we have a fallback
20:39:09 <ttx> and we can incrementally improve from there
20:39:23 <ttx> for dependency management, not sure we have such a fallback
20:39:29 * flaper87 wonders if ttx is trying to hack "The Process"
20:39:34 <flaper87> :P
20:39:35 <ttx> It's more just a fall
20:39:57 <dims> abyss!
20:39:58 <ttx> Today is pun day
20:40:06 <ttx> OK, moving on!
20:40:13 <ttx> #topic Add a "docs:install-guide-verified" tag
20:40:17 <ttx> #link https://review.openstack.org/445536
20:40:24 <ttx> dhellmann: you sent an email to ask that we table this until you have a chance to work out the next draft with Alexandra ?
20:40:25 <dhellmann> asettle and I are working on a new draft of this
20:40:35 <dhellmann> yeah, I think we'll have something next week
20:40:36 <ttx> ok, so maybe useless to talk about it now
20:40:51 <dhellmann> yeah, let's skip it for now
20:40:52 <ttx> Have several topics for open discussion, so ok to skip
20:41:09 <ttx> #topic Open discussion
20:41:17 <ttx> I had a few topics to cover
20:41:21 <ttx> * Centrally documenting API versions for exposure in project navigator
20:41:26 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2017-March/114690.html
20:41:34 <ttx> The web team at the Foundation would like to expose accurate API version information in the Project Navigator
20:41:37 <ttx> A noble goal
20:41:45 <ttx> So they would like to collect things like http://paste.openstack.org/show/604775/ or http://paste.openstack.org/show/604776/ (which rosmaita proposed)
20:41:56 <ttx> I would rather not add this to projects.yaml though, because it's not governance, nor does it need TC approval
20:42:05 <ttx> lsell suggested that they create a specific project-navigator repository to collect that information
20:42:11 <johnthetubaguy> we have links to api-ref docs now, is there a reason why thats not enough?
20:42:14 <ttx> (and any other non-governance-releated information they will need for the navigator in the future)
20:42:17 <mtreinish> ttx: yeah it seems out of place in projects.yaml
20:42:26 <ttx> Does that sound like a good idea ? We can make it a TC-owned repo and delegate review.
20:42:32 <ttx> Or would you rather collect that information somewhere else ?
20:42:46 <ttx> johnthetubaguy: I think the issue is if each project does things differently
20:42:47 <johnthetubaguy> it just feels like a failure of the existing API docs
20:42:59 <dhellmann> johnthetubaguy : ++
20:43:17 <sdague> so, I think a machine structured overview in api-ref feels like the right thing here
20:43:18 <mtreinish> ttx: I'm with johnthetubaguy, it feels like the projects can expose this in a standard way
20:43:25 <sdague> we just need a schema
20:43:28 <fungi> what if it's consumable by the existing api docs, simply extracted into its own tree/repo for reduced duplication?
20:43:32 <dhellmann> ttx: if we want to standardize, then let's get the API WG to set a standard
20:43:32 <johnthetubaguy> sdague: that works
20:43:36 <jroll> johnthetubaguy: so the new project navigator wants to show which API versions are supported in (the current?) release. I would show you but the dev version is broken
20:43:46 <jroll> sdague: that makes sense to me
20:43:58 <fungi> seems a lot like the discussion about coming up with a standard format for driver feature matrices between projects
20:44:04 <dhellmann> jroll : the question is, why is that in the navigator to begin with?
20:44:06 <ttx> dhellmann: it's blocking the release of the new version though, so it's not realkly a one-year thing
20:44:09 <jroll> johnthetubaguy: ah here it is, see version history toward the bottom http://devbranch.openstack.org/software/releases/ocata/components/glance
20:44:11 <dhellmann> fungi : ++
20:44:19 <dhellmann> ttx : the question is, why is that in the navigator to begin with?
20:44:32 <jroll> dhellmann: good question, I can't answer that :/
20:44:45 <fungi> the project navigator wants a project/api versioning history, the marketplace wants driver feature matrices and contact details...
20:44:48 <ttx> dhellmann: I asked the question, and it was mentioned as a useful piece of information to communicate about a given service
20:44:55 <dhellmann> ttx: I'm also not sure why you think agreeing on a standard outside of any of our processes is going to be faster or work better than using the working group :-)
20:44:59 <sdague> the API version information seems useful honestly, I have no problem with it being there
20:45:21 <mordred> it should be correct though
20:45:28 <mordred> and should include the list of versions each release supports
20:45:29 <sdague> I think we just need an owner on defining a schema
20:45:32 <mordred> like, that glance page is wrong
20:45:36 <ttx> dhellmann: well, the API WG was very busy for the last 3 months defining API compatibility :)
20:45:48 <dhellmann> then, yeah, I guess let's set up a new repo to hold whatever data the navigator team needs that isn't available somewhere else
20:45:48 <jroll> mordred: right, hence why we're talking about a machine readable format :)
20:45:58 <ttx> dhellmann: ++
20:46:13 <fungi> options seem to be in a central repo or distributed across teams
20:46:15 <dhellmann> sdague : wouldn't that be the navigator devs?
20:46:17 <flaper87> dhellmann: ++
20:46:17 <mordred> I mean - we do already have a machine readable format for versions in a release - maybe we just use that?
20:46:20 <sdague> dhellmann: sure
20:46:24 <fungi> but with a consistent schema in either case
20:46:26 <ttx> I mean, *if* data ends up being covered somewhere else, we can delete it from the project-navigator extra-information directory
20:46:28 <dhellmann> fungi : centralize it
20:46:35 <jroll> mordred: we do? for api versions?
20:46:35 <mordred> and whereit diverges across projects, use this as an opportuntity to fix that
20:46:37 <mordred> jroll: yes
20:46:38 <sdague> mordred: it's not super readable
20:46:45 <mordred> no - it's Machine readable
20:46:48 <jroll> mordred: where?
20:46:50 <mordred> a program can read it
20:46:53 <sdague> yeh, where?
20:47:02 <mordred> the version discovery document each service services from /
20:47:15 <sdague> mordred: ok, but you have to stand up the services at all those versions
20:47:18 <dhellmann> so literally you have to stand the service up and ask it
20:47:18 <jroll> mordred: you want the project navigator to run every version of every api service?
20:47:23 <mordred> nono - I get that ...
20:47:25 <mordred> no
20:47:30 <mordred> I'm not saying we collect it that way
20:47:38 <mordred> I'm saying we HAVE a format - we just need to collect it and stick it somewhere
20:47:41 <mordred> so it can be read
20:47:45 <jroll> right
20:47:46 <dhellmann> oh, just use the same format
20:47:47 <cdent> why not each project keep a chunk of yaml in its own git. the projects.yaml knows where those repos are
20:47:48 <jroll> the question is where :)
20:47:49 <mordred> literally ever project can already produce this data
20:47:56 <sdague> cdent: yeh, pretty much
20:48:14 <ttx> mordred: we could dump that information in that project-navigator git repo alright
20:48:20 <mordred> cdent: sure. but maybe keep that chunk of yaml in an identical document format to what  GET / would return
20:48:33 * johnthetubaguy is still confused what people use that info in the navigator for, has CD too ingrained in his head
20:48:35 <dhellmann> I don't know. I'd just put it in one repo. It's much easier to change the schema as needed that way, since the tools could live there, too.
20:48:37 <jroll> I'm fine with something in api-ref per project or a central repo. tend to prefer the former so we can update it in the same patch that changes the microversion
20:48:46 <ttx> dhellmann: much easier to collect the information too
20:48:47 <cdent> mordred: yeah, that would be nice
20:48:54 <ttx> cloning a thousand repos is not taht fun
20:49:01 <dhellmann> ttx: ++
20:49:06 <fungi> yep, so comes back to the same as the driver feature matrix discussion. we agree there should be a common schema, there's disagreement on whether it's centralized (and whose responsibility it is to review proposed changes) or distributed across teams to each maintain their own
20:49:13 <johnthetubaguy> but, will it be kept up to date if it is centralized?
20:49:17 <mordred> thing is - if there is a single document with a collection of discovery documents for a release
20:49:20 <sdague> ttx: cloning them is more fun then forgetting to update the centralized repo
20:49:24 <mordred> then one would imagine a tool for reading it
20:49:25 <dhellmann> johnthetubaguy : will it be kept up to date if it's not?
20:49:25 <johnthetubaguy> what fungi said
20:49:32 <mordred> which would mean maybe a _cloud_ would also post such a documentfor itself
20:49:35 <mordred> that could also be read
20:49:40 <mordred> without having to hit every service
20:49:47 <mordred> and we baby step towards users knowing what's going on
20:49:53 <johnthetubaguy> dhellmann: it seems as likely as the api-ref to be up to date, if its part of that
20:50:05 <sdague> yeh, api-ref has high incentive to stay up to date now
20:50:10 <dhellmann> johnthetubaguy : they want the history, too, though, right? not just what's current?
20:50:14 * cdent gives mordred hope and glory
20:50:17 <sdague> and that's part of a normal management process
20:50:27 <johnthetubaguy> dhellmann: that seems like a one time thing that needs adding as a release goal
20:50:30 <sdague> anyway, we still need a schema
20:50:32 <jroll> dhellmann: ironic is able to keep something like this up https://github.com/openstack/ironic/blob/master/doc/source/dev/webapi-version-history.rst
20:50:34 <jroll> just needs a format
20:50:45 <fungi> dhellmann: the schema could be append-only and you just stop updating it in stable branches?
20:50:56 <dhellmann> ok. I'm not doing the work, so I'll let others decide on central or distributed data storage.
20:51:02 <sdague> ttx: whoever is doing this from foundation side able to tackle the schema question, as they are parsing it?
20:51:04 <mordred> please don't define a new schema. please please please
20:51:24 <sdague> mordred: then you define the schema :)
20:51:31 <dhellmann> mordred : are all of the services returning data in the same schema?
20:51:34 <thingee> would like to bring up that for the Market Place, the projects are coming together on Nova's originally matrix in a ini file as a common format to suck in the information to the foundation's site.
20:51:39 <ttx> mordred: available to work with jimmy on a format ?
20:51:40 <fungi> mordred: what current schema do you have that encapsulates the release-by-release portion of the requirement?
20:51:44 <mordred> dhellmann: it's nearly identical - the schema being the superset is not hard
20:51:47 <thingee> these come from each project's repo. could probably just follow that idea
20:51:48 <sdague> because I guess I don't quite see how we get from the single release one we have to the multi one
20:51:52 <dhellmann> mordred : ok, cool
20:52:00 <sdague> mordred: but if you solve it, will totally implement it
20:52:10 <mordred> sdague: awesome. I will sign up to do that
20:52:29 * dims checks what's on mordred 's plate already :)
20:52:32 <ttx> I just don't want them to be stuck until we agree on a file format when all they need is a piece of information from each project :)
20:52:39 * dhellmann hands mordred another plate to hold this new task
20:53:20 <ttx> #agreed mordred will come up with a format that avoids creating yet another format for this information
20:53:23 <sdague> ttx: well, mordred hopefully figures it out quick with jimmy
20:53:24 <fungi> perhaps we could, in parallel, give them the info they need for the initial veesion of teh site and work on a format/parser so they don't have to keep asking?
20:53:30 <sdague> then we implement quick
20:53:36 <ttx> sdague: yes, I'm hopeful :) They are in the same TZ
20:53:42 <sdague> any ask is basically just doing that with an adhoc schema
20:53:51 <fungi> heck, they're in the same state a lot of the time
20:53:53 <ttx> fungi: that's plan B if plan A takes forever
20:54:09 <ttx> OK, I'll connect the dots
20:54:18 <ttx> * TC election - this is nomination week
20:54:24 <ttx> #link https://governance.openstack.org/election/
20:54:34 <ttx> As a reminder, the following members have terms ending in April: dims, dtroyer, flaper87, johnthetubaguy, mtreinish, thingee, ttx
20:54:42 <ttx> Whether you plan to run (or plan not to run), you should probably post something this week to the -dev list.
20:54:50 * johnthetubaguy nods at ttx
20:54:54 <ttx> Anything else, anyone ?
20:54:57 <thingee> I have announced my non-candidacy http://lists.openstack.org/pipermail/openstack-dev/2017-April/114974.html
20:55:00 <zaneb> I added the footnote with implementation info that sdague requested to https://review.openstack.org/#/c/447031/
20:55:00 <sdague> TC vision draft is out
20:55:01 <ttx> dhellmann, EmilienM, thingee: quick update on Forum topics selection, maybe ?
20:55:07 <sdague> #link https://review.openstack.org/#/c/453262/
20:55:08 <jroll> sdague: ++
20:55:12 <EmilienM> ttx: we are working on the selection this week
20:55:23 * dims thanks thingee for his work and guidance on the TC!
20:55:25 <EmilienM> and we are ranking the sessions
20:55:26 <thingee> ttx: we have a process in place to start selecting before our meeting this thursday I believe?
20:55:27 <dhellmann> we're reviewing now and meeting thursday to discuss the forum sessions
20:55:28 <sdague> ttx: I think you are on the hook for doing the email broadcast around that
20:55:32 <ttx> dims: he is not gone yet
20:55:43 <ttx> sdague: yes
20:55:44 * mtreinish is still working on his election repo patch
20:55:46 <dims> :)
20:56:13 <fungi> dims: i think that means there's still time to change his mind? ;)
20:56:16 <EmilienM> sdague: we should tweet it :D
20:56:24 <sdague> EmilienM: feel free :)
20:56:25 <dims> fungi :)
20:56:30 <EmilienM> sdague: I'm bad at that
20:56:45 <sdague> I was just making sure it got out there, and I think ttx said he was going to do the publicizing
20:57:26 <ttx> sdague: I'm fine with sharing the task with whoever
20:57:27 <johnthetubaguy> does that come once we have the survey ready?
20:57:36 <ttx> Just thoughts I would use my -dev ML juice for the cause
20:58:17 * ttx gmances at the TC backlog
20:58:22 <ttx> glances even
20:58:41 <dims> we should get this out (castellan/oslo - https://review.openstack.org/#/c/451131/)
20:58:44 <sdague> johnthetubaguy: good question, probably worth getting gothicmindfood looped in on that. It would be nice to have survey feedback ready to go
20:58:48 <ttx> zaneb's Resolution on OpenStack's mission for cloud applications shall be back on the table next week
20:58:49 <sdague> when the ML post hits
20:59:02 <johnthetubaguy> sdague: +1
20:59:08 <dhellmann> dims : I think that one falls under the "one week with no objections" rule
20:59:21 <dims> ah cool thanks dhellmann
20:59:26 <zaneb> ttx: I updated the review after last week's discussion
20:59:36 <ttx> zaneb: yes, looks like it's going well
20:59:52 <zaneb> I think that addresses everything sdague requested
20:59:54 <ttx> mordred's "Add tag assert:never-breaks-compat" might be back if there is some new rev in it
21:00:10 <sdague> zaneb: yes, thank you
21:00:12 <EmilienM> I'll probably skip next meeting, due to the leadership training
21:00:13 <johnthetubaguy> I like the cloud application thing, its really the same thing I was trying to do with the VM & BM resolution, so I might think on how to do the same thing for that
21:00:15 <dtroyer> a non-trivial subset of us will be in MI next week…
21:00:16 <ttx> We'll also discuss the App Catalog team removal
21:00:18 <zaneb> sdague: cool, thanks
21:00:19 <dims> outta time...
21:00:20 <fungi> EmilienM: as will i
21:00:26 <ttx> Oh right
21:00:28 <jroll> michigan \o/
21:00:29 * fungi updates excuses list
21:00:32 <ttx> We might want to skip
21:00:46 <dtroyer> 5 by my count
21:00:48 <ttx> You clearly should not have a TC meeting during that week
21:00:57 <dhellmann> that's a big group to be missing
21:00:58 <ttx> ok, I'll move that discussion to the -tc ML
21:01:01 <dhellmann> ++
21:01:08 <ttx> #endmeeting