| *** diablo_rojo has quit IRC | 00:05 | |
| *** diablo_rojo has joined #openstack-tc | 00:06 | |
| *** kumarmn has joined #openstack-tc | 01:34 | |
| *** kumarmn has quit IRC | 01:35 | |
| *** kumarmn has joined #openstack-tc | 02:02 | |
| *** kumarmn has quit IRC | 02:04 | |
| *** mriedem has quit IRC | 02:56 | |
| *** harlowja_ has quit IRC | 03:21 | |
| *** kumarmn has joined #openstack-tc | 03:28 | |
| *** kumarmn has quit IRC | 03:54 | |
| *** kumarmn has joined #openstack-tc | 04:03 | |
| *** kumarmn has quit IRC | 04:09 | |
| *** kumarmn has joined #openstack-tc | 04:09 | |
| *** kumarmn has quit IRC | 04:10 | |
| *** kumarmn has joined #openstack-tc | 04:11 | |
| *** kumarmn has quit IRC | 04:16 | |
| *** kumarmn has joined #openstack-tc | 04:28 | |
| *** rosmaita has quit IRC | 04:34 | |
| *** kumarmn has quit IRC | 04:38 | |
| *** kumarmn has joined #openstack-tc | 04:39 | |
| *** kumarmn has quit IRC | 04:44 | |
| *** harlowja has joined #openstack-tc | 05:29 | |
| *** gcb has quit IRC | 05:30 | |
| *** gcb has joined #openstack-tc | 05:31 | |
| *** liujiong has joined #openstack-tc | 06:09 | |
| *** liujiong has quit IRC | 06:28 | |
| *** liujiong has joined #openstack-tc | 06:33 | |
| *** harlowja has quit IRC | 06:47 | |
| *** dims_ has quit IRC | 07:21 | |
| *** dims has joined #openstack-tc | 07:25 | |
| *** kumarmn has joined #openstack-tc | 07:39 | |
| *** kumarmn has quit IRC | 07:44 | |
| ttx | smcginnis: I notice you're going through non-official projects and propose the inactive ones for retirement | 07:47 |
|---|---|---|
| ttx | fwiw it's something we have not really been paying much attention in the past as this is ungoverned territory | 07:48 |
| ttx | retirement there is pretty much an infra decision | 07:49 |
| *** jpich has joined #openstack-tc | 09:02 | |
| *** flaper87 has quit IRC | 09:17 | |
| *** flaper87 has joined #openstack-tc | 09:21 | |
| *** flaper87 has quit IRC | 09:21 | |
| *** flaper87 has joined #openstack-tc | 09:23 | |
| *** dtantsur|afk is now known as dtantsur | 09:38 | |
| *** liujiong has quit IRC | 10:23 | |
| *** cdent has joined #openstack-tc | 10:30 | |
| *** rosmaita has joined #openstack-tc | 10:32 | |
| dims | ttx : seen this? https://foss-backstage.de/call-papers | 11:24 |
| cdent | hmm, interesting | 11:32 |
| dims | cdent : y, short hop away for you both | 11:38 |
| *** kumarmn has joined #openstack-tc | 11:40 | |
| *** kumarmn has quit IRC | 11:45 | |
| *** cdent has quit IRC | 12:02 | |
| *** cdent has joined #openstack-tc | 12:16 | |
| *** rosmaita has quit IRC | 12:34 | |
| ttx | dims: thx for the pointer ! | 13:09 |
| smcginnis | ttx: 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 |
| smcginnis | cdent: 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 |
| cdent | yes | 13:32 |
| ttx | smcginnis: sure, it sounds like a good idea. I was just pointing out that the TC has no legitimacy ruling that corner | 13:33 |
| persia | I 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 |
| smcginnis | ttx: Oh, yep, I get that. | 13:33 |
| ttx | persia: exactly | 13:33 |
| smcginnis | persia: Can you elaborate on "dangerously irresponsible"? | 13:34 |
| ttx | I fear that sending "is ailuropoda still alive" questions on openstack-dev increases the confusion rather than removes it | 13:34 |
| ttx | I think it's a godo topic for the -infra list though :) | 13:34 |
| persia | smcginnis: 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 |
| cdent | that the TC has refused such responsibilty should maybe change? | 13:35 |
| smcginnis | cdent: ++ | 13:35 |
| ttx | cdent: well, no. That space is precisely defined as the space we are not governing | 13:36 |
| ttx | it's the only difference with the "official" space | 13:36 |
| cdent | Yeah, I know that's what we said, but I'm not sure it was the right thing to say | 13:36 |
| cdent | and I think we're foolish if we constrain ourselves to never changing | 13:36 |
| persia | So, "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 |
| ttx | cdent: you mean all projects we host should be official ? I proposed that a while ago and was not exactly supported | 13:37 |
| persia | cdent: 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 |
| smcginnis | Governed or not, I care about OpenStack and would like to see it not weighed down by entropy. | 13:37 |
| cdent | I'm not suggesting that that all projects be official, I simply support the assertion that entropy is a problem | 13:37 |
| ttx | good counterarguments include "projects need a space to start before thinking governance" and "it's a great space to learn our tooling" | 13:37 |
| smcginnis | The big tent introduced mass confusion, IMO, that I think we are still living with and would like to do something to decrease. | 13:37 |
| cdent | and we are in a place to know and do something about it | 13:37 |
| persia | smcginnis: 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 |
| smcginnis | persia: You state my intent better than I have. | 13:38 |
| ttx | I totally support infra cleaning up :) | 13:38 |
| persia | smcginnis: I'm glad to hear that: I feared we might disagree :() | 13:38 |
| persia | smcginnis: 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 |
| ttx | persia: that was not really in the cards | 13:39 |
| smcginnis | OK, 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 |
| persia | ttx: An effective charman with a clear vision is a treasure never to be undervalued | 13:40 |
| smcginnis | But I do not entirely agree this isn't something TC-associated folks shouldn't do. | 13:40 |
| persia | smcginnis: 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 |
| ttx | I 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 up | 13:40 |
| smcginnis | persia: Did I position it as a TC effort somewhere? | 13:41 |
| smcginnis | If so, it was not intentional. | 13:41 |
| *** rosmaita has joined #openstack-tc | 13: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 |
| persia | Apologies 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 |
| smcginnis | persia: Not at all, input is good. | 13:44 |
| smcginnis | I 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 |
| cdent | Personally I welcome any opportunity to clarify and/or question the roles of the TC | 13:45 |
| persia | Well, 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 |
| ttx | smcginnis: I did a review of the negative space back when I proposed to clean up, which you may find interesting | 13:47 |
| smcginnis | ttx: Yes, I think I would. | 13:47 |
| * ttx tries to find that etherpad again | 13:48 | |
| ttx | https://etherpad.openstack.org/p/negative-space-analysis | 13:48 |
| ttx | It was basically listing all repos that are not in governance | 13:49 |
| smcginnis | Looks a lot like the list I was compiling last night of the stale projects. | 13:49 |
| cdent | how are you defining "stale"? And presumably stale doesn't mean "dead" it means "candidate for finding out if dead"? | 13:49 |
| ttx | openstack/sticks-dashboard - Sticks Horizon Plugin -- 4 commits, last modified Aug 5, 2015 | 13:50 |
| smcginnis | cdent: Exactly. | 13:50 |
| ttx | That is pretty stale in my book :) | 13:50 |
| smcginnis | cdent: 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 |
| ttx | there are a bunch of one-commit things | 13:51 |
| smcginnis | Get the whole candidate list before doing one by one. | 13:51 |
| smcginnis | ttx: 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 |
| smcginnis | And then of course there were things like openstack/ailuropoda that were amusing. :) | 13:52 |
| ttx | smcginnis: 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 year | 13:52 |
| ttx | asked for help on processing it but didn't get much | 13:52 |
| smcginnis | ttx: 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 |
| ttx | smcginnis: please do whatever you want with it :) | 13:54 |
| dhellmann | I'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 |
| ttx | I just fear the info in it is outdated now | 13:54 |
| smcginnis | The ones that are not outdated may be telling. | 13:54 |
| smcginnis | dhellmann: ++ 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 school | 13:55 | |
| ttx | Last call for help (unanswered back then): http://lists.openstack.org/pipermail/openstack-dev/2017-June/119134.html | 13:57 |
| ttx | Original email starting this thread if you need a refresher: http://lists.openstack.org/pipermail/openstack-dev/2017-June/119043.html | 13:59 |
| *** rosmaita has quit IRC | 14:34 | |
| dhellmann | dims : foss backstage looks like it has the potential to be very interesting | 14:39 |
| dims | indeed dhellmann, i saw another one from linux foundation, but that seemed like invite-only - https://events.linuxfoundation.org/events/open-source-leadership-summit-2018/ | 14:41 |
| dims | see topics/presentation from 2017 | 14:41 |
| dhellmann | oh, I'd heard of that one but didn't realize it required an invitation | 14:41 |
| dims | dhellmann : i mean if you don't submit a proposal then you need an invite from what i can tell | 14:42 |
| dhellmann | ah | 14:42 |
| *** hongbin has joined #openstack-tc | 14:48 | |
| ttx | tc-members assemble | 15:00 |
| dhellmann | o/ | 15:00 |
| cmurphy | hello | 15:00 |
| smcginnis | o/ | 15:00 |
| cdent | hola | 15:00 |
| ttx | not much on my list for this hour, except continuing the discussion(s) we had on Tuesday | 15:01 |
| ttx | We talked goals, and looked for next steps for the few stuck proposals we have | 15:01 |
| pabelanger | present | 15:01 |
| * cmurphy drafting interop testing email | 15:02 | |
| ttx | Brainstorming Q goals is probably the most urgent | 15:02 |
| cmurphy | *R goals ? | 15:02 |
| ttx | err yes | 15:02 |
| ttx | R goals | 15:02 |
| ttx | Had a hard time getting to mikal on IRC, so sent email | 15:02 |
| ttx | looks like the nova-compute stuff is still WIP | 15:02 |
| *** mriedem has joined #openstack-tc | 15:02 | |
| ttx | (moving nova-compute to privsep) | 15:03 |
| * ttx looks up recent goal proposals | 15:03 | |
| persia | My 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 |
| ttx | I like the concept of requesting invites | 15:04 |
| persia | http://www.communityleadershipsummit.com/ is another one that some folk like, in a similar vein | 15:04 |
| fungi | oh, yes, it's office hour | 15:04 |
| ttx | yes the LF leadership summit is the Davos of open source | 15:04 |
| ttx | You can ask but you kinda expect to be invited without having to ask | 15:05 |
| ttx | It's shortly after PTG this year | 15:05 |
| * dhellmann mustn't know the right people | 15:05 | |
| ttx | dhellmann: it's not just you :) | 15:05 |
| persia | All 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 |
| smcginnis | I spot a hogepodge in that conference photo. | 15:06 |
| dhellmann | I think I'm more interested in going to a leadership conference that is more open | 15:06 |
| smcginnis | dhellmann: ++ | 15:06 |
| persia | CLS is very open, and convenient if you have other reasons to be in Portland the following week. | 15:07 |
| dhellmann | also that's not 1/2 way around the planet from a conference he'll be at the week before | 15:07 |
| persia | OLS is better titled "LF projects leadership summit". | 15:07 |
| ttx | yes, I've done CLS in the past, it's a pretty open setting | 15:07 |
| smcginnis | persia: Is there something the following week? | 15:07 |
| persia | smcginnis: OSCON | 15:07 |
| dhellmann | is CLS the one that Jono Bacon is involved with? | 15:07 |
| ttx | CLS = OSCON's community leadership summit | 15:07 |
| persia | dhellmann: Yes. | 15:07 |
| ttx | yes | 15:07 |
| smcginnis | Ah | 15:08 |
| dhellmann | ok, I think that's the one I was thinking of instead of the LF one | 15:08 |
| ttx | not really linked to OSCNO but traditionally organized at its margins | 15:08 |
| ttx | More grassroots, less thought leaders | 15:08 |
| smcginnis | It finally doesn't conflict with an OpenStack event. | 15:09 |
| ttx | so we have remove-mox and ensure-pagination-links up as goal candidates | 15:09 |
| dims | o/ | 15:09 |
| ttx | We dsicussed requiring basic cold upgrades capabilities as a good goal, but missing a champion | 15:10 |
| dhellmann | the remove-mox goal is good, but rewriting some of those test suites is going to be a lot of work | 15:10 |
| smcginnis | Privsep was another one I would like to see. | 15:10 |
| smcginnis | But also a lot of work. | 15:10 |
| ttx | smcginnis: not that much once Nova is covered | 15:10 |
| dhellmann | privsep feels like it has more user benefit | 15:10 |
| fungi | okay, 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 |
| dhellmann | ttx: do we really have any projects that can't be upgraded at all? | 15:10 |
| dhellmann | or are their tags just not in place? | 15:11 |
| ttx | dhellmann: it's more that testing is not in place imho | 15:11 |
| dhellmann | ah | 15:11 |
| persia | fungi: Yes, that would be the proposition. | 15:11 |
| ttx | they can, they just don't get on checking it | 15:11 |
| smcginnis | fungi: Is there a proposal to make everything we host official? | 15:11 |
| ttx | gate* | 15:11 |
| dhellmann | ok, then I support adding upgrade testing as a goal | 15:11 |
| ttx | dhellmann: I feel like it's mostly a QA effort rather than a feature effort | 15:11 |
| cdent | fungi: no one ever made that proposal, it was a misunderstanding | 15:11 |
| fungi | also 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 past | 15:11 |
| cdent | (at least not today) | 15:12 |
| dhellmann | ttx: sure. unless we find a bug. | 15:12 |
| ttx | dhellmann: I think it's gently raising the bar on what we expect from "an openstack project" | 15:12 |
| mgagne | as an op, I'm really looking forward for policy-in-code completion =) | 15:12 |
| cmurphy | :) | 15:12 |
| dims | have folks here heard of apache attic? https://attic.apache.org/ (to provide process and solutions to make it clear when an Apache project has reached its end of life..) | 15:13 |
| dhellmann | ttx: 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 |
| dhellmann | otherwise starting/adopting new projects is going to become impossible | 15:13 |
| dims | right dhellmann | 15:13 |
| fungi | cdent: 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 infrastructure | 15:14 |
| dhellmann | maybe that wouldn't be a bad thing to do anyway | 15:14 |
| smcginnis | I feel like I'm missing something. Where did we talk about raising the bar for projects? | 15:14 |
| ttx | dhellmann: you think requiring a grenade-like test is hard ? | 15:14 |
| dhellmann | ttx: I'm looking at the trend, not this specific change | 15:14 |
| cdent | fungi, no I was disputing that we should be responsible for cleaning up what's there | 15:14 |
| *** kumarmn has joined #openstack-tc | 15:14 | |
| ttx | smcginnis: saying all projects need to support upgrade | 15:14 |
| dims | smcginnis : i got that from the email thread i think | 15:14 |
| cdent | and asserting that in general we should take more responsibility, not less | 15:14 |
| dhellmann | ttx: but yeah, it's "one more thing" and it's not exactly trivial | 15:14 |
| ttx | smcginnis: part of the goal discussion, not the other oen | 15:15 |
| smcginnis | OK, good. :) | 15:15 |
| fungi | cdent: 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 tc | 15:15 |
| cdent | to me, that's a stretch | 15:15 |
| smcginnis | fungi: Or the TC are being good stewards. | 15:15 |
| cdent | smcginnis++ | 15:15 |
| fungi | i don't see where the division is, personally | 15:15 |
| cdent | stewardship of the dead | 15:15 |
| fungi | #define "dead" | 15:16 |
| dims | or we saddle infra for that responsibility? | 15:16 |
| ttx | I like to see it as an infra issue | 15:16 |
| persia | I think Infra does a good job with it today. | 15:16 |
| cdent | maybe we have a confused set of definitions of what "governed" means | 15:16 |
| smcginnis | I see a big gap between making sure things are cleaned up when no longer relevant vs "governing" those thigns. | 15:16 |
| ttx | since the maintenance of that space falls on their hands | 15:16 |
| fungi | as soon as the tc starts deciding what the criteria are for declaring unofficial projects "dead" it is governing them, like it or not | 15:16 |
| dhellmann | is it governing those projects, or the use of community resources? | 15:17 |
| smcginnis | dhellmann: That, in my opinion. | 15:17 |
| ttx | I don't think we should be taking "more responsibility" if that means making decisions further away from where the work is done. | 15:17 |
| smcginnis | And when there is no work being done? | 15:17 |
| dims | right fungi | 15:17 |
| fungi | also, 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 one | 15:17 |
| ttx | smcginnis: I would help within the infra team rather than wielding a big TC hammer | 15:18 |
| fungi | er, is now on the road | 15:18 |
| dhellmann | fungi : good point | 15:18 |
| smcginnis | I 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 |
| cdent | as far as I can tell the TC is stating that it doesn't want to have a hammer | 15:18 |
| fungi | so the openstack tc deciding whether the shared infrastructure should host a particular repository for katacontainers is likely a problem | 15:18 |
| ttx | cdent: no, I'm saying it's always been an infra task to curate that space, and I don't see why that should change | 15:19 |
| smcginnis | I don't see the TC involved in that. | 15:19 |
| dims | smcginnis : guess we have to point out what hat we are wearing in such emails | 15:19 |
| ttx | and I'm happy to see smcginnis tackle that issue, but I think that needs to be done with his infra hat on | 15:19 |
| cdent | I don't dispute that detail, ttx | 15:20 |
| ttx | (which I think was implied here but not clear to everyone) | 15:20 |
| dims | totally ttx | 15:20 |
| fungi | i'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 idea | 15:20 |
| fungi | simply underscoring why it's a bad idea | 15:20 |
| cdent | What 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 |
| smcginnis | If 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 |
| ttx | cdent: The trick here is in the "in OpenStack" part of the sentence | 15:21 |
| cdent | which sounds like lawyering to me | 15:21 |
| ttx | In that case it's really not "leadership void that I think exists in OpenStack" | 15:21 |
| cdent | and not of any help or use to the community | 15:21 |
| ttx | since it's precisely "leadership void that I think exists in what is not OpenStack" | 15:22 |
| fungi | yeah, 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 gain | 15:22 |
| dhellmann | cdent : 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 |
| cdent | dhellmann: give me a moment to think about it | 15:22 |
| johnthetubaguy | cdent: 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 |
| EmilienM | hello | 15:23 |
| cdent | johnthetubaguy: that's certainly as aspect of it | 15:23 |
| cdent | s/as/an/ | 15:23 |
| dhellmann | cdent : 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 |
| fungi | i 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 win | 15:24 |
| cdent | yes, thus my earlier statement about the "the details of this issue" | 15:24 |
| dhellmann | for 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 |
| ttx | yes -- 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 bounds | 15:24 |
| dhellmann | saying "do something" feels like a good first step but it's not clear how many projects that actually affects | 15:25 |
| persia | I 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 |
| dhellmann | persia : I think cdent's point is that we do that more often than actually taking charge of the situation ourself. | 15:26 |
| cdent | I also think that we don't say "we've identified $problem" often enough, nor repeat frequently enough | 15:27 |
| dhellmann | and to some degree that's because 13 people only scale so far. but we could probably do more than we're doing. | 15:27 |
| ttx | dhellmann: I would say that overall we talk more about issues than actually do something to address the issues | 15:27 |
| cdent | regardless of who can solve it | 15:27 |
| dhellmann | ttx, cdent : I agree | 15:28 |
| persia | dhellmann: The key is the second sentence :) Also, I agree with cdent that the first sentence isn't used enough. | 15:28 |
| fungi | we'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 tasks | 15:28 |
| ttx | which brings us back to goals | 15:29 |
| fungi | yup | 15:29 |
| ttx | privsep and basic-upgarde-support both need champions | 15:29 |
| dhellmann | fungi : sure. 13 people only scale so far. | 15:29 |
| cdent | and also to something we talked about at the last ptg: identify themes for problem solving areas, more conceptual than concrete | 15:29 |
| ttx | any volunteer or idea of one ? | 15:29 |
| persia | One 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 |
| smcginnis | remove-mox also could use a champion, though that can be me if no one else steps up. | 15:29 |
| pabelanger | I'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 maybe | 15:30 |
| ttx | persia: that's a pretty optimistic way to look at DPL's authority, but that's a tangential topic :) | 15:30 |
| dhellmann | do we have people familiar enough with privsep to take that one on? or should we spend this cycle recruiting help for it? | 15:30 |
| ttx | pabelanger: ++ | 15:31 |
| fungi | is gus still around and working on privsep at this point? | 15:31 |
| dhellmann | we should start making a list of all the things people say they want us to do | 15:31 |
| dims | fungi : nope | 15:31 |
| fungi | :( | 15:31 |
| ttx | dhellmann: I can help there, but would rather it be championed by someone who did one of the transitions already | 15:31 |
| smcginnis | fungi: I think he's off to k8s land now. | 15:31 |
| cdent | In 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 |
| dhellmann | fungi : he was in Sydney, but I think that's only because it was close to him anyway. | 15:31 |
| pabelanger | sadly, I do not know privsep much | 15:31 |
| ttx | fungi: mikal is the new expert | 15:31 |
| cdent | the bad half of that is that "this" is different for everyone | 15:31 |
| smcginnis | cdent: ++ | 15:31 |
| dhellmann | oh, or maybe that's where I saw him | 15:31 |
| pabelanger | cdent: yes, I would agree | 15:32 |
| fungi | cdent: a fundamental of government, i expect | 15:32 |
| cdent | I think we do a very bad job of doing that | 15:32 |
| cdent | And in fact, I think we actively avoid doing that for reasons I cannot discern | 15:32 |
| ttx | cdent: again, an example would help | 15:32 |
| dhellmann | do you have specific things in mind that matter that aren't being talked about enough? | 15:33 |
| persia | cdent: 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 |
| cdent | as asserted before, talking may not be the thing, but I think in general we've given up on "nova cores" as a topic | 15:33 |
| dhellmann | I 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 |
| dhellmann | that's definitely one we haven't resolved or talked about in a while | 15:34 |
| cdent | another topic is enforcing architectural changes like DLM (which had a very lukewarm resolution) | 15:34 |
| dhellmann | DLM? | 15:34 |
| cdent | or why some official projects are special in tempest but others are not | 15:34 |
| ttx | dhellmann and myself tried to make progress addressing it, most recently in Denver | 15:34 |
| cdent | distributed lock/etcd | 15:34 |
| dhellmann | ah | 15:35 |
| dhellmann | sorry, I'm acronym challenged | 15:35 |
| cdent | yes, individually we tend to have little conversations or make efforts | 15:35 |
| ttx | (the Nova situation) | 15:35 |
| dims | so far no one has wanted to do a full dependency on etcd ... | 15:35 |
| cdent | but as a governing body we do not priortize and publically make statements about $problem | 15:35 |
| * TheJulia reads | 15:35 | |
| dhellmann | cdent : the tempest thing is at the heart of https://review.openstack.org/#/c/521602/2 | 15:35 |
| cdent | and say "this needs to be fixed" | 15:35 |
| cdent | dhellmann: yes, and look how long it is taking us to do anything? | 15:35 |
| ttx | cdent: that's fair yes. I think the difficulty of doing it at the TC level was that most people were not interested in getting involved | 15:36 |
| cdent | because we are not, as a group, willing to assert that there is a problem | 15:36 |
| fungi | fwiw, i think 521602 is a proxy for the battle to eliminate the perception of "core" services | 15:36 |
| ttx | hence the subgroup of interested/willing people meeting with Nova folks separately | 15:36 |
| ttx | subgroup being dhellmann and myself in that precise case | 15:36 |
| dhellmann | fungi : yes, a battle we've been fighting for years. | 15:37 |
| * flaper87 is quite late but made it | 15:37 | |
| dhellmann | we have a principle that says we provide a level playing field for companies, but not for teams | 15:37 |
| fungi | the 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 them | 15:38 |
| cmurphy | if 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 |
| dhellmann | cmurphy : should we treat teams of people differently because the software they produce is used differently? | 15:39 |
| persia | I 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 |
| fungi | cmurphy: 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 sway | 15:39 |
| ttx | cdent: 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 |
| dhellmann | we 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 them | 15:40 |
| dhellmann | so the doc team had to make it possible to publish installation guides but didn't have to write them for all projects | 15:40 |
| persia | fungi: 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 |
| dhellmann | in this specific case, the QA team said it would take tests for all projects covered by the interop requirements | 15:40 |
| ttx | cdent: 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 successes | 15:40 |
| cdent | ttx: 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 |
| dhellmann | as an exception to or extension of their policy of hosting tests for only the integrated release | 15:41 |
| cdent | s/we choose/we sometimes choose/ | 15:41 |
| fungi | persia: 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 standards | 15:41 |
| * ttx can't remember a 7 vs. 6 decision that wasn't a disaster | 15:41 | |
| persia | fungi: That part makes sense. Are the folk who implement systems to validate the board choices working on repositories under TC remit? | 15:42 |
| dhellmann | right, the board asked us to produce a list of "designated sections" of code, and we said we would only ever pick entire projects | 15:42 |
| ttx | cdent: 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 out | 15:43 |
| fungi | persia: yes, the team producing the test collection and reporting service are governed by the tc: https://governance.openstack.org/tc/reference/projects/refstack.html | 15:43 |
| persia | fungi: Hence my assertion that they should be subject to TC governance, rather than "partial sway" :) | 15:43 |
| fungi | persia: 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 process | 15:43 |
| fungi | persia: and the only real ultimatum we can provide is to remove their status as an official team if they don't want to play along | 15:44 |
| persia | fungi: 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 |
| dhellmann | I'm confused about why you're bringing the board into this. | 15:45 |
| EmilienM | I missed all the discussion about goals, I was in meetings, I'll read scrollback | 15:45 |
| smcginnis | EmilienM: It may take a while. :) | 15:45 |
| dims | hehe | 15:46 |
| ttx | cdent: 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 one | 15:46 |
| ttx | human nature | 15:46 |
| EmilienM | yeah the channel has been busy for 3 hours | 15:46 |
| ttx | I agree we need to fight that, and stating the problems is really the first step in not ignoring them | 15:47 |
| cdent | yeah, 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 |
| ttx | Agreeing on solutions is difficult, but it feels like agreeing on problems would not be that gard | 15:47 |
| ttx | hard* | 15:47 |
| ttx | cdent: as often, we disagree at start but agree in the end | 15:48 |
| cdent | yeah, is good to talk things through, not leave it lie. And thanks. | 15:49 |
| fungi | persia: 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 tests | 15:49 |
| fungi | for 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 |
| ttx | cdent: 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 up | 15:50 |
| ttx | For a full year. | 15:50 |
| cdent | indeed because we haven't address the underlying problems there | 15:51 |
| ttx | The Arch WG died out of resources, because it was basically 1.5 person | 15:51 |
| fungi | at 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 happen | 15:51 |
| cdent | no 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 sponsors | 15:51 |
| cdent | neither of these things are generally true for many people, except for "elites" like us who get a lot of leeway on what we do | 15:51 |
| pabelanger | fungi: which team is that? | 15:51 |
| fungi | pabelanger: designate | 15:52 |
| dhellmann | cdent : which architectural issues are blocked on nova agreeing to change? | 15:52 |
| cmurphy | has the qa team so far rejected adding designate tests to tempest? | 15:52 |
| persia | fungi: 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 |
| cdent | dhellmann: 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 thing | 15:52 |
| cdent | and it died on the vine | 15:52 |
| dhellmann | ok, sure | 15:52 |
| dhellmann | how many other agents do we have on the compute node? could *those* form into 1 agent so we only have 2? | 15:53 |
| cdent | btw: 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/etc | 15:53 |
| dhellmann | I stopped waiting for nova to set the precedent a long time ago when we started rolling out oslo libraries. | 15:53 |
| fungi | persia: 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 group | 15:53 |
| dhellmann | There's often more energy and willingness to change in other projects, where the work is smaller. | 15:54 |
| * cdent nods | 15:54 | |
| cdent | or at least more welcomed because of a general "room for change" | 15:55 |
| dhellmann | yeah, it's easier for lots of reasons, not all social | 15:55 |
| fungi | cmurphy: 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 instead | 15:56 |
| persia | fungi: 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 the | 15:56 |
| persia | imeplementation 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 |
| fungi | cmurphy: 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 extent | 15:57 |
| dhellmann | persia : 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 |
| fungi | persia: 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 others | 15:58 |
| dhellmann | fungi : it would be easier to tell if that was 3 patches instead of 1. | 15:59 |
| fungi | yeah | 15:59 |
| dhellmann | fwiw, we only ever asked the qa team to take the interop tests for projects, not their entire suite | 15:59 |
| fungi | i 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 inequalities | 16:00 |
| dhellmann | there'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 question | 16:00 |
| persia | For 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 |
| dhellmann | I'd like them to explain their criteria clearly and in a way that isn't based on the APIs used by tests | 16:01 |
| fungi | e.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 plugins | 16:01 |
| dhellmann | have we set up social or technical structures that make it harder for some teams to do their work than for others? | 16:03 |
| fungi | persia: 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 plugins | 16:04 |
| ttx | EmilienM: 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 one | 16:04 |
| ttx | EmilienM: I guess we could post a "looking for champions" post, since goal champions is on our most-needed list | 16:06 |
| smcginnis | ++ | 16:06 |
| ttx | it is, after all, how we found the Queens champions | 16:06 |
| fungi | that seemed to work well this cycle, yes | 16:06 |
| EmilienM | yeah, it sounds like worth a try | 16:06 |
| ttx | by stating publicly how much that matters | 16:07 |
| ttx | EmilienM: you post it ? | 16:07 |
| EmilienM | I'll post it today | 16:07 |
| ttx | great, thanks | 16:07 |
| * cdent winks at ttx | 16:07 | |
| * EmilienM continues to read the eternal scroll back | 16:07 | |
| smcginnis | EmilienM: Please include the remove-mox goal as one of the things that is open for championing. | 16:08 |
| cmurphy | fungi: 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 |
| flaper87 | smcginnis: I think it's there already | 16:08 |
| ttx | EmilienM: 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 |
| EmilienM | smcginnis: ack | 16:08 |
| ttx | smcginnis: argh was assuming you would driver it :) | 16:09 |
| ttx | drive* | 16:09 |
| smcginnis | ttx: I certainly will, but I want to leave it open for someone non-TC to take on. | 16:09 |
| fungi | cmurphy: right, just because you ask a question doesn't mean you're suggesting it should happen, but it still deserved answering all the same | 16:09 |
| ttx | ack | 16:09 |
| cmurphy | fungi: gotcha | 16:10 |
| fungi | and 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 goal | 16:11 |
| * dhellmann needs to drop off to start his commute | 16:11 | |
| fungi | i 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 advance | 16:13 |
| * cdent nods | 16:13 | |
| cmurphy | well the interop wg should be approachable | 16:14 |
| fungi | so of the two, we could end up being the path of least resistance in many cases | 16:14 |
| fungi | cmurphy: good point | 16:14 |
| fungi | one would still likely need to work through them to get an alternative proposal before the board anyway | 16:15 |
| persia | Given 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 IRC | 16:16 | |
| cdent | persia: I've always hoped that was part of the TC's job, but there doesn't seem to be consensus on that | 16:16 |
| fungi | yes, 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 directors | 16:17 |
| fungi | maybe 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 |
| persia | My 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 |
| fungi | if memory serves, in the past that's mainly happened in tc meetings and on the tc ml | 16:18 |
| fungi | but i don't see an issue with broadening the call for agenda topics | 16:18 |
| fungi | granted, there are only a limited class of concerns worth bringing before the board, as their jurisdiction over technical matters is minimal/nonexistent | 16:20 |
| cdent | nearly ever technical issue founders on "who is going to do the work" | 16:20 |
| fungi | yep, and that is in theory something worth bringing before the board | 16:21 |
| cdent | what's missing is a path from either the board or the tc to the people who bring people for real | 16:21 |
| fungi | granted in the past that tactic hasn't achieved much | 16:21 |
| cdent | jinx-ish | 16:21 |
| fungi | yeah | 16:21 |
| fungi | exactly | 16:21 |
| persia | I 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 |
| fungi | and understandably, as the board members often lack sufficient leverage/power within their own organizations to make those concerns heard in any meaningful way | 16:22 |
| persia | Whether the TC has a relationship with contributing orgs is a different question. | 16:23 |
| fungi | our obvious connection to contributing organizations is through existing contributors, and they often serve as admirable advocates for our cause to their employers | 16:24 |
| fungi | i'll cite the generous donations of infrastructure we receive as a prime example | 16:24 |
| fungi | the 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 needs | 16:25 |
| cdent | that may be true in infra, but does not correspond with my experience as a developer devoted to upstream | 16:27 |
| smcginnis | We 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 |
| cdent | getting more upstream resources by talking to managers usually results in "yeah, that would be great wouldn't it" | 16:27 |
| fungi | cdent: true, and also i think infrastructure donations are a little more liquid and easier to make happen than adding humans | 16:27 |
| fungi | smcginnis: 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 specifics | 16:28 |
| smcginnis | fungi: Maybe we need to start naming names. :) | 16:29 |
| cdent | presumably we have real numbers | 16:29 |
| cdent | we don't need to single anyone out | 16:29 |
| cdent | we can just produce numbers | 16:29 |
| cdent | it would be important to have a lower limit of contributions per individual per company | 16:29 |
| cdent | as low numbers are not consistent resources | 16:30 |
| cdent | and it is showing up regularly that can often be important | 16:30 |
| fungi | well, 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 driven | 16:30 |
| cdent | that would certainly help | 16:30 |
| smcginnis | I like that idea too. | 16:31 |
| *** rosmaita has joined #openstack-tc | 16:31 | |
| persia | cdent: 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 |
| smcginnis | Numbers don't matter. Impact is the important thing. | 16:31 |
| fungi | like, i'd love to hear the story about multi-attach volume support | 16:31 |
| persia | Asking contributing orgs to document their contributions is an arrangement where gaming should be to the benefit of OpenStack. | 16:32 |
| fungi | who pitched in on that? what was the driving factor behind the organizations whose employees pitched in? | 16:32 |
| fungi | not 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 it | 16:33 |
| smcginnis | True, that insight might be useful. | 16:34 |
| ttx | fungi: yes I noted that we should open up the "leadership" agenda on the ML rather than just edit the wiki and discuss it here | 16:34 |
| fungi | thanks ttx! | 16:35 |
| ttx | also we did collect snippets of "valuable contributions to the project" for the annual report, as suggested during the KubeCon meeting and discussed here | 16:36 |
| ttx | as an incentive to get valuable resources from employers | 16:36 |
| ttx | I'm co-authoring a blogpost with Caleb Miles from Google/Kubernetes on the importance of strategic contributions | 16:36 |
| ttx | that's the in-progress actions to help in that area | 16:37 |
| persia | Note 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 |
| ttx | Note that it comes with a pretty wide definition of strategic contribution. Includes for example sponsoring the PTG | 16:39 |
| cdent | that seems completely valid to me | 16:40 |
| persia | Indeed. | 16:40 |
| persia | I 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 IRC | 16:47 | |
| *** dtantsur is now known as dtantsur|afk | 16:47 | |
| *** cdent has joined #openstack-tc | 16:52 | |
| ttx | sponsorship packages are $25K, so I'd argue much less than a FTE | 16:59 |
| ttx | https://www.openstack.org/ptg#tab_sponsor | 17:00 |
| persia | Depends on locality :) In some places, $25K is an above-average wage for this class of work. | 17:03 |
| ttx | Great write-up, cmurphy ! | 17:06 |
| cmurphy | thanks ttx | 17:06 |
| ttx | Oh async question to tc-members... do we want a room at the PTG ? If yes for how long ? | 17:14 |
| ttx | My idea was to piggyback on reservable rooms during the week, and maybe book half a day on Friday afternoon | 17:15 |
| smcginnis | We don't have any new project applications to go over this time. | 17:15 |
| smcginnis | Might be nice to have some time though. | 17:15 |
| smcginnis | Even at least an hour or two to actually spend some time face to face. | 17:15 |
| TheJulia | ttx: I would be +1 to friday afternoon. | 17:16 |
| ttx | if we have another topic and find a godo time for it, we can easily book one of the extra space | 17:16 |
| ttx | good* | 17:16 |
| pabelanger | are 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 |
| ttx | so we'd only preschedule the Friday PM stuff | 17:16 |
| fungi | yeah, some organized face time (not just between us but for anyone in the community who wants to join in) would be helpful | 17:16 |
| *** jpich has quit IRC | 17:17 | |
| ttx | pabelanger: what do you mean by first of the week? | 17:17 |
| pabelanger | let 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 summit | 17:18 |
| cdent | I like the idea of a "level set", at both | 17:19 |
| cdent | not sure of ease of timing | 17:19 |
| ttx | If we end up doing a "level set" presentation on Monday lunch we'll have to prepare something in advance anyway | 17:20 |
| pabelanger | https://etherpad.openstack.org/p/SYD-tc-office-hour 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 forum | 17:20 |
| ttx | pabelanger: yeah I think that was slightly forum-specific, due to conflicts and all | 17:21 |
| ttx | make sure all spots were covered ni a busy schedule | 17:21 |
| pabelanger | sure | 17:21 |
| ttx | for PTG we have more information in advance so the prep can be done before the event starts imho | 17:21 |
| ttx | although I'll be snowboarding the whole week before so could use last-minute prep :) | 17:22 |
| EmilienM | ttx: +1 for having a room for maybe 2 or 3 hours | 17:41 |
| EmilienM | if we could avoid the Friday afternoon otherwise no big deal | 17: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 patchsets | 17:48 | |
| *** cdent has quit IRC | 18:59 | |
| dhellmann | ttx: 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 |
| dhellmann | we 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 |
| dhellmann | tbh, 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 |
| jroll | ++ | 19:12 |
| jroll | it's also good to give folks that are less active on irc an opportunity to get involved on these conversations | 19:13 |
| *** harlowja has joined #openstack-tc | 19:43 | |
| fungi | cmurphy: belated thumbs-up on the interop testing summary. very thorough and accurate | 20:39 |
| * fungi just got caught up on the ml | 20:39 | |
| cmurphy | fungi: :) | 20:46 |
| fungi | also you managed to phrase it in a less inflammatory manner than i could ever have hoped to do | 20:47 |
| cmurphy | haha | 20:50 |
| EmilienM | smcginnis: could you please propose remove-mox on ML and maybe look for a champion? I'm unsure about the work etc | 20:57 |
| smcginnis | EmilienM: Sure, will do. | 21:03 |
| EmilienM | smcginnis: thanks! | 21:03 |
| *** david-lyle has quit IRC | 21:03 | |
| *** david-lyle has joined #openstack-tc | 21:04 | |
| *** kumarmn has quit IRC | 21:11 | |
| openstackgerrit | Doug Hellmann proposed openstack/governance master: show deliverables in the order listed in the projects file https://review.openstack.org/532977 | 21:33 |
| openstackgerrit | Frank Kloeker proposed openstack/governance master: I18n Extra-ATCs for Queens https://review.openstack.org/532982 | 21:44 |
| *** kumarmn has joined #openstack-tc | 22:13 | |
| *** kumarmn has quit IRC | 22:30 | |
| *** hongbin has quit IRC | 23:53 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!