| *** zaneb has quit IRC | 00:08 | |
| *** lbragstad has joined #openstack-tc | 00:53 | |
| openstackgerrit | gengchc2 proposed openstack/governance master: Adding Dariusz Krol candidacy for Trove PTL https://review.openstack.org/588510 | 00:57 |
|---|---|---|
| *** annabelleB has joined #openstack-tc | 01:01 | |
| *** annabelleB has quit IRC | 01:02 | |
| *** annabelleB has joined #openstack-tc | 01:02 | |
| *** annabelleB has quit IRC | 01:03 | |
| *** lbragstad has quit IRC | 01:05 | |
| *** annabelleB has joined #openstack-tc | 01:07 | |
| *** gagehugo_ has quit IRC | 01:07 | |
| *** gagehugo has joined #openstack-tc | 01:22 | |
| *** eumel8 has quit IRC | 01:24 | |
| *** mriedem has quit IRC | 02:08 | |
| openstackgerrit | gengchc2 proposed openstack/governance master: Adding Changcai Geng candidacy for Freezer PTL https://review.openstack.org/590071 | 02:15 |
| *** dklyle has joined #openstack-tc | 02:46 | |
| *** annabelleB has quit IRC | 03:03 | |
| *** rosmaita has quit IRC | 03:04 | |
| openstackgerrit | baisen proposed openstack/governance master: add personal info to tricircle https://review.openstack.org/590082 | 03:13 |
| *** dklyle has quit IRC | 03:42 | |
| *** e0ne has joined #openstack-tc | 04:11 | |
| *** e0ne has quit IRC | 04:24 | |
| *** ricolin has joined #openstack-tc | 04:28 | |
| *** eumel8 has joined #openstack-tc | 05:36 | |
| *** evrardjp has joined #openstack-tc | 06:55 | |
| *** tosky has joined #openstack-tc | 07:52 | |
| openstackgerrit | Chandan Kumar proposed openstack/governance master: Move refstack-client, refstack and python-tempestconf to interop WG https://review.openstack.org/590179 | 08:00 |
| openstackgerrit | Luka Peschke proposed openstack/governance master: Updating CloudKitty PTL information https://review.openstack.org/590180 | 08:00 |
| ttx | yes, it might be the shock it needed to be revived. I wish the previous PTL would have sounded the alarm publicly rather than progressively go dark, but it's hard to blame him as that was volunteered time | 08:03 |
| ttx | It feels like we could have handled a Trove-like transition there without skipping a release | 08:04 |
| *** jpich has joined #openstack-tc | 08:19 | |
| *** dtantsur|afk is now known as dtantsur | 08:33 | |
| *** cdent has joined #openstack-tc | 09:08 | |
| *** ricolin has quit IRC | 09:26 | |
| *** dpl has joined #openstack-tc | 11:58 | |
| *** rosmaita has joined #openstack-tc | 12:32 | |
| TheJulia | I think perceptions change and around the election does really cause people to step back and ponder... ponder if they've served that project and group of people well. | 12:36 |
| TheJulia | it is easy for people to withdraw at that point, which is the exact opposite of what projects need, but we are all human | 12:36 |
| smcginnis | Hopefully this is something that our health checks will help avoid in the future. | 12:39 |
| smcginnis | Or at least, allow us to react a little sooner. | 12:39 |
| *** edmondsw has joined #openstack-tc | 12:45 | |
| *** lbragstad has joined #openstack-tc | 12:46 | |
| *** ianychoi has quit IRC | 12:49 | |
| mugsie | I think there is also the worry that if you raise the flag, no one will answer, and the project will end sooner than if you try and run a project in evenings and weekends | 12:49 |
| mugsie | the lure of "I can definitely deal with this stuff this weekend" is hard to break | 12:49 |
| smcginnis | That is true. | 12:50 |
| cdent | I have very mixed feelings about loyalty to corporate open source | 12:58 |
| persia | I have very mixed feelings about categorising projects as "corporate" and "non-corporate". | 12:59 |
| mugsie | Well, it is usually loyalty (or just pride / a sense of ownership) for something you built | 12:59 |
| cdent | persia: it's like I'm laying out bait for you ;) | 13:00 |
| cdent | persia: but yes, my mixed feelings are to do with the categorising | 13:00 |
| TheJulia | smcginnis: I doubt it, because we can only look at trends and take the PTL's perspective, and things can change massively in a very short time. | 13:01 |
| cdent | (in part) | 13:01 |
| TheJulia | smcginnis: well, react sooner, I agree it should help | 13:01 |
| mugsie | e.g. Designate was started in a company I help found, by one of my co-founders. We then went to work for $PublicCloud to bring it forward, and then brought it into the private cloud version. We all kept working on it long after it was our dayjob | 13:01 |
| cdent | mugsie: yes, I agree with all that. I've stuck with placement through two employers now, and gabbi through three. But I think it is also fair to be angry with corporations that say they are supporting this stuff, but aren't, not really. | 13:03 |
| mugsie | cdent: definitely | 13:03 |
| cdent | They make _billions_ of dollars off this stuff. | 13:04 |
| TheJulia | is the problem a value perception issue? | 13:04 |
| persia | When folk's roles/funding sources change, the model I've seen work best is transparency. Someone saying "I no longer feel I have as much time for foo as I used to have: is anyone else willng to help?". | 13:04 |
| persia | No reason to stop work just because it isn't 100% of one's dayjob, but that should be a personal interest / future career / etc. decision, not just blind expectation. | 13:05 |
| persia | (same applies for folks who encounter personal issues that block time, even with the same funding situation) | 13:05 |
| TheJulia | persia: I concur, we just need to remember that is the context of those people and that we can't expect the same level of interaction or commitment. | 13:06 |
| mugsie | persia: There is a talk from boston where me and the PTL at the time both stood on stage and said that, and got nothing from anyone. There was even distros in the room, who started asking for features, and who pinged me for help with their internal deploy tooling that to this day have not contributed to us | 13:07 |
| persia | Yes, and to make clear to people that if their available time changes (for any reason), they are encouraged to report this to the wider project and ask for help (rather than waiting for the cycle to end, etc.). | 13:07 |
| persia | mugsie: Yep. That happens. Especially on stage: it is rare that the people who are capable of making commitments are in those rooms (they have meetings in private rooms at the same time). | 13:08 |
| mugsie | all that did was kick off a rumour mill that designate was dead, and there was no point in doing anything with it | 13:08 |
| persia | mugsie: Would a framework to report it that was explicitly constructed to indicate that the project isn't dead have helped avoid starting that rumour? | 13:08 |
| cdent | mugsie: yes, simply asking hasn't proven effective (whether in front rooms or back rooms). I think not doing things we don't have time for is one of the remaining strategies | 13:08 |
| mugsie | Oh, I am aware - but the raising of the issue nearly killed the project | 13:09 |
| cdent | when someone asks for A, ask them which B they don't want. | 13:09 |
| persia | I've seen asking work in back rooms. Key is who is asking and for what. Asking generically for "help with foo" doesn't tend to be interesting. | 13:09 |
| cdent | and if no one asks for A, don't do. Do what's needed instead. | 13:09 |
| mugsie | yeah, we had a whole cycle where our major feature was "we fixed the gates" | 13:10 |
| evrardjp | I think that's a reasonable goal to keep the lights on | 13:13 |
| mugsie | evrardjp: yeah, I thought so :) | 13:14 |
| evrardjp | Also I have a fatalistic view of software: if there is no-one willing to step in to work on it, maybe it doesn't fill enough interest/use cases and must die? (Not talking about a project particularily here, just saying sometimes it's not worth the effort) | 13:15 |
| evrardjp | in other words: times change | 13:15 |
| persia | evrardjp: I've seen that work *very* well in other contexts. The usual results are a) a fork on different infra (sometimes for trust reasons) and b) someone stepping up and taking over if they have a need for it to be maintained. | 13:16 |
| mugsie | evrardjp: yeap, that is usually true. | 13:16 |
| persia | There are lots of companies in the business of selling warrants for open source software. If they have warranted a feature, there are almost no limits to their need to be able to effect change for the term of the warrant. | 13:17 |
| evrardjp | I don't disagree : ) | 13:18 |
| mugsie | It is just annoying to hear a vendors PS team did a few one off bespoke installs of your software for their customers, but they haven't done anything for the project or integrated it into the installer, or have integrated it into the installer, and don't contribute back at all | 13:18 |
| mordred | ++ | 13:19 |
| mugsie | to be fair, one of the vendors have made an effort to put people on the project recently and add it to the installer | 13:20 |
| evrardjp | mugsie: that's sad indeed. But I consider if they install it and report bugs, even if they don't fix it, they are still positive in the balance. But I guess you're talking about an experience that's not so positive. | 13:20 |
| persia | mugsie: One of the big challenges for communities ike ours is defining the edges. If we make it trivial enough to join that those PS people find it easier to work upstream than to carry local patches/fixes, then we lose the ability to have an "us" that is doing it "right". If we have any barrier that lets those PS folk be defined as "them", then they have no incentive to put in the time to be part of "us". | 13:20 |
| persia | One project in which I was involved in the past took an interesting view towards this: they blindly applied every patch from anyone who would provide one, and volunteers focused on making (even terrible) patches for every bug, all based off someone else's work. | 13:21 |
| persia | This became immensely popular, even though it was demonstrably worse than the source from which it forked. | 13:22 |
| persia | Making it good ended up killing a lot of the popularity. | 13:22 |
| persia | So this story doesn't really have a moral, or provide an answer. | 13:22 |
| mugsie | persia: the PS people have been great, and pushed back docs and info. the vendor product team didn't do any of that until recently, dispite quite a few of their large customers asking for it | 13:22 |
| mordred | even if we made is simple for people to join, I think an issue we've seen in many contexts is that people might have time to report the bug or even submit a patch the first time, but they don't have time to follow through on review comments and whatnot | 13:22 |
| evrardjp | persia: interesting | 13:22 |
| mordred | which is the flip-side of persia's story ... we ignore patches from people who don't follow up on them, even if the patches are good | 13:23 |
| persia | mordred: Yep. We define an "us" based on a level of interaction. We're happy to provide training for folk that demonstrate a willingness to interact that much. We exclude the rest. | 13:23 |
| mordred | yup | 13:23 |
| *** mriedem has joined #openstack-tc | 13:24 | |
| scas | i've started engaging, for better or worse, because the rumor mill started about chef openstack being dead. it was a bit disheartening to read on the ml that, but it also showed me i was too heads-down for the project's well-being. continuity has been on my mind for more than a cycle or two | 13:24 |
| mugsie | a vendor made the mistake of telling a customer the project was dead, when the customer had been talking to the upstream team for a while | 13:24 |
| mordred | I think in the early hype days there were reasons in which that was acutally a useful stance - but today we're in a position where we haven't developed "janitors" who will grab those sorts of things and follow through on them | 13:24 |
| evrardjp | mordred: that sounds time expensive | 13:25 |
| evrardjp | I'd rather distribute so that everyone becomes a "janitor" | 13:25 |
| mordred | yah. that too | 13:25 |
| evrardjp | or that there is none needed | 13:25 |
| persia | I think distribution should be based on incentives, rather than one size fits all. | 13:25 |
| evrardjp | (but that's dreaming) | 13:25 |
| mugsie | mordred: yeah, that may be a good way forward, and something I know we have talked about in the past - talking over patches, or merging with followups | 13:26 |
| evrardjp | persia: in case of non merged code that was proposed, the incentive should be clear: "you don't have to carry that patch downstream if we merge it". With the policy on reviews in (anti nitpicking), I don't see any barrier anymore | 13:27 |
| persia | For example, if some org wants feature foo, it makes sense to fund someone to do a feature, and that person has little incentive to be a janitor. Conversely, if some org has sold a support contract, warrant, or similar, it makes sense for that org to fund a janitor (or face potentially uncontrolled liability, which is usually inrteresting to the risk management department). | 13:27 |
| evrardjp | if there ever was a barrier | 13:27 |
| mordred | persia: yes | 13:27 |
| persia | evrardjp: So if I randomly add a patch to a bug and then go do something else for six months, the patch will be applied? | 13:27 |
| mordred | persia: one of our problems thus far, I believe, is that we've not done a great job in communicating to people about funding janitors | 13:27 |
| mordred | people get that they need to fund people to work on features | 13:27 |
| persia | Remember, I don't care about the customer situation again until the next release, and even then, I probably don't have forward confirmation as to whether or not I'll need to port the patches. | 13:28 |
| evrardjp | persia: that's not what I meant -- the incentive in the effort of merging in the first place is the reduced cost on the long run of carrying a fork | 13:28 |
| mugsie | persia: the problem is that the janitor role is carried by a few people, and orgs are happy to have a janitor assigned for 6 months, which is actually more work for the project than they get back | 13:28 |
| scas | i sometimes wonder what would have happened if peak openstack had taken chef down with it, had i not been stubborn enough to scratch my own itches | 13:28 |
| *** zaneb has joined #openstack-tc | 13:28 | |
| scas | deployment efforts are usually multi-year affairs, so long as they don't cause too much pain | 13:28 |
| persia | mordred: Understood. I'm happy to sit with folk who sell the products that need that support, if you have candidate orgs. I can also refer some peers. I don't know of much open content that really pushes the point in strict economic terms. | 13:28 |
| cdent | mordred: funding janitors is definitely a needed thing. It was kind of what rocky was going for in one of her sessions in vancouver but it got sidetracked. As our local token board member, is that a thing you can push harder? | 13:29 |
| *** edmondsw has quit IRC | 13:29 | |
| persia | scas: Yes, but those might not be upgraded over that term, which is the only time the PS folk are incented to care about what upstream does. | 13:29 |
| mugsie | cdent: mordred it also came up in the BoD session in Vancouver | 13:29 |
| mordred | cdent: I can certainly try - I've raised it in, I believe, every board meeting we've ever had | 13:29 |
| cdent | mordred: you are a) a star, b) apparently need to go nova | 13:30 |
| mordred | the issue is that nobody on the board are in the product-management chain at their companies that control employee allocation to tasks | 13:30 |
| persia | Do we believe that a sufficient plurality of the board represents organisations that are liable if future releases of openstack fail to perform in the way that the current releases perform? if not, that's not a useful body to approach for this sort of request. | 13:30 |
| scas | persia: fair point. upgrading has been something that has been lightly approached due to time involved | 13:30 |
| mordred | so while everyone on the board seems to understand the issue and agree it should be made better, everyone seems equally as empowered as I am to effect that change in their host companies | 13:30 |
| cdent | meh | 13:30 |
| mugsie | yeah - they are usually so far removed from the real work their company does, I wonder do they even know what level of upstream that they actually have, or just reading sumaries of management reports | 13:31 |
| scas | in chefland, once one is at a certain deployment level, upgrading is usually done out of band without involving the automation | 13:31 |
| mordred | (in case y'all don't know, I do not have any power to affect change in my host company) | 13:31 |
| scas | (not causing too much pain, there's that theme) | 13:31 |
| cdent | mordred: let's form a new company and hire each other | 13:32 |
| mordred | cdent: such a good idea | 13:32 |
| * smcginnis laughs at "host company" | 13:32 | |
| mugsie | persia: well, our latest platnium member will still be printing money if openstack is a thing or not for example, same for quite a few member companies | 13:32 |
| mordred | cdent: do either of us know how to find money to pay each other? | 13:32 |
| persia | mugsie: That has nothing to do with whther the code is any good, unfortunately. | 13:33 |
| cdent | mordred: I was assuming I'd pay you with the money you pay me. That's how capitalism works, right? | 13:33 |
| scas | mordred: just use a blockchain! | 13:33 |
| mordred | cdent: oh, right | 13:33 |
| mugsie | mordred: there has to be a bank running a Havana cloud we can consult on right? | 13:33 |
| mordred | scas: yes! we just do an ICO right? | 13:33 |
| persia | Or, for that matter, whether any particular project within the "openstack" umbrella exists or is maintained, as long as "openstack" is a thing. | 13:33 |
| mordred | mugsie: SO MANY BANKS | 13:33 |
| scas | mordred: yup. the white paper is literally writing itself | 13:33 |
| mugsie | in ten years someone who can debug a broken havana openstack install will be the new cobal developer | 13:33 |
| scas | something something moon | 13:33 |
| persia | smcginnis: Would you prefer "sponsoring fiscal entity" (being the formal term of art)? | 13:34 |
| evrardjp | mugsie: I laughed, but I don;t know if I should | 13:34 |
| mugsie | I am only 1/2 joking | 13:34 |
| mordred | persia: inside of companies I've tried multiple times to communicate that it's cheaper to fund janitors upstream than to fund people to fix breaks after the fact downstream. unfortunately, it's a value prop that spans more than one fiscal quarter, so none of the managers involved are particularly motivated to invest in a reward outside of their bonus comp structure | 13:35 |
| scas | mugsie: i can see it being plausible. platform choices tend to be multi-year things. no reason why someone wouldn't be running havana in a decade, if they can keep their own personal pain levels tolerable | 13:36 |
| *** edmondsw has joined #openstack-tc | 13:36 | |
| scas | i used to support a websphere customer whose one and only request was 'reboot the machine' | 13:36 |
| scas | that's what they paid for | 13:37 |
| persia | mordred: Certainty and profit also matter. Organisations that charge for time are incented to do it wrong, if the customer pays. Most PS orgs are like this. Also, orders are fufilled, but it is unwise to undertake a staffing commitment until one has a forward contract to consume that. So, until there is known funding to solve a problem, it doesn't make sense to staff someone to do the janitorial work. By the time it does make sense, it's too | 13:37 |
| persia | late (plus, maybe charge the customer). | 13:37 |
| mordred | persia: yah | 13:38 |
| mordred | scas: I used to get paid to 'support' an app that had no support needs - but nobody at the company understood the tech, so they put me on the payroll to hedge risk in case something did break | 13:39 |
| persia | I believe there are only two common business models that fund janitors, being a) operators (as it's cheaper to hire a janitor than pay PS $$$$ every once in a while) and b) orgs with "fixed-price" commitments (which are anything but), that do not incur additional hourly rates for faiure, but rather either see no gain or see reduced income (common in soverign contracts). | 13:39 |
| mordred | in the time I worked there, it didn't break such that I needed to do anything one time :) | 13:39 |
| persia | PS firms (which we often call "vendors") generally benefit significantly from the lack of janitors, from upstream code not working, from upstream documentation being low quality, and similar. | 13:39 |
| *** edmondsw has quit IRC | 13:41 | |
| scas | it has been said, in this channel, that such efforts as the one i currently consider a giant hobby are better suited as products | 13:41 |
| scas | only once, but that one sticks with me | 13:41 |
| scas | being that so much capital flows through and around openstack, it shouldn't be that there are discussions about how to fund the development | 13:43 |
| cdent | one would think as much, but here we are | 13:44 |
| scas | indeed. that's the part i didn't follow up with | 13:45 |
| scas | i had some sidewalk discussions at the peak of the hype, when i learned what itch i was really scratching. the story was stark back then: "they don't see any money in it, so this is our last summit" | 13:46 |
| mugsie | the problem is for a lot of private operators, the infra / cloud / platform team (which is where a janitor style role woudl come from) is considered a cost centre, so trying to justify the headcount can be difficult, the PS organisations want billible hours (see persia's description), and the traditional linux vendors who traditionally do the janitor work get the entire bucket, which means they need to prioritize the areas they do janitorial | 13:48 |
| mugsie | work in | 13:48 |
| scas | five cycles later, the self-reported survey shows that there's something. people use these things that "didn't see any money" | 13:48 |
| *** edmondsw has joined #openstack-tc | 13:51 | |
| persia | mugsie: I fail to see a distinction between "linux vendor" and "PS firm", although I admit that the folk who work on open source are often a cost centre not in the PS team. | 13:54 |
| scas | the paths to openstack are as important as openstack itself. not every company is able to make the cosmic shift, be it due to whatever reason they have. ps orgs can only do so much | 13:54 |
| persia | The operators are definitely a cost centre. See the Public Cloud WG for examples of operators that understand that landing things early can reduce the overhead of that cost centre. | 13:54 |
| persia | There are also perversities related to the cycle structure. Professionally, I only care about Queens and Stein. I'll start caring about Rocky only after it isn't a development target. Personally, I understand that this is a broken model, but I've been around a whlie. Folk used to less transparent development environments may not appreciate things in the same way. | 13:56 |
| scas | professionally, i care about three releases roughly tied to equivalent osp versions. for my other hat, i care mainly about whatever 'master' is at at the time | 13:59 |
| *** amotoki_ is now known as amotoki | 14:01 | |
| scas | i'll generally start focusing on rocky once packages have been made GA | 14:01 |
| scas | i've tried to keep closer to trunk, but it was not worth the additional burden of chasing a moving target | 14:02 |
| persia | That this is true *except* when one has outstanding patches is part of why there are so few janitors. | 14:04 |
| *** jaypipes has quit IRC | 14:06 | |
| scas | alas, this is the underpinning of the bazaar model | 14:08 |
| scas | when widely used open source efforts are maintained by people who show up 'for fun', it's not always sustainable | 14:09 |
| *** jaypipes has joined #openstack-tc | 14:10 | |
| scas | i speak not only of openstack, but others. i'm all too reminded of freebsd of yesterdecade | 14:10 |
| mugsie | persia: the difference for me is one is a product team, with PS, who does product dev in a "upstream kind of first" model, the other is a "we will fork openstack where is it now, and maintain it for you for the life of your contract" | 14:10 |
| scas | the mentality of not upstreaming first, or at all, is part of the problem for maintaining things. i can point to metrics, but i can also infer that most of them carry local patches | 14:11 |
| persia | mugsie: In march, I spent three days staffing a booth wherein I was discussing how to deal with the latter with "life of the contract" being measured in decades. It turns out that it looks a lot like the former, except with more complicated testing infrastructure. | 14:12 |
| mugsie | the reality is for a "boxed product" style on premises product, you will always have patches you are carrying - it is the nature of the beast. the key metric is how soon you converge with the upstream solution to the bug after upstreaming it | 14:13 |
| mugsie | persia: yeah, but a lot of these PS orgs have been doing this style of product for decades, and have the infra / people / process to pull it off (most of the time) | 14:14 |
| persia | Not necessarily. I spent some time working with a "boxed product" vendor that shipped unmodified public code. The value add was entirely about the box. There are lots of models, and many are in use by different parties at any given time. | 14:14 |
| persia | mugsie: Yep, but key is that if some constituency wants folk to perform janitorial duties, the organisations you describe are entirely the wrong audience for the request. | 14:15 |
| scas | ps orgs won't necessarily do the work. you can't bill for open sourcing | 14:17 |
| persia | Oh, yes you can :) | 14:18 |
| scas | if there's a perceived need. many enterprises like to consider their local patches akin to the crown jewels themselves | 14:20 |
| ttx | It's a general trend as open source gets more and more adopted / the default, the imbalance between users and contributors is only getting worse | 14:23 |
| ttx | OpenStack is far from being the only open source project suffering | 14:23 |
| scas | ^ | 14:24 |
| mugsie | ttx: very true | 14:24 |
| ttx | hype keeps you afloat artificially | 14:24 |
| persia | This is contrary to my experience. 30 years ago, "contributors" were magic folk, and learning to be a contributor was hard, but *everyone* used the code. Not doing so left you with the vendor tools, which were only as good as the unix wars permitted. | 14:24 |
| persia | Transparency has increased, but I think the ratio of users to contributors is actually smaller. | 14:25 |
| ttx | One mistake we made is to build to much processes (in the Zingerman sense) around that period of abundance | 14:25 |
| persia | That is something with which I agree | 14:25 |
| ttx | It's easy to believe it will never stop. We made taht mistake, and K8s is doing the same right now | 14:25 |
| scas | indeed | 14:25 |
| ttx | There must be a syndrome with someone's name to describe that. The fallacy of nice things | 14:26 |
| persia | Being able to name the discoverer is one of the nice things that seems to have been lost along the way. | 14:26 |
| mugsie | ttx: yeah, I saw it when I was working on k8s - all our team did was pull the source, and package it in a box nicely - we didn't do any upstream at all (in k8s - we did in some of the container runtimes) | 14:29 |
| scas | the unfortunate reality is that as open source becomes the default choice, all too often, many people are happy this simple fact: so long as it Just Works, it can be one person or 100 | 14:29 |
| scas | to a great extent, many can be unaware as to how things are behind the curtain | 14:30 |
| fungi | cf, openssl | 14:30 |
| openstackgerrit | Thierry Carrez proposed openstack/governance master: Adding Dariusz Krol candidacy for Trove PTL https://review.openstack.org/588510 | 14:30 |
| ttx | I fixed the review, you can revote on it ^ | 14:31 |
| ttx | wow. hmm | 14:31 |
| ttx | Somehow gerrit is smart enough to see that that patchset was the same as the previous one we voted on | 14:32 |
| ttx | That is kind of cool | 14:32 |
| scas | coming from freebsd, i was accustomed to the notion of a single person being responsible for a large swathe of a codebase | 14:32 |
| smcginnis | ttx: I've noticed that behavior since the last gerrit upgrade. Kind of nice. | 14:33 |
| scas | to that degree, it's not often that i've asked of others | 14:34 |
| cdent | ttx gerrit looks at the commit hash et voila | 14:38 |
| cdent | it's not super new, but happens rarely enough that when it does it's all "zomg, gerrit is so my friend" | 14:38 |
| *** hongbin has joined #openstack-tc | 14:41 | |
| *** dtantsur is now known as dtantsur|brb | 14:43 | |
| scas | fostering continuity to spread beyond a small focused group, or an individual in some cases, suggests to be predicated on the ability for someone new to grok things to be able to propose and land patches | 14:44 |
| scas | it's easy for someone accustomed to not see the sharp edges | 14:45 |
| scas | this is especially true in the more complex of efforts | 14:45 |
| evrardjp | cdent: yeah on the "it's not so new", and definitely on the "so my friend" ;) | 14:48 |
| ttx | updating status on https://etherpad.openstack.org/p/stein-leaderless | 14:50 |
| openstackgerrit | Chandan Kumar proposed openstack/governance master: Move refstack-client, refstack and python-tempestconf to interop WG https://review.openstack.org/590179 | 14:50 |
| scas | during the time i had freebsd as a focus, going back some two decades at this point, the more cantankerous of efforts usually had one person. contributing patches was notoriously difficult due to numerous reasons | 14:50 |
| chandankumar | ttx: Hello | 14:51 |
| ttx | chandankumar: o/ | 14:51 |
| chandankumar | ttx: https://review.openstack.org/#/c/590179/ regarding this review do i need to update project-config also? | 14:51 |
| *** dpl has quit IRC | 14:51 | |
| ttx | no.. from an infra perspective the repos do not change | 14:52 |
| chandankumar | ttx: i donot know how working group handles release deliverables? | 14:52 |
| chandankumar | ttx: ok | 14:52 |
| ttx | it's just a governance question... what entity owns them | 14:52 |
| ttx | if you add them on one side you need to remove them from the other side | 14:52 |
| chandankumar | ttx: got it thanks :-) | 14:54 |
| *** annabelleB has joined #openstack-tc | 14:55 | |
| ttx | tc-members: you should vote on that change (confirming Claudiu as PTL for another cycle at Winstackers) https://review.openstack.org/#/c/589553/ | 14:55 |
| ttx | err | 14:56 |
| ttx | that is not the change I expected | 14:56 |
| ttx | let's wait until it's fixed | 14:57 |
| ttx | So regarding leaderless projects, it looks like we have a clear resolution path for all, except Freezer | 14:59 |
| ttx | (otherwise there seems to be lazy consensus in keeping Trove and removing Searchlight) | 15:00 |
| cdent | oh look tc-members it's office hours | 15:00 |
| smcginnis | o/ | 15:00 |
| fungi | ohai | 15:00 |
| * cmurphy has a conflicting meeting :'( | 15:00 | |
| EmilienM | o/ | 15:01 |
| smcginnis | Didn't we have a candidate for freezer? | 15:01 |
| ttx | What's your take on Freezer ? Approving Changcai or dropping it ? | 15:01 |
| smcginnis | Agree on the trove and searchlight ones. | 15:01 |
| ttx | smcginnis: we do, does not mean we should save it... since it missed Rocky. | 15:01 |
| pabelanger | hello | 15:01 |
| ttx | I'm leaning weakly toward keeping them provisionally and revisit before Membershipfreeze | 15:01 |
| zaneb | o/ | 15:02 |
| smcginnis | That works for me. Let's give them a little time to right the ship, then follow through with policy if we don't see that happening. | 15:02 |
| ttx | Dropping it now would seriously impact that new leadership from stepping up | 15:02 |
| fungi | cmurphy: yeah, i have another meeting at the exact same time as our thursday office hour too. makes it hard to split my attention successfully | 15:02 |
| ttx | but I could go the other way, because the missed release looks so bad | 15:03 |
| cdent | If we're going to give people extra time we _must_ be strong in our follow through | 15:03 |
| smcginnis | cdent: ++ | 15:03 |
| TheJulia | o/ | 15:03 |
| ttx | cdent: I'd argue we need a pair signed up to follow | 15:03 |
| * ttx looks who the lucky winners are | 15:03 | |
| ttx | ttx and mugsie | 15:04 |
| smcginnis | You're a winner! | 15:04 |
| ttx | suckers! | 15:04 |
| ttx | err | 15:04 |
| TheJulia | lol | 15:04 |
| * TheJulia suddenly wants to watch the fifth element | 15:05 | |
| ttx | We *do* reshuffle those every cycle right | 15:05 |
| ttx | smcginnis: if you feel this way, you should vote on https://review.openstack.org/#/c/590071/ and https://review.openstack.org/588645 | 15:06 |
| smcginnis | Oh right. | 15:06 |
| openstackgerrit | Luka Peschke proposed openstack/governance master: Updating CloudKitty PTL information https://review.openstack.org/590180 | 15:06 |
| ttx | smcginnis: wants to give a quick report on how the release is going so far ? | 15:11 |
| ttx | want* | 15:11 |
| smcginnis | They're going. | 15:11 |
| smcginnis | :) | 15:11 |
| smcginnis | We have a few projects yet to RC, but I'm not too concerned at this point. Yet. | 15:11 |
| * smcginnis pokes mugsie | 15:12 | |
| smcginnis | I've at least seen some activity from most of the major ones. | 15:12 |
| ttx | it's your everlasting optimism | 15:12 |
| fungi | optimism is what keeps the homicidal rage at bay | 15:13 |
| smcginnis | Yep | 15:14 |
| * dhellmann finally makes it through atlanta traffic | 15:15 | |
| smcginnis | Seems like we had most of the discussion today before the office hour. | 15:15 |
| dhellmann | ttx: my plan was to change liaisons each tc term, since that's when the tc members might change over. after stein that will sync back up closer to the dev cycle so it amounts to the same thing | 15:17 |
| cdent | I had a small update on the paste situation, mentioned it before, but will restate: it looks like haypo may have the keys to the paste kingdom, but it is August and he's in France | 15:17 |
| smcginnis | Send ttx to track him down? | 15:18 |
| dhellmann | cdent : what's the plan then? get him to land the fix? or add some volunteers? | 15:18 |
| * dhellmann volunteers to go to france to hunt for haypo | 15:18 | |
| dhellmann | in spite of the heat | 15:18 |
| * lbragstad is curious of other services have discussed other options to paste | 15:18 | |
| EmilienM | I'm actually flying to France right now | 15:18 |
| smcginnis | I'll carry dhellmann's bags | 15:18 |
| * EmilienM knows where he lives | 15:18 | |
| smcginnis | lbragstad: How is the flask work going? | 15:19 |
| cdent | dhellmann: based on what I was able to read, haypo is neither interested, nor has the expertise to "own", so I reckon if we want stability we will need to adopt, so my plan was to see what he thought of that idea | 15:19 |
| ttx | cdent: those French people don't work in August | 15:19 |
| lbragstad | pretty good so far | 15:19 |
| dhellmann | cdent : ok | 15:19 |
| smcginnis | cdent: It would be good having some input from someone "official" on that project, even if he's not an expert. | 15:20 |
| cdent | lbragstad: I think lots of services would like to change but a) the usual resources problems (see earlier in today's logs), b) the extant paste.ini files that are out in the world and are customized | 15:20 |
| lbragstad | smcginnis: we've had the plumbing merged for quite a while, so now we're at the point of converting parts of keystone's APIs to using actual flask | 15:20 |
| smcginnis | lbragstad: cdent has a good point. Are you doing anything to handle the migration from paste.ini, or is it a clean cut over? | 15:20 |
| cdent | smcginnis: I think calling him official is overstating things. It's merely that he was granted the power to <not quite sure> at some point in the past. There is no project. It is dead. | 15:20 |
| dhellmann | it sounds like maybe he's the person to give the keys to someone else who wants to take it over, though. if we have such a person. | 15:21 |
| smcginnis | Well, official in this case just being he has some power related to the project. | 15:21 |
| smcginnis | Yeah, it's at least a possible pathway to some other activity. | 15:21 |
| lbragstad | smcginnis: kmalloc was providing some ways to load middleware via configuration, but otherwise we're attempted to pull middleware into keystone proper | 15:21 |
| lbragstad | at least as a stop gap | 15:22 |
| lbragstad | but ultimately it would be nice if those lines were cleaner (IMO) | 15:22 |
| lbragstad | and i think that's what we're striving towards | 15:22 |
| smcginnis | Current RC status in case anyone is interested: http://paste.openstack.org/show/727745/ | 15:23 |
| *** alex_xu has quit IRC | 15:24 | |
| * lbragstad sets https://review.openstack.org/#/c/590361/ next to smcginnis | 15:24 | |
| smcginnis | :) | 15:24 |
| dhellmann | cdent , smcginnis : since you were both working on https://etherpad.openstack.org/p/tc-board-foundation I wanted to make sure that you saw that Alan will be there Sunday for the PTG and that I added an agenda item to talk about the joint leadership meeting for November. There could be some nice overlap with the topics you had in mind. | 15:25 |
| smcginnis | dhellmann: Thanks, that could be good. | 15:26 |
| cdent | indeed | 15:26 |
| *** dtantsur|brb is now known as dtantsur | 15:29 | |
| dhellmann | tc-members: I count about 25 teams that don't seem to have health tracker details on https://wiki.openstack.org/wiki/OpenStack_health_tracker | 15:29 |
| cdent | I had another thing I wanted to ask about, and it has completely slipped my mind. I think the earlier conversation about loyalty and resources (which was very interesting) used up my brain | 15:29 |
| dhellmann | some have "reported issues" but nothing that looks like an update from a tc-member | 15:29 |
| mnaser | i think i never updated mine on the wiki so i'll get around it. | 15:29 |
| EmilienM | I still need to reach out some of them indeed | 15:30 |
| TheJulia | I think I have one I still need to reach out to, and two I need to follow-up on. Hopefully in the next few days. | 15:30 |
| pabelanger | I'm still have 2 sigs to reach out too, been missing their meeting times sadly | 15:31 |
| dhellmann | that would be great, thank you | 15:31 |
| dhellmann | pabelanger : I think we can emphasize the project teams for this round (and given the timing) | 15:31 |
| dhellmann | but if you're done with those, by all means contact the sig leaders | 15:31 |
| pabelanger | dhellmann: ack | 15:31 |
| cdent | do we have enough data to identify any trends or themes? | 15:32 |
| dhellmann | tc-members: if you have tried to contact the PTL of the team and had no response, just note that. that's an indicator on its own :-/ | 15:32 |
| dhellmann | cdent : I haven't had time to review all of the reports yet, but I intend to do that before denver so we can discuss it there | 15:33 |
| persia | Maybe also note how and when the contact was attempted. Some people are oddly strict about hours. | 15:33 |
| dhellmann | persia : ++ | 15:33 |
| TheJulia | Also retry, I had one PTL that never recieved two emails and I finally got ahold of them on the third and via IRC. | 15:34 |
| dhellmann | email knows no time | 15:34 |
| dhellmann | TheJulia : good point | 15:34 |
| fungi | i've been doing my best to get up with them in scheduled meetings so far, but yes there are a few on my plate that are lacking updates in the wiki, or for which i haven't solicited details yet | 15:34 |
| persia | dhellmann: It so does. There exist people who only read email during $hours, and if things are missed in a day, never get back to them. | 15:34 |
| persia | Also, email is inherently unreliable (by mechanisms inherent in the current protocols), so retries do matter (and hours of retries matter: some organisatons do filtering differently by time of day). | 15:35 |
| *** ricolin has joined #openstack-tc | 15:36 | |
| mordred | persia: I frequently fall into that set of people | 15:38 |
| mordred | persia: email is a terribly unreliable way to reach me - not because my email itself is bad (it's actually quite good) but because if I miss it it's typically gone for good :) | 15:39 |
| *** dklyle has joined #openstack-tc | 15:39 | |
| persia | mordred: Thank you for volunteering! You are an excellent example case of folk who generally communicate well that suggest a single email at potential $bad_time_of_day isn't a reliable mechanism. | 15:39 |
| fungi | it's unfortunate that e-mail is so unreliable given smtp is extra reliable, people have built in all sorts of unreliability in the name of progress | 15:39 |
| fungi | s/built in/bolted on/ | 15:40 |
| persia | fungi: Sadly, even SMTP isn't reliable any more: recent protocol updates actively remove some of what was there (but I'm arguing *with* you here). | 15:40 |
| fungi | sure | 15:40 |
| pabelanger | dhellmann: I've updated loci info on wiki, reply came in while on PTO | 15:40 |
| mordred | my problem is that I very reliably get way too much email | 15:41 |
| dhellmann | pabelanger : thanks | 15:41 |
| fungi | roughly twice a year i get tasked with sending out code contributor discounts for summit registration. it's not until after i send e-mail to ~1500 people that i realize just how many of them decide to reply to me | 15:41 |
| fungi | some have questions, some just want to have friendly conversation | 15:42 |
| mordred | how friendly | 15:42 |
| fungi | it's a great way to virtually meet lots of people from the contributor community, but also quite a time sink :/ | 15:42 |
| *** annabelleB has quit IRC | 15:43 | |
| *** annabelleB has joined #openstack-tc | 15:43 | |
| fungi | and i feel compelled to reply to them all, because not to do so would be rude | 15:43 |
| persia | You are a fundamentally good person. | 15:43 |
| TheJulia | ++ | 15:44 |
| TheJulia | I personally fall into the email is the worst way to contact me, since so many emails I get are just noise, and it makes it difficult to pick out the signal for me... especially when... *squerrel!* | 15:46 |
| ttx | squerrels are the worst | 15:46 |
| fungi | unfortunately i've got really efficient server-side filtering set up on my mta | 15:48 |
| fungi | which makes it all too easy to separate signal from noise | 15:48 |
| fungi | but... so much signal | 15:48 |
| ttx | zeroth-world problems: My spam filter is too good | 15:49 |
| persia | Receiving no spam != receiving zero noise. Some folk's signal is other's noise, especially if there is limited time for email. | 15:50 |
| TheJulia | I've had too much bad luck with spam filtering catching legitimate email and stuff getting caught into the wrong folder because of an out of band reply, that I just try and keep it all minimally messed with and scan when the braincells are powered. | 15:51 |
| * kmalloc circles up | 15:52 | |
| TheJulia | ttx: my spam filtering was awesome when I ran a private TLS wrapped SMTP system for law firms that was all whitelist access only to reach each other... we had zero spam. | 15:52 |
| kmalloc | fwiw, keystone (as of now) does not allow loading of non-standard middleware (one exception is the debug middleware) in the pipeline | 15:53 |
| kmalloc | this is for 2 reasons: 1) security, even if we re-enable it, non-blessed middleware cannot be added after we handle auth because it could muck with data in ways we can't control, breaking how keystone handles a request, and 2) because loading in middleware after auth is as easily handled above the wsgi layer in a proxy | 15:54 |
| cdent | kmalloc: yeah, that's how it should be, but unfortunately nova, at least, is not like that | 15:54 |
| kmalloc | we could add in a loader (trivially) at this point, but it would still adhere to the "before the keystone authentication handlers" because of the security concerns / possibility of breaking keystone in horrible ways. | 15:54 |
| lbragstad | and paste.deploy is !maintained :( | 15:54 |
| kmalloc | we do direct load of the middleware we care about and instantiate it, wrap the wsgi_app | 15:55 |
| cdent | yeah, same thing in placement. is nice separation of concerns with good control | 15:55 |
| kmalloc | if you look here https://github.com/openstack/keystone/blob/master/keystone/server/flask/core.py#L89 we load in our middleware we care about here | 15:56 |
| kmalloc | once keystone is moved to pure flask, all the middleware supplied by keystone's python package (itself) will be moved to flask "before_request" methods | 15:56 |
| kmalloc | so we will only have oslo/blessed 3rd party middlewares loaded in | 15:56 |
| kmalloc | cdent: yeah, i looked at some of what placement was doing when making decisions on how keystone was going to handle that | 15:57 |
| jroll | ironic does the same, we only load middleware we know about | 15:57 |
| kmalloc | cdent: i much prefer telling folks "you may use a proxy in front of keystone, or you may use keystonemiddleware if you need to be behind "auth" | 15:58 |
| kmalloc | jroll: ++ yeah it is silly to allow "any/all" middleware from anywhere | 15:58 |
| jroll | not that people won't just patch it to add things in, but we tried :) | 15:58 |
| lbragstad | also - this might be irrelevant to some | 15:58 |
| kmalloc | jroll: i find people "patching" things in is much rarer and those folks are going to do silly thing anyway | 15:59 |
| lbragstad | but using something like flask cleans up a lot of technical debt for us | 15:59 |
| *** dklyle has quit IRC | 15:59 | |
| kmalloc | jroll: solution: re-write keystone in rust (s/keystone/ironic) and distribute binaries with obfuscation. no wait, that is the wrong answer ;) heheh | 15:59 |
| lbragstad | s/irrelevant/an implementation detail/ | 15:59 |
| kmalloc | lbragstad: ++ | 15:59 |
| jroll | heh | 16:00 |
| kmalloc | we could have done flask with paste, but i figured i could more easily drop paste with a move to flask than any other time | 16:00 |
| kmalloc | since there was massive re-working to be done. | 16:00 |
| lbragstad | for example - the community goal we wanted to get done for Rocky becomes a lot simpler to implement | 16:00 |
| kmalloc | lbragstad: especially since we don't use oslo.service | 16:00 |
| jroll | lbragstad: do you think that was because you used something like flask, or because you were re-writing a large chunk of code anyway, so it was easy to clean up while you were there? | 16:00 |
| jroll | (or both) | 16:00 |
| kmalloc | jroll: both. | 16:00 |
| lbragstad | for sure the later | 16:00 |
| jroll | nod | 16:01 |
| kmalloc | jroll: flask makes it a lot easier to add in functionality where we need / change out how things work. but massive re-write makes it easier to make big changes / plan for the big changes | 16:01 |
| lbragstad | flask probably has something to do with it, but i'm sure $other_framework would work, too | 16:01 |
| kmalloc | yeah | 16:01 |
| *** dklyle has joined #openstack-tc | 16:01 | |
| kmalloc | any well built framework would have had the same benefit | 16:01 |
| lbragstad | adhering to a framework helps us isolate our business logic from the wsgi layer (if that makes sense?) | 16:03 |
| jroll | nod | 16:03 |
| lbragstad | which should, theoretically, help us improve self-service APIs in a "secure" way | 16:03 |
| kmalloc | it also is forcing us [the way i wrote the conversion] to merge in all the separate api "extensions" so each path prefix (e.g. /users) is isolated into a single file "controller" wise. | 16:04 |
| *** annabelleB has quit IRC | 16:04 | |
| kmalloc | we used to have things spread all over and could hook into any url prefix from anywhere | 16:04 |
| lbragstad | ^ should help with developer pain of understand routing in keystone | 16:04 |
| lbragstad | understanding* | 16:04 |
| lbragstad | which kinda gets to cdent's point of having less people around | 16:04 |
| *** annabelleB has joined #openstack-tc | 16:05 | |
| kmalloc | we're also not just using flask, we're using flask_restful (mostly) | 16:05 |
| kmalloc | since it adds some nice API-specific mechanisms. | 16:05 |
| cdent | understanding routing is _huge_ help | 16:05 |
| kmalloc | i also very much like that flask has a global request context that can be accessed from anywhere as long as the request has started (in the flask app) | 16:06 |
| lbragstad | i hope it helps when people don't have to wrap their minds around a custom routing/dispatcher to understand how keystone's API is implemented (especially if they are already familiar with something like flask) | 16:06 |
| *** annabelleB has quit IRC | 16:06 | |
| kmalloc | so no need to pass "request" or "context" around, just reference it. it makes our code a lot easier to work with. | 16:07 |
| kmalloc | we used to pass request objects all over the place | 16:07 |
| kmalloc | now we just do flask.request.<request_bit, usually environ> | 16:07 |
| clarkb | kmalloc: out of curiousity why have a debug middleware over say debug logging configuration? Does it let you do more than record requests in detail? | 16:07 |
| kmalloc | kmalloc: debug middleware is specific to whole-app-wsgi debug data, it is in addition to debug logging | 16:08 |
| *** jpich has quit IRC | 16:08 | |
| kmalloc | most folks have no use for the debug middleware data even when debug logging, but since we offered it by defualt before, i maintained it | 16:08 |
| kmalloc | it is on the short list of "to be removed" if we don't have a concrete use for it | 16:09 |
| kmalloc | easier to keep out base set of middleware than drastically change it (for example, i'd love to make os-profiler not even loaded unless configured on as well) | 16:09 |
| kmalloc | s/kmalloc/cdent | 16:10 |
| kmalloc | :P | 16:10 |
| kmalloc | erm | 16:10 |
| kmalloc | clarkb: dang it, you all have similar names pre-coffee | 16:10 |
| kmalloc | :P | 16:10 |
| * cdent has been mistaken for clarkb before | 16:12 | |
| fungi | unrelated, but in response to my comment last week about cyborg not having weekly meetings in irc even though they have subteams meeting on zoom, seems they _do_ have weekly irc meetings they just hadn't put them on the schedule. fixed with the merging of https://review.openstack.org/589971 | 16:12 |
| cdent | lbragstad, kmalloc was there a particular thing that made doing the flask switchover "possible" for a priority/time/permission/whatever it takes sense? | 16:17 |
| lbragstad | um - well if i understand your question, we kinda had to do it to do fix some problems in keystone | 16:17 |
| lbragstad | for example, incorporating the new default roles we provide into keystone APIs is a lot easier after converting to flask | 16:18 |
| cdent | okay, so would it be fair to say you were able to justify it by hanging it on a feature of some kind? | 16:19 |
| lbragstad | s/converting to flask/separating keystone business logic from parts of the WSGI implementation/ | 16:19 |
| lbragstad | i would say so, yes | 16:19 |
| cdent | if you just wanted to "clean up" would you still have been able to do it? | 16:19 |
| cdent | I know these are weird questions, because it's not like anyone is likely telling you exactly what to do, but... there are implicit drivers | 16:19 |
| lbragstad | well - i guess i would still push to have done the conversion to flask even if we didn't hang a feature (security specific feature) on it for the sake of making keystone easier for newcomers to understand | 16:20 |
| * lbragstad isn't sure if he's giving conflicting answers | 16:20 | |
| lbragstad | we've had a decline in contributors and maintainers, so making it easier for new people to join or pick things up is important IMO | 16:21 |
| cmurphy | i wish we had planned better at the beginning of the cycle to incorporate the flask stuff | 16:21 |
| cdent | I'm not sure there are any straight answers. I'm mostly fishing for your feelings | 16:21 |
| cmurphy | we had some other stuff drop off the table this cycle while we were spending bandwidth on flask | 16:22 |
| lbragstad | yeah | 16:22 |
| cdent | so we can steal the oomph | 16:22 |
| lbragstad | it wasn't until like halfway through we were looking at everything and seeing the impact it would have if we waited until after we cleaned up a ton of the technical debt fixed by flask | 16:23 |
| lbragstad | or converting to an official framework that wasn't our handrolled-thing | 16:23 |
| lbragstad | but i completely agree with cmurphy, i would have likely to foreseen that impact sooner =/ | 16:25 |
| lbragstad | s/likely/liked/ | 16:32 |
| *** hongbin has quit IRC | 16:37 | |
| *** tosky has quit IRC | 16:39 | |
| openstackgerrit | Merged openstack/governance master: Add Tripleo Ansible repo https://review.openstack.org/583416 | 17:09 |
| openstackgerrit | Merged openstack/governance master: Add openstack-chef project https://review.openstack.org/585473 | 17:12 |
| *** annabelleB has joined #openstack-tc | 17:22 | |
| *** cdent has quit IRC | 17:29 | |
| *** gouthamr is now known as gouthamr_away | 17:37 | |
| *** ricolin has quit IRC | 17:46 | |
| *** annabelleB has quit IRC | 18:03 | |
| kmalloc | lbragstad: unfortunately, it's hard to see the impact (mostly the cleanup benefits) sometimes | 18:09 |
| kmalloc | lbragstad: early on | 18:09 |
| kmalloc | lbragstad: also, flask work didn't start right at the beginning of the cycle. =/ | 18:10 |
| *** dtantsur is now known as dtantsur|afk | 18:24 | |
| *** annabelleB has joined #openstack-tc | 18:27 | |
| *** annabelleB has quit IRC | 18:45 | |
| *** annabelleB has joined #openstack-tc | 18:48 | |
| *** mriedem has quit IRC | 19:11 | |
| *** mriedem has joined #openstack-tc | 19:11 | |
| *** tellesnobrega has quit IRC | 19:31 | |
| *** tellesnobrega has joined #openstack-tc | 19:32 | |
| *** annabelleB has quit IRC | 20:06 | |
| *** annabelleB has joined #openstack-tc | 20:11 | |
| *** lbragstad has quit IRC | 20:51 | |
| *** gouthamr_away is now known as gouthamr | 20:53 | |
| *** gouthamr is now known as gouthamr|brb | 21:20 | |
| mnaser | https://twitter.com/JohnONolan/status/980872508395188224 | 21:20 |
| mnaser | interesting thread to read | 21:20 |
| *** gouthamr|brb is now known as gouthamr | 21:20 | |
| *** gouthamr is now known as gouthamr|brb | 21:21 | |
| *** diablo_rojo has joined #openstack-tc | 21:23 | |
| jroll | neat, thanks for the link | 21:25 |
| *** zaneb has quit IRC | 21:27 | |
| fungi | yeah, that was going around back about the same time slack announced they were going to be getting rid of their irc gateway | 21:31 |
| *** gouthamr|brb is now known as gouthamr | 21:40 | |
| fungi | in discussing with tonyb, changes like https://review.openstack.org/590386 feel a little weird since it's altering the election record after conclusion of the election based on appointments which are the responsibility of the tc, but ni a repository with gerrit acls making it such that the election officials need to be the ones to approve those appointments | 22:11 |
| fungi | i understand it's more a matter of picking somewhere official-seeming to have appointee volunteers declare their intent and that there's no good way to track whether someone was appointed vs elected in the current projects.yaml data, so as a compromise it doesn't seem terrible, but still a little weird | 22:13 |
| *** annabelleB has quit IRC | 22:14 | |
| smcginnis | I did think it seems like these TC appointments should be recorded somehow in a governance repo, but... meh. | 22:15 |
| persia | smcginnis: They are, by means of the changes proposed (and approved) to projects.yaml | 22:18 |
| persia | `git blame` or similar will show which candidates were approved outside of the election process, letting one track down the relevant governance change (and TC discussion) | 22:19 |
| jroll | could always do a quick TC vote on the ML or with meetbot, and link to that, with the chair's +1 | 22:19 |
| smcginnis | persia: Yes, just that instead of putting that info also in elections where they were not actually part of any election, it seemed like maybe something else we needed to official state. But it does say TC-APPOINTED, so I was glad to see we at least have that as a breadcrumb for our future selves. | 22:20 |
| persia | jroll: How is that better than something like https://review.openstack.org/#/c/590071/ ? | 22:20 |
| jroll | persia: specifically I'm talking about changes like https://review.openstack.org/#/c/590386/ where the election results are being modified | 22:21 |
| jroll | (which is what seems weird to fungi) | 22:21 |
| jroll | if folks feel less weird after it's recorded in projects.yaml, then it's moot :) | 22:22 |
| persia | jroll: Yep. Before posting the link I did, I was searching for the equivalent at https://review.openstack.org/#/q/project:openstack/governance | 22:22 |
| persia | But I didn't see one for WinStackers, so there appears not to be a precise equivalent. | 22:23 |
| diablo_rojo | I think if its updated in governance that should be fine- I don't think we really need to also make changes to the elections repo. | 22:23 |
| fungi | in the case of the prior ptl being appointed to continue the seat after missing the nomination window, there's no current precedent for indicating that in the governance data | 22:24 |
| fungi | because the ptl info doesn't actually change | 22:24 |
| persia | Hrm. | 22:25 |
| diablo_rojo | That is an interesting conundrum | 22:25 |
| persia | Too late now, but in future, I suspect that the correct model is for the election update to clear the old data, to be updated after a vounteer volunteers. | 22:26 |
| persia | In the unusual situation where a volunteer appears during voting, I'm more comfortable approving it as a late nomination within the election. | 22:26 |
| persia | But post-election changes to election data feels wrong somehow. | 22:27 |
| *** tosky has joined #openstack-tc | 22:30 | |
| *** diablo_rojo has quit IRC | 22:55 | |
| *** evrardjp has quit IRC | 22:55 | |
| tonyb | I suppose for the *next* PTL election we could produce 2 changes, meant to be merged in rapid succession, one that sets all PTL positions to some placeholder that equates to 'Open pending election results', and a second one that appoints PTLs based on said election. In the event that a project remains leaderless in an election that will leave scope for a will candidate or the TC to appoint a PTL. | 23:15 |
| fungi | note my use of "precedent" there to not preclude extending the data we maintain in the governance repo, should that be a preferable option | 23:15 |
| tonyb | I *could* generate such chnages for this election if we think that's a good idea | 23:16 |
| tonyb | fungi: I did think of adding simple 'appointed-by' and 'appinted-at' records as well. | 23:17 |
| persia | tonyb: I was thinking just one change, representing election results (including setting to "None" if that is the result of the election). | 23:19 |
| persia | With individual changes for the individual appointments, unless everyone believes it makes more sense to appoint everyone at once (but that leaves less for discussion). | 23:20 |
| fungi | yeah, that may make more sense as a future process. election results change to governance removes the ptls for teams which did not elect one, and then the nominees get (re)added in subsequent changes | 23:23 |
| fungi | the other thing which is still missing, which may have been an intended feature of the present solution, is that at least some of them provided campaign platforms in their post-election changes to the election repo | 23:24 |
| fungi | i'm not sure ho important that is, as the volunteers could also just provide some similar verbiage in their commit message to governance | 23:25 |
| *** annabelleB has joined #openstack-tc | 23:26 | |
| *** tosky has quit IRC | 23:48 | |
| tonyb | Okay do you think there is merit in doign that now? Have we merged anything to the governance repo that would cause a problem? | 23:58 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!