Thursday, 2018-01-11

*** diablo_rojo has quit IRC00:05
*** diablo_rojo has joined #openstack-tc00:06
*** kumarmn has joined #openstack-tc01:34
*** kumarmn has quit IRC01:35
*** kumarmn has joined #openstack-tc02:02
*** kumarmn has quit IRC02:04
*** mriedem has quit IRC02:56
*** harlowja_ has quit IRC03:21
*** kumarmn has joined #openstack-tc03:28
*** kumarmn has quit IRC03:54
*** kumarmn has joined #openstack-tc04:03
*** kumarmn has quit IRC04:09
*** kumarmn has joined #openstack-tc04:09
*** kumarmn has quit IRC04:10
*** kumarmn has joined #openstack-tc04:11
*** kumarmn has quit IRC04:16
*** kumarmn has joined #openstack-tc04:28
*** rosmaita has quit IRC04:34
*** kumarmn has quit IRC04:38
*** kumarmn has joined #openstack-tc04:39
*** kumarmn has quit IRC04:44
*** harlowja has joined #openstack-tc05:29
*** gcb has quit IRC05:30
*** gcb has joined #openstack-tc05:31
*** liujiong has joined #openstack-tc06:09
*** liujiong has quit IRC06:28
*** liujiong has joined #openstack-tc06:33
*** harlowja has quit IRC06:47
*** dims_ has quit IRC07:21
*** dims has joined #openstack-tc07:25
*** kumarmn has joined #openstack-tc07:39
*** kumarmn has quit IRC07:44
ttxsmcginnis: I notice you're going through non-official projects and propose the inactive ones for retirement07:47
ttxfwiw it's something we have not really been paying much attention in the past as this is ungoverned territory07:48
ttxretirement there is pretty much an infra decision07:49
*** jpich has joined #openstack-tc09:02
*** flaper87 has quit IRC09:17
*** flaper87 has joined #openstack-tc09:21
*** flaper87 has quit IRC09:21
*** flaper87 has joined #openstack-tc09:23
*** dtantsur|afk is now known as dtantsur09:38
*** liujiong has quit IRC10:23
*** cdent has joined #openstack-tc10:30
*** rosmaita has joined #openstack-tc10:32
dimsttx : seen this?
cdenthmm, interesting11:32
dimscdent : y, short hop away for you both11:38
*** kumarmn has joined #openstack-tc11:40
*** kumarmn has quit IRC11:45
*** cdent has quit IRC12:02
*** cdent has joined #openstack-tc12:16
*** rosmaita has quit IRC12:34
ttxdims: thx for the pointer !13:09
smcginnisttx: Do you think I should bring this up with the infra team? I would like to clean up the old stale repos. I think it would help leading up to flattening the namespace, it would clean up a lot of project-config, and it might help with the whole "what is OpenStack" question (before namespace flattening).13:27
cdent(removing corpses)++13:30
smcginniscdent: Tangentially ties in to the whole developer happiness idea too, at least for new devs coming in and looking at all that is out there and getting overwhelmed.13:32
ttxsmcginnis: sure, it sounds like a good idea. I was just pointing out that the TC has no legitimacy ruling that corner13:33
persiaI think cleaning up abandoned non-openstack projects is a laudable goal, and that anyone interested should reach out to Infra.  I think doing so while wearing a TC hat is dangerously irresponsible in terms of the "what is openstack" question.13:33
smcginnisttx: Oh, yep, I get that.13:33
ttxpersia: exactly13:33
smcginnispersia: Can you elaborate on "dangerously irresponsible"?13:34
ttxI fear that sending "is ailuropoda still alive" questions on openstack-dev increases the confusion rather than removes it13:34
ttxI think it's a godo topic for the -infra list though :)13:34
persiasmcginnis: By wearing an OpenStack TC hat whilst engaged in an activity for which the TC has explicitly refused responsibility, one erodes the memory of the TC declaring "that's not under openstack governance", and those with limited view into project details are less likely to receivce the correct understanding.13:35
cdentthat the TC has refused such responsibilty should maybe change?13:35
smcginniscdent: ++13:35
ttxcdent: well, no. That space is precisely defined as the space we are not governing13:36
ttxit's the only difference with the "official" space13:36
cdentYeah, I know that's what we said, but I'm not sure it was the right thing to say13:36
cdentand I think we're foolish if we constrain ourselves to never changing13:36
persiaSo, "dangerous" in that it might inadvertently involve the TC in things for which the TC hasn't agreed to take responsibility.  Maybe not precisely "irresponsible", but rather "misresponsible", im the sense of being responsible for the wrong thing; althpugh maybe "irresponsible" in terms of being responsible for the public understanding of TC responsibilities.13:36
ttxcdent: you mean all projects we host should be official ? I proposed that a while ago and was not exactly supported13:37
persiacdent: I'd be against that: it makes the bar for using OpenStack infra too high.  projects should be able to use infra without invoking TC.13:37
smcginnisGoverned or not, I care about OpenStack and would like to see it not weighed down by entropy.13:37
cdentI'm not suggesting that that all projects be official, I simply support the assertion that entropy is a problem13:37
ttxgood counterarguments include "projects need a space to start before thinking governance" and "it's a great space to learn our tooling"13:37
smcginnisThe big tent introduced mass confusion, IMO, that I think we are still living with and would like to do something to decrease.13:37
cdentand we are in a place to know and do something about it13:37
persiasmcginnis: In this case, I think you would better state that as "I care about perception of OpenStack and believe that removing entropy from OpenStack Infra will be a good thing".13:38
smcginnispersia: You state my intent better than I have.13:38
ttxI totally support infra cleaning up :)13:38
persiasmcginnis: I'm glad to hear that: I feared we might disagree :()13:38
persiasmcginnis: Still, I think you should do that as an individual.  I think you'd find many like-minded individuals in this channel.  I would argue against a TC decision to have anything to do with the effort.13:39
ttxpersia: that was not really in the cards13:39
smcginnisOK, if I can't do it as an idividual while serving on the TC, I will step back and hope someone picks it up before I am able to do it.13:40
persiattx: An effective charman with a clear vision is a treasure never to be undervalued13:40
smcginnisBut I do not entirely agree this isn't something TC-associated folks shouldn't do.13:40
persiasmcginnis: Who says you can't do it as an individual while you are on the TC?  Just don't write "The TC ...", instead write "I think ..."13:40
ttxI think it's a good effort to continue -- The only advice I have is that you should be clear that those are not official things and that it is an infra decision if the owner does not show up13:40
smcginnispersia: Did I position it as a TC effort somewhere?13:41
smcginnisIf so, it was not intentional.13:41
*** rosmaita has joined #openstack-tc13:41
ttx(fwiw I didn't read it as a TC thing, but by default assumed it was a release management thing, until I realized it was unofficial leftovers)13:42
persiaApologies then: my original statement in this discussion was intended only as support for ttx's earlier assertion that it was an Infra thing: in this case, not writing may have been the better choice (as ttx has stated my opinion in less words and is currently activec, and on reflection, your query was addressed to him).13:42
smcginnispersia: Not at all, input is good.13:44
smcginnisI know it is more an infra thing as far as the cleanup goes, but it is an OpenStack thing as well and something I do not see being addressed.13:44
cdentPersonally I welcome any opportunity to clarify and/or question the roles of the TC13:45
persiaWell, I'm an interested party, as someone who has sponsored some work on some projects hosted on openstack-infra that aren't currently very active (but which I use, and expect to have folk work on again).13:45
ttxsmcginnis: I did a review of the negative space back when I proposed to clean up, which you may find interesting13:47
smcginnisttx: Yes, I think I would.13:47
* ttx tries to find that etherpad again13:48
ttxIt was basically listing all repos that are not in governance13:49
smcginnisLooks a lot like the list I was compiling last night of the stale projects.13:49
cdenthow are you defining "stale"? And presumably stale doesn't mean "dead" it means "candidate for finding out if dead"?13:49
ttxopenstack/sticks-dashboard  - Sticks Horizon Plugin -- 4 commits, last modified Aug 5, 201513:50
smcginniscdent: Exactly.13:50
ttxThat is pretty stale in my book :)13:50
smcginniscdent: I started just going through the repos and looking for any that have not had a commit for over a year, with the plan to go back and look more deeply into any official meeting minutes.13:50
ttxthere are a bunch of one-commit things13:51
smcginnisGet the whole candidate list before doing one by one.13:51
smcginnisttx: Trying to look for that. And things like anvil that had a last commit of "retire project" but was still in project-config.13:51
smcginnisAnd then of course there were things like openstack/ailuropoda that were amusing. :)13:52
ttxsmcginnis: the list dates back from June of last year, so would likely need refresh. We "fixed" quite a few in that list over the end of the year13:52
ttxasked for help on processing it but didn't get much13:52
smcginnisttx: I do notice a few interesting ones. Is it OK if I update this etherpad, or should I stick to my own notes?13:53
ttxsmcginnis: please do whatever you want with it :)13:54
dhellmannI'd be interested in seeing a similar analysis of official projects. We have several low volume projects and I wonder if they're stable, having trouble recruiting help, or ready to shutdown.13:54
ttxI just fear the info in it is outdated now13:54
smcginnisThe ones that are not outdated may be telling.13:54
smcginnisdhellmann: ++ That would be interesting to at least categorize them so we have a clear lay of the land.13:55
* smcginnis steps away to see his kids off to school13:55
ttxLast call for help (unanswered back then):
ttxOriginal email starting this thread if you need a refresher:
*** rosmaita has quit IRC14:34
dhellmanndims : foss backstage looks like it has the potential to be very interesting14:39
dimsindeed dhellmann, i saw another one from linux foundation, but that seemed like invite-only -
dimssee topics/presentation from 201714:41
dhellmannoh, I'd heard of that one but didn't realize it required an invitation14:41
dimsdhellmann : i mean if you don't submit a proposal then you need an invite from what i can tell14:42
*** hongbin has joined #openstack-tc14:48
ttxtc-members assemble15:00
ttxnot much on my list for this hour, except continuing the discussion(s) we had on Tuesday15:01
ttxWe talked goals, and looked for next steps for the few stuck proposals we have15:01
* cmurphy drafting interop testing email15:02
ttxBrainstorming Q goals is probably the most urgent15:02
cmurphy*R goals ?15:02
ttxerr yes15:02
ttxR goals15:02
ttxHad a hard time getting to mikal on IRC, so sent email15:02
ttxlooks like the nova-compute stuff is still WIP15:02
*** mriedem has joined #openstack-tc15:02
ttx(moving nova-compute to privsep)15:03
* ttx looks up recent goal proposals15:03
persiaMy experience with the LF leadership summit is that most folk who are known quantities in open source (being on the TC would qualify) can request an invite with an expectation that it will be offered.15:03
ttxI like the concept of requesting invites15:04
persia is another one that some folk like, in a similar vein15:04
fungioh, yes, it's office hour15:04
ttxyes the LF leadership summit is the Davos of open source15:04
ttxYou can ask but you kinda expect to be invited without having to ask15:05
ttxIt's shortly after PTG this year15:05
* dhellmann mustn't know the right people15:05
ttxdhellmann: it's not just you :)15:05
persiaAll the folk I know that receive invitations without asking either a) are actively involved in coordination of active LF projects or b) are nominated representatives from platinum (or higher) sponsors of LF projects.15:06
smcginnisI spot a hogepodge in that conference photo.15:06
dhellmannI think I'm more interested in going to a leadership conference that is more open15:06
smcginnisdhellmann: ++15:06
persiaCLS is very open, and convenient if you have other reasons to be in Portland the following week.15:07
dhellmannalso that's not 1/2 way around the planet from a conference he'll be at the week before15:07
persiaOLS is better titled "LF projects leadership summit".15:07
ttxyes, I've done CLS in the past, it's a pretty open setting15:07
smcginnispersia: Is there something the following week?15:07
persiasmcginnis: OSCON15:07
dhellmannis CLS the one that Jono Bacon is involved with?15:07
ttxCLS = OSCON's community leadership summit15:07
persiadhellmann: Yes.15:07
dhellmannok, I think that's the one I was thinking of instead of the LF one15:08
ttxnot really linked to OSCNO but traditionally organized at its margins15:08
ttxMore grassroots, less thought leaders15:08
smcginnisIt finally doesn't conflict with an OpenStack event.15:09
ttxso we have remove-mox and ensure-pagination-links up as goal candidates15:09
ttxWe dsicussed requiring basic cold upgrades capabilities as a good goal, but missing a champion15:10
dhellmannthe remove-mox goal is good, but rewriting some of those test suites is going to be a lot of work15:10
smcginnisPrivsep was another one I would like to see.15:10
smcginnisBut also a lot of work.15:10
ttxsmcginnis: not that much once Nova is covered15:10
dhellmannprivsep feels like it has more user benefit15:10
fungiokay, caught up. on the topic of making everything we host official, that's essentially "agree to be governed by the openstack tc or get out"15:10
dhellmannttx: do we really have any projects that can't be upgraded at all?15:10
dhellmannor are their tags just not in place?15:11
ttxdhellmann: it's more that testing is not in place imho15:11
persiafungi: Yes, that would be the proposition.15:11
ttxthey can, they just don't get on checking it15:11
smcginnisfungi: Is there a proposal to make everything we host official?15:11
dhellmannok, then I support adding upgrade testing as a goal15:11
ttxdhellmann: I feel like it's mostly a QA effort rather than a feature effort15:11
cdentfungi: no one ever made that proposal, it was a misunderstanding15:11
fungialso removing dead projects hasn't been a super high priority because it's a fairly small fraction of the whole, and hunting down unofficial project maintainers is nontrivial, and deciding for them that their projects are dead is something we've not generally been comfortable doing in the past15:11
cdent(at least not today)15:12
dhellmannttx: sure. unless we find a bug.15:12
ttxdhellmann: I think it's gently raising the bar on what we expect from "an openstack project"15:12
mgagneas an op, I'm really looking forward for policy-in-code completion =)15:12
dimshave folks here heard of apache attic? (to provide process and solutions to make it clear when an Apache project has reached its end of life..)15:13
dhellmannttx: if we keep raising the bar, we're going to need to bring back some sort of state for "just starting out under governance"15:13
dhellmannotherwise starting/adopting new projects is going to become impossible15:13
dimsright dhellmann15:13
fungicdent: you were perhaps playing devil's advocate, but you suggested we should revisit our earlier choice that the tc disclaims responsibility for unofficial projects we're hosting in the infrastructure15:14
dhellmannmaybe that wouldn't be  a bad thing to do anyway15:14
smcginnisI feel like I'm missing something. Where did we talk about raising the bar for projects?15:14
ttxdhellmann: you think requiring a grenade-like  test is hard ?15:14
dhellmannttx: I'm looking at the trend, not this specific change15:14
cdentfungi, no I was disputing that we should be responsible for cleaning up what's there15:14
*** kumarmn has joined #openstack-tc15:14
ttxsmcginnis: saying all projects need to support upgrade15:14
dimssmcginnis : i got that from the email thread i think15:14
cdentand asserting that in general we should take more responsibility, not less15:14
dhellmannttx: but yeah, it's "one more thing" and it's not exactly trivial15:14
ttxsmcginnis: part of the goal discussion, not the other oen15:15
smcginnisOK, good. :)15:15
fungicdent: it's the same thing, right? if the tc takes on the power to decide when a project is dead and should be removed, then that project is governed by the tc15:15
cdentto me, that's a stretch15:15
smcginnisfungi: Or the TC are being good stewards.15:15
fungii don't see where the division is, personally15:15
cdentstewardship of the dead15:15
fungi#define "dead"15:16
dimsor we saddle infra for that responsibility?15:16
ttxI like to see it as an infra issue15:16
persiaI think Infra does a good job with it today.15:16
cdentmaybe we have a confused set of definitions of what "governed" means15:16
smcginnisI see a big gap between making sure things are cleaned up when no longer relevant vs "governing" those thigns.15:16
ttxsince the maintenance of that space falls on their hands15:16
fungias soon as the tc starts deciding what the criteria are for declaring unofficial projects "dead" it is governing them, like it or not15:16
dhellmannis it governing those projects, or the use of community resources?15:17
smcginnisdhellmann: That, in my opinion.15:17
ttxI don't think we should be taking "more responsibility" if that means making decisions further away from where the work is done.15:17
smcginnisAnd when there is no work being done?15:17
dimsright fungi15:17
fungialso, the tc is really not in the position to govern community resources at this point. remember our infrastructure is not on the road to being shared by multiple distinct communities under the foundation, of which the openstack tc is in charge of but one15:17
ttxsmcginnis: I would help within the infra team rather than wielding a big TC hammer15:18
fungier, is now on the road15:18
dhellmannfungi : good point15:18
smcginnisI should also point out, this didn't start as a TC hat wearing effort for me. It started as a "hey there's a lot of old crap out here" and I want it cleaned up effort.15:18
cdentas far as I can tell the TC is stating that it doesn't want to have a hammer15:18
fungiso the openstack tc deciding whether the shared infrastructure should host a particular repository for katacontainers is likely a problem15:18
ttxcdent: no, I'm saying it's always been an infra task to curate that space, and I don't see why that should change15:19
smcginnisI don't see the TC involved in that.15:19
dimssmcginnis : guess we have to point out what hat we are wearing in such emails15:19
ttxand I'm happy to see smcginnis tackle that issue, but I think that needs to be done with his infra hat on15:19
cdentI don't dispute that detail, ttx15:20
ttx(which I think was implied here but not clear to everyone)15:20
dimstotally ttx15:20
fungii'm just coming back to the (presumably devil's advocate) suggestion which was made that we should reconsider whether it should start being the openstack tc's responsibility to decide what to clean up in the shared hosting. i know it's not something we're likely to think a good idea15:20
fungisimply underscoring why it's a bad idea15:20
cdentWhat I'm upset (mildly) about is our continued effort to sort _not_ have the TC fill the leadership void that I think exists in OpenStack. The details of this particular case are a stimulus for that conversation, but not necessary relevant.15:21
smcginnisIf I continue with this (though now I have a lot of reservations) I will make that explicit in any further emails that I am not doing it as a TC initiative.15:21
ttxcdent: The trick here is in the "in OpenStack" part of the sentence15:21
cdentwhich sounds like lawyering to me15:21
ttxIn that case it's really not "leadership void that I think exists in OpenStack"15:21
cdentand not of any help or use to the community15:21
ttxsince it's precisely "leadership void that I think exists in what is not OpenStack"15:22
fungiyeah, i'm all for reaching out to maintainers of defunct repositories in our infrastructure and asking them whether they are okay with us closing them down, if that's what you want to spend your time on. i do also howver believe that it's a huge time sink for a very limited gain15:22
dhellmanncdent : do you have another example of something you'd like to see us doing that we're not? maybe one that's less fuzzy on the ownership?15:22
cdentdhellmann: give me a moment to think about it15:22
johnthetubaguycdent: is another way of saying it, who is going to do that thing, it seems important that it gets done, so how do we make that happen?15:23
cdentjohnthetubaguy: that's certainly as aspect of it15:23
dhellmanncdent : sure. I think I likely agree with you that there are some areas, fwiw, but I also think fungi's point about the foundation restructuring is a good argument to stay out of the specific infra thing.15:23
fungii would be surprised if we manage to shut down even 10% of what's being hosted by trying to clean up defunct projects. in a sea of 2k+ repos that doesn't seem like a huge win15:24
cdentyes, thus my earlier statement about the "the details of this issue"15:24
dhellmannfor example, mordred's goal of having "some" pagination API could go further and specify what type (or at least "rules" for picking, since apparently not all services can work with all implementations for some reason)15:24
ttxyes -- I totally think there is enough leadership issues in what is clearly our role to fix, that we don't need to claim ownership of territories taht are explicitly outside of our bounds15:24
dhellmannsaying "do something" feels like a good first step but it's not clear how many projects that actually affects15:25
persiaI think it is within the scope of the TC's remit to make statements to the wider community like "we've identified $problem, which we would like to see solved, but is outside the TC remit.  Some of us are planning to help $team accomplish this goal.  Wder participation would be welcome.".  This can safely be done without the TC, as a body, taking control of $problem.15:26
dhellmannpersia : I think cdent's point is that we do that more often than actually taking charge of the situation ourself.15:26
cdentI also think that we don't say "we've identified $problem" often enough, nor repeat frequently enough15:27
dhellmannand to some degree that's because 13 people only scale so far. but we could probably do more than we're doing.15:27
ttxdhellmann: I would say that overall we talk more about issues than actually do something to address the issues15:27
cdentregardless of who can solve it15:27
dhellmannttx, cdent : I agree15:28
persiadhellmann: The key is the second sentence :)  Also, I agree with cdent that the first sentence isn't used enough.15:28
fungiwe've suggested in the past that it's a more scalable use of our time to try and help identify champions to take on some of these tasks15:28
ttxwhich brings us back to goals15:29
ttxprivsep and basic-upgarde-support both need champions15:29
dhellmannfungi : sure. 13 people only scale so far.15:29
cdentand also to something we talked about at the last ptg: identify themes for problem solving areas, more conceptual than concrete15:29
ttxany volunteer or idea of one ?15:29
persiaOne of the interesting things about how Debian governance works is that the DPL is almost forcibly prohibited from doing anything at all, but has the authority to appoint anyone to do almost anything, which forces incumbents to delegate effectively.15:29
smcginnisremove-mox also could use a champion, though that can be me if no one else steps up.15:29
pabelangerI've often heard users says they which the TC did more, I get the impression they mean actually do the work (whatever the item that needs to be done). But I see that more as a communication issue to users maybe15:30
ttxpersia: that's a pretty optimistic way to look at DPL's authority, but that's a tangential topic :)15:30
dhellmanndo we have people familiar enough with privsep to take that one on? or should we spend this cycle recruiting help for it?15:30
ttxpabelanger: ++15:31
fungiis gus still around and working on privsep at this point?15:31
dhellmannwe should start making a list of all the things people say they want us to do15:31
dimsfungi : nope15:31
ttxdhellmann: I can help there, but would rather it be championed by someone who did one of the transitions already15:31
smcginnisfungi: I think he's off to k8s land now.15:31
cdentIn my experience what people are asking for when they want the TC to do things is that they want someone with what is perceived as authority to state, loudly, to all the right people "this matters"15:31
dhellmannfungi : he was in Sydney, but I think that's only because it was close to him anyway.15:31
pabelangersadly, I do not know privsep much15:31
ttxfungi: mikal is the new expert15:31
cdentthe bad half of that is that "this" is different for everyone15:31
smcginniscdent: ++15:31
dhellmannoh, or maybe that's where I saw him15:31
pabelangercdent: yes, I would agree15:32
fungicdent: a fundamental of government, i expect15:32
cdentI think we do a very bad job of doing that15:32
cdentAnd in fact, I think we actively avoid doing that for reasons I cannot discern15:32
ttxcdent: again, an example would help15:32
dhellmanndo you have specific things in mind that matter that aren't being talked about enough?15:33
persiacdent: I think that is precisely what folk asking the TC for action desire.  On the other hand, I think it is important that the TC only stare about some things, and help folk understand that they may not need authoritative action for other things.15:33
cdentas asserted before, talking may not be the thing, but I think in general we've given up on "nova cores" as a topic15:33
dhellmannI don't disagree, but my list is probably different from yours, cdent. :-)15:33
* persia has seen lots of things that could just be done waiting on "I want to talk to all the TC members first", rather than (properly) waiting on "I haven't gotten around to sending email to the mailing list yet"15:33
cdent(which is a challenging topic for me because most peope think I want to be a nova core, but I do not)15:33
dhellmannthat's definitely one we haven't resolved or talked about in a while15:34
cdentanother topic is enforcing architectural changes like DLM (which had a very lukewarm resolution)15:34
cdentor why some official projects are special in tempest but others are not15:34
ttxdhellmann and myself tried to make progress addressing it, most recently in Denver15:34
cdentdistributed lock/etcd15:34
dhellmannsorry, I'm acronym challenged15:35
cdentyes, individually we tend to have little conversations or make efforts15:35
ttx(the Nova situation)15:35
dimsso far no one has wanted to do a full dependency on etcd ...15:35
cdentbut as a governing body we do not priortize and publically make statements about $problem15:35
* TheJulia reads15:35
dhellmanncdent : the tempest thing is at the heart of
cdentand say "this needs to be fixed"15:35
cdentdhellmann: yes, and look how long it is taking us to do anything?15:35
ttxcdent: that's fair yes. I think the difficulty of doing it at the TC level was that most people were not interested in getting involved15:36
cdentbecause we are not, as a group, willing to assert that there is a problem15:36
fungifwiw, i think 521602 is a proxy for the battle to eliminate the perception of "core" services15:36
ttxhence the subgroup of interested/willing people meeting with Nova folks separately15:36
ttxsubgroup being dhellmann and myself in that precise case15:36
dhellmannfungi : yes, a battle we've been fighting for years.15:37
* flaper87 is quite late but made it15:37
dhellmannwe have a principle that says we provide a level playing field for companies, but not for teams15:37
fungithe heart of 521602 is the question of whether we as the tc can force projects to not have preferential relationships with some other projects and not all of them15:38
cmurphyif eliminating the perception of "core" services was the goal then wouldn't the effort be addressed at eliminating the defcore add-on program altogether?15:38
dhellmanncmurphy : should we treat teams of people differently because the software they produce is used differently?15:39
persiaI would assert that the answer to that question is "yes, the TC can force projects to behave in certain ways", especially in the case that the TC is advocating for all TC-governed projects to be treated similarly.  Whether the TC wishes to do so (and deal with the resulting social issues) is a different question.15:39
fungicmurphy: defcore (not named that any longer) is a slight wrinkle there since it's a board of directors initiative over which we hold only partial sway15:39
ttxcdent: the group is composed of multiple people, some of which (at least in the past) disagreeing on the need to fix the issue.15:40
dhellmannwe have, in the past, said that horizontal teams must support and provide tools for all teams, but they do not have to do the work for all of them15:40
dhellmannso the doc team had to make it possible to publish installation guides but didn't have to write them for all projects15:40
persiafungi: How does that work?  I would imagine the BoD only said "define things like that", and the TC properly governs the behaviour of the team engaged in implementation.15:40
dhellmannin this specific case, the QA team said it would take tests for all projects covered by the interop requirements15:40
ttxcdent: so I agree we seem to be unwilling to pass resolutions at 51% votes and say it's a TC decision. The rare cases where we did were not stellar successes15:40
cdentttx: agreed, but instead of making a decision one way or another, we choose to let it linger because we can't reach consensus. We may need to decide in a more concrete fashion.15:41
dhellmannas an exception to or extension of their policy of hosting tests for only the integrated release15:41
cdents/we choose/we sometimes choose/15:41
fungipersia: actually the tc gets to tell the board which services it can choose from, and then the board chooses a subset of those to cover with trademark programs and interoperability standards15:41
* ttx can't remember a 7 vs. 6 decision that wasn't a disaster15:41
persiafungi: That part makes sense.  Are the folk who implement systems to validate the board choices working on repositories under TC remit?15:42
dhellmannright, the board asked us to produce a list of "designated sections" of code, and we said we would only ever pick entire projects15:42
ttxcdent: that's why more recemtly we tried to have Zingerman-like consensus in decisions, but tha's not perfect either, results in linger like you point out15:43
fungipersia: yes, the team producing the test collection and reporting service are governed by the tc:
persiafungi: Hence my assertion that they should be subject to TC governance, rather than "partial sway" :)15:43
fungipersia: so we could in theory tell them to test different things than the interoperability standards the board defines, but that seems like a somewhat underhanded way to influence the process15:43
fungipersia: and the only real ultimatum we can provide is to remove their status as an official team if they don't want to play along15:44
persiafungi: Ah, so in this case the "preferential relationship" is related to the core remit of the project in question, as defined by the Board?15:44
dhellmannI'm confused about why you're bringing the board into this.15:45
EmilienMI missed all the discussion about goals, I was in meetings, I'll read scrollback15:45
smcginnisEmilienM: It may take a while. :)15:45
ttxcdent: some of it is also an efficiency optimization. We have a pile of things to address, so when one is hard / non-consensual / requires extra work we tend to move on to the next one15:46
ttxhuman nature15:46
EmilienMyeah the channel has been busy for 3 hours15:46
ttxI agree we need to fight that, and stating the problems is really the first step in not ignoring them15:47
cdentyeah, totally get that ttx, unfortunately the non-consensual things are the big deals. I'm not trying to suggest that we are slacking and avoiding easy work. If we were to do this stuff, it would be _hard_15:47
ttxAgreeing on solutions is difficult, but it feels like agreeing on problems would not be that gard15:47
ttxcdent: as often, we disagree at start but agree in the end15:48
cdentyeah, is good to talk things through, not leave it lie. And thanks.15:49
fungipersia: probably best to take a concrete example. the board interop working group has defined the "openstack powered platform" mark which requires a specific set of services and associated capabilities to be provided. the question then arises as to whether it's acceptable for a team to treat the set of services covered by that interop grouping differently from other services (in this case, keeping tests15:49
fungifor some services in-tree in tempest while telling projects who aren't subject to interop requirements that they need to implement all their tests in tempest plugins)15:49
ttxcdent: regarding architectural decisions though, I think we clearly stated the need. Defined a structure to work on it. Blessed that structure. But then nobody showed up15:50
ttxFor a full year.15:50
cdentindeed because we haven't address the underlying problems there15:51
ttxThe Arch WG died out of resources, because it was basically 1.5 person15:51
fungiat least one team who is required to keep their tests in a tempest plugin would rather see their tests in-tree, and since they're proposed to be covered by a new "add-on" interoperability standard, this may be the leverage they're looking for to make that happen15:51
cdentno one will show up to change architecture until they are convinced a) that nova can and will change, b) that they can't get time from the corporate sponsors15:51
cdentneither of these things are generally true for many people, except for "elites" like us who get a lot of leeway on what we do15:51
pabelangerfungi: which team is that?15:51
fungipabelanger: designate15:52
dhellmanncdent : which architectural issues are blocked on nova agreeing to change?15:52
cmurphyhas the qa team so far rejected adding designate tests to tempest?15:52
persiafungi: The concrete example helps, although I'm still not sure why it matters whether the tests are in-tree or in-plugins in terms of the total result as seen by the board (except as a matter of convenience for the folk defining the interop tests).  To put it another way, I think involving the fact that interop is board-mandated only confuses the underlying issue.15:52
cdentdhellmann: it's more of a perception thing, but during the arch-wg discussions one of the main things discussed was "extract nova-compute" to its own thing15:52
cdentand it died on the vine15:52
dhellmannok, sure15:52
dhellmannhow many other agents do we have on the compute node? could *those* form into 1 agent so we only have 2?15:53
cdentbtw: I dont want to reinforce the stereotype that the nova drivers are resistant to all this stuff. That's not the case. There simply isn't the time/energy/resources/headspace/etc15:53
dhellmannI stopped waiting for nova to set the precedent a long time ago when we started rolling out oslo libraries.15:53
fungipersia: as an example it's relevant to 521602, insofar as that the privileged group was defined outside of tc control, and a tc controlled team is perceived by at least some in the community to be providing preferential treatment to that group15:53
dhellmannThere's often more energy and willingness to change in other projects, where the work is smaller.15:54
* cdent nods15:54
cdentor at least more welcomed because of a general "room for change"15:55
dhellmannyeah, it's easier for lots of reasons, not all social15:55
fungicmurphy: i believe the qa team/tempest maintainers have said that moving interop-specific tests for designate into the tempest repository would be acceptable, but has not said that all of designate's tempest tests would be a candidate for that and that designate would still need to maintain those in a tempest plugin instead15:56
persiafungi: I'm increasingly of the opinion that this has become a tangent, but I think the same problem would apply (and should be treated about the same) if a team decided to treat other teams in a privileged way because of a list I made, rather than the board.  The TC has a clear remit to override me, whereas that may be complicated in the case of the board, but in *either* case, I suggest the TC should be able to be sensibly involved in the15:56
persiaimeplementation details, especially if they cause social issues within the openstack development community, so long as all teams goals are met (so refstack can have results that meet their stakeholder's needs).15:56
fungicmurphy: but it's a very lengthy lot of comments in that review, so it's not entirely clear if opinions have changed over the course of the discussion and to what extent15:57
dhellmannpersia : we have already said we would leave it up to teams to decide what work they will take on, as long as they provide tools and guidance to other teams. The QA team seems to be doing that in this case.15:58
fungipersia: sure. for my part, tc hat on opinion, i believe the tempest maintainers when they say that there are technical reasons why nova, cinder, keystone et al have their tempest tests in-tree and designate needs a tempest plugin, and that it's not a matter of them simply liking some projects better than others15:58
dhellmannfungi : it would be easier to tell if that was 3 patches instead of 1.15:59
dhellmannfwiw, we only ever asked the qa team to take the interop tests for projects, not their entire suite15:59
fungii also am uncertain of the extent to which forcing the qa team to change their policy on tempest test inclusion is worth it simply as an attempt to solve perceived preferential treatment as the cause for the resulting inequalities16:00
dhellmannthere's a question of fairness in how they've selected the set of projects for which they do take all of the tests, but that's separate from the interop test question16:00
persiaFor the avoidance of doubt, both the direction to the QA team and the QA team action seem reasonable to me.  My main point was only that I didn't think that board involvement changed the underlying jurisdiciton.16:01
dhellmannI'd like them to explain their criteria clearly and in a way that isn't based on the APIs used by tests16:01
fungie.g., the suggestion in there that all in-tree tempest tests which aren't interop-specific should be moved out of the tempest repo into plugins just so that the teams maintaining those services get to deal with the same issues as other teams with tempest plugins16:01
dhellmannhave we set up social or technical structures that make it harder for some teams to do their work than for others?16:03
fungipersia: the tangent of board involvement started as an answer to cmurphy's question as to whether the community should be looking to eliminate defcore add-on trademark programs as a means of eliminating the perception of a "core" set of services. i agree it was not germane to the jurisdiction question with regard to tc or qa policies on tempest plugins16:04
ttxEmilienM: regarding the goals the TL;DR is that we have two new candidates posted, would love to see privsep and minimal-upgrade-capabilities but those are missing a champion, so we should look for one16:04
ttxEmilienM: I guess we could post a "looking for champions" post, since goal champions is on our most-needed list16:06
ttxit is, after all, how we found the Queens champions16:06
fungithat seemed to work well this cycle, yes16:06
EmilienMyeah, it sounds like worth a try16:06
ttxby stating publicly how much that matters16:07
ttxEmilienM: you post it ?16:07
EmilienMI'll post it today16:07
ttxgreat, thanks16:07
* cdent winks at ttx16:07
* EmilienM continues to read the eternal scroll back16:07
smcginnisEmilienM: Please include the remove-mox goal as one of the things that is open for championing.16:08
cmurphyfungi: i didn't mean to suggest the community should be doing that, i just mean that if that was the goal then i would expect the teams wishing to be perceived as "core" would not be so happy being called an "add-on"16:08
flaper87smcginnis: I think it's there already16:08
ttxEmilienM: Like generally point to the backlog  as source of inspiration, saying we would love it if we could find champions for privsep and minimal-upgrade-capabilities, but it's ok if they push another one too :)16:08
EmilienMsmcginnis: ack16:08
ttxsmcginnis: argh was assuming you would driver it :)16:09
smcginnisttx: I certainly will, but I want to leave it open for someone non-TC to take on.16:09
fungicmurphy: right, just because you ask a question doesn't mean you're suggesting it should happen, but it still deserved answering all the same16:09
cmurphyfungi: gotcha16:10
fungiand i agree, teams concerned about this could go to the board instead of us in an attempt to solve that perception, if such was their goal16:11
* dhellmann needs to drop off to start his commute16:11
fungii also get the impression the tc, as steeped in bureaucracy as we probably are, is still easier to approach than the board since we take proposals from anyone at any time and discuss them, while getting the board's attention generally involves convincing the chair and getting onto a meeting agenda months in advance16:13
* cdent nods16:13
cmurphywell the interop wg should be approachable16:14
fungiso of the two, we could end up being the path of least resistance in many cases16:14
fungicmurphy: good point16:14
fungione would still likely need to work through them to get an alternative proposal before the board anyway16:15
persiaGiven the difficulty of getting direct board attention, perhaps it makes sense for the TC (and UC as peer) to more clearly offer to carry issues to the Board.  While TC/UC/Board meetings aren't constant, they are likely to be more often than the timeframe it might take many folk to get an item on the board agenda.16:16
*** eumel8 has quit IRC16:16
cdentpersia: I've always hoped that was part of the TC's job, but there doesn't seem to be consensus on that16:16
fungiyes, we likely aren't as clear as we should be in communicating our willingness to act as a conduit for bringing issues/concerns within the technical community before the board of directors16:17
fungimaybe in advance of the next joint leadership meeting, we could take a little time to discuss potential topics for teh agenda on the -dev ml?16:18
persiaMy experience with the UC is that they are often willing to carry items, but I'm not sure if that's because they are open or if because I'm me.  I don't recall having tried to take anything through the TC (not because I considered the process complicated, but because none of the issues I raised felt "TC" to me), so can't talk about the experience in raising something for escalation.16:18
fungiif memory serves, in the past that's mainly happened in tc meetings and on the tc ml16:18
fungibut i don't see an issue with broadening the call for agenda topics16:18
fungigranted, there are only a limited class of concerns worth bringing before the board, as their jurisdiction over technical matters is minimal/nonexistent16:20
cdentnearly ever technical issue founders on "who is going to do the work"16:20
fungiyep, and that is in theory something worth bringing before the board16:21
cdentwhat's missing is a path from either the board or the tc to the people who bring people for real16:21
fungigranted in the past that tactic hasn't achieved much16:21
persiaI don7t think "who does the work" should be brought to the board.  I've seen it happen a lot, but without much result.  I think "who does the work" needs to be brought to the contributing orgs (which list is loosely under board supervision. but independent of formal organisation membership).16:22
fungiand understandably, as the board members often lack sufficient leverage/power within their own organizations to make those concerns heard in any meaningful way16:22
persiaWhether the TC has a relationship with contributing orgs is a different question.16:23
fungiour obvious connection to contributing organizations is through existing contributors, and they often serve as admirable advocates for our cause to their employers16:24
fungii'll cite the generous donations of infrastructure we receive as a prime example16:24
fungithe contributions there, when i do hear the stories as to how they come about, almost always start with individual contributors speaking to their management about the project's needs16:25
cdentthat may be true in infra, but does not correspond with my experience as a developer devoted to upstream16:27
smcginnisWe do state for gold and platinum membership that there is an expectation of dedicating resources. I don't think we enforce that though.16:27
cdentgetting more upstream resources by talking to managers usually results in "yeah, that would be great wouldn't it"16:27
fungicdent: true, and also i think infrastructure donations are a little more liquid and easier to make happen than adding humans16:27
fungismcginnis: it's come up in board meetings at least half a dozen times that i remember, and pretty much always leads to no real change. usually comes across as one member company passive-aggressively accusing other member companies of not pulling their weight but nobody ever wants to go into specifics16:28
smcginnisfungi: Maybe we need to start naming names. :)16:29
cdentpresumably we have real numbers16:29
cdentwe don't need to single anyone out16:29
cdentwe can just produce numbers16:29
cdentit would be important to have a lower limit of contributions per individual per company16:29
cdentas low numbers are not consistent resources16:30
cdentand it is showing up regularly that can often be important16:30
fungiwell, we have real numbers which are easily gamed. this is why i'm intruiged by the new suggestion that member companies should start telling the stories of how they're furthering our community and what specific improvements they've driven16:30
cdentthat would certainly help16:30
smcginnisI like that idea too.16:31
*** rosmaita has joined #openstack-tc16:31
persiacdent: Depends on the managers.  I often find getting more upstream contributors by talking to managers involves exchange of currency.  In other cases, it just takes a review of the cost implications of maintaining a downstream branch.16:31
smcginnisNumbers don't matter. Impact is the important thing.16:31
fungilike, i'd love to hear the story about multi-attach volume support16:31
persiaAsking contributing orgs to document their contributions is an arrangement where gaming should be to the benefit of OpenStack.16:32
fungiwho pitched in on that? what was the driving factor behind the organizations whose employees pitched in?16:32
funginot only does it serve as a means for companies to brag about improvements they funded, but it gives us a better insight into what factors weighed into their decisions to get involved on it16:33
smcginnisTrue, that insight might be useful.16:34
ttxfungi: yes I noted that we should open up the "leadership" agenda on the ML rather than just edit the wiki and discuss it here16:34
fungithanks ttx!16:35
ttxalso we did collect snippets of "valuable contributions to the project" for the annual report, as suggested during the KubeCon meeting and discussed here16:36
ttxas an incentive to get valuable resources from employers16:36
ttxI'm co-authoring a blogpost with Caleb Miles from Google/Kubernetes on the importance of strategic contributions16:36
ttxthat's the in-progress actions to help in that area16:37
persiaNote that the funding organisation is not necessarily the contributing organisation.  One organisation with which I work funds a vendor to seven figures to make sure solutions to bugs found in the private cloud implemnentation are delivered upstream.  They may eventually contribute FTEs instead of money, but right now they have more money than FTEs.16:37
ttxNote that it comes with a pretty wide definition of strategic contribution. Includes for example sponsoring the PTG16:39
cdentthat seems completely valid to me16:40
persiaI don't have any figures, but my guess is that PTG sponsorships are on the same order of magnitude as an FTE (loosely averaging over global rate variances).16:42
*** cdent has quit IRC16:47
*** dtantsur is now known as dtantsur|afk16:47
*** cdent has joined #openstack-tc16:52
ttxsponsorship packages are $25K, so I'd argue much less than a FTE16:59
persiaDepends on locality :)  In some places, $25K is an above-average wage for this class of work.17:03
ttxGreat write-up, cmurphy !17:06
cmurphythanks ttx17:06
ttxOh async question to tc-members... do we want a room at the PTG ? If yes for how long ?17:14
ttxMy idea was to piggyback on reservable rooms during the week, and maybe book half a day on Friday afternoon17:15
smcginnisWe don't have any new project applications to go over this time.17:15
smcginnisMight be nice to have some time though.17:15
smcginnisEven at least an hour or two to actually spend some time face to face.17:15
TheJuliattx: I would be +1 to friday afternoon.17:16
ttxif we have another topic and find a godo time for it, we can easily book one of the extra space17:16
pabelangerare we still planning on meeting up first of the week? That was some feedback at summit, to see who is going where, etc?17:16
ttxso we'd only preschedule the Friday PM stuff17:16
fungiyeah, some organized face time (not just between us but for anyone in the community who wants to join in) would be helpful17:16
*** jpich has quit IRC17:17
ttxpabelanger: what do you mean by first of the week?17:17
pabelangerlet me find etherpad from feedback session in summit, but I believe one of the ideas was to make have a face to face at start of event, just to level set. Maybe see where people were going, and if members should sit in on specific things.  I'm not sure if that is something we also want to consider at PTG or just summit17:18
cdentI like the idea of a "level set", at both17:19
cdentnot sure of ease of timing17:19
ttxIf we end up doing a "level set" presentation on Monday lunch we'll have to prepare something in advance anyway17:20
pabelanger consider meeting earlier in the week for PTG and summit to establish shared goals, is what I was thinking about. But could be specific to forum17:20
ttxpabelanger: yeah I think that was slightly forum-specific, due to conflicts and all17:21
ttxmake sure all spots were covered ni a busy schedule17:21
ttxfor PTG we have more information in advance so the prep can be done before the event starts imho17:21
ttxalthough I'll be snowboarding the whole week before so could use last-minute prep :)17:22
EmilienMttx: +1 for having a room for maybe 2 or 3 hours17:41
EmilienMif we could avoid the Friday afternoon otherwise no big deal17:41
-openstackstatus- NOTICE: Due to an unexpected issue with zuulv3.o.o, we were not able to preserve running jobs for a restart. As a result, you'll need to recheck your previous patchsets17:48
*** cdent has quit IRC18:59
dhellmannttx: regarding space at the PTG, I'd like for us to set aside time on friday to talk even if we don't know about what yet. If we're scheduling it in advance I'd like to do it earlier in the day rather than at the end.19:00
dhellmannwe should try to include at least one of the unresolved issues that we discussed today, like the perception of unfair handling by some teams, challenges finding goal champions, what to do with the architecture wg, etc.19:03
dhellmanntbh, I don't think it's unreasonable for us to set aside the whole morning. we should be a team, just like the other teams.19:04
jrollit's also good to give folks that are less active on irc an opportunity to get involved on these conversations19:13
*** harlowja has joined #openstack-tc19:43
fungicmurphy: belated thumbs-up on the interop testing summary. very thorough and accurate20:39
* fungi just got caught up on the ml20:39
cmurphyfungi: :)20:46
fungialso you managed to phrase it in a less inflammatory manner than i could ever have hoped to do20:47
EmilienMsmcginnis: could you please propose remove-mox on ML and maybe look for a champion? I'm unsure about the work etc20:57
smcginnisEmilienM: Sure, will do.21:03
EmilienMsmcginnis: thanks!21:03
*** david-lyle has quit IRC21:03
*** david-lyle has joined #openstack-tc21:04
*** kumarmn has quit IRC21:11
openstackgerritDoug Hellmann proposed openstack/governance master: show deliverables in the order listed in the projects file
openstackgerritFrank Kloeker proposed openstack/governance master: I18n Extra-ATCs for Queens
*** kumarmn has joined #openstack-tc22:13
*** kumarmn has quit IRC22:30
*** hongbin has quit IRC23:53

Generated by 2.15.3 by Marius Gedminas - find it at!