| frickler | tc-members: related to yesterday's "what is openstack" discussion and a current question in the release-team channel, we might want to reconsider the way unofficial projects are using the openstack-provided publishing jobs | 07:50 |
|---|---|---|
| frickler | e.g. from looking at the pypi page, this looks very much like an official deliverable to me https://pypi.org/project/tobiko/ | 07:51 |
| frickler | noting in particular the "Author: OpenStack" tag in combination with the "Maintainers: https://pypi.org/user/openstackci/" | 07:53 |
| frickler | though the current situation is in fact documented in https://docs.opendev.org/opendev/infra-manual/latest/drivers.html#tagging-a-release | 07:54 |
| opendevreview | Dr. Jens Harbott proposed openstack/openstack-manuals master: CI: run build jobs on newer distro https://review.opendev.org/c/openstack/openstack-manuals/+/915086 | 08:07 |
| frickler | elodilles: tonyb: FYI we will be discussing future actions regarding the unmaintained process in the PTG session at 16:00 UTC, in case you want to join or add comments before at https://etherpad.opendev.org/p/apr2024-ptg-os-tc#L154 | 09:01 |
| elodilles | frickler: ACK, I saw that | 09:08 |
| frickler | tc-members: Transition Freezer project to DPL https://review.opendev.org/c/openstack/governance/+/914911 is needing more votes before being approved, please have a look, this would help allowing people to clean things up | 11:56 |
| frickler | noonedeadpunk: I think it would also be fine if you voted yourself on that review. also maybe can you get khyr0n to approve it? | 12:02 |
| frickler | JayF: the last PTG topic on the etherpad ("Somewhat heated discussion around "Moderizing Python Stack"") doesn't have an owner, but also isn't referenced in the schedule, do you maybe want to still add that at the end? | 12:18 |
| noonedeadpunk | frickler: I'm not sure if I can or should actually vote on smth I've proposed | 12:20 |
| noonedeadpunk | I wrote couple of emails to current PTL though didn't get any replies | 12:21 |
| frickler | noonedeadpunk: "... we usually ask all TC members to cast a vote on all patches, even those they write." https://governance.openstack.org/tc/reference/house-rules.html#voting-on-changes-in-openstack-governance | 12:30 |
| noonedeadpunk | frickler: well... I mean... there's context around this wording | 12:36 |
| noonedeadpunk | and I'm not sure if this proposal is that complex :D | 12:36 |
| noonedeadpunk | And I obviously don't want this to look like project hijacking | 12:38 |
| JayF | noonedeadpunk: I am not in favor of freezer going immediately to DPL, since that doesn't have a forcing function for check-ins. I've voted accordingly on the patch but wanted to ensure you saw this last part: a similar patch that appoints you (or another viable candidate) as PTL is something I'd be +1 to. | 14:24 |
| noonedeadpunk | JayF: I'm not read to take full responsibility as already quite over-subscribed. And other folks I've worked with do not know enough about the process to be ptl either | 14:26 |
| noonedeadpunk | *not ready | 14:26 |
| fungi | though we did discuss during the ptg that it might make sense to force people to re-volunteer for dpl liaison positions every cycle as a mitigation | 14:26 |
| JayF | I can completely understand that feeling; I don't think it changes my opinion that the DPL model (as currently implemented) is not a great idea for a project emerging from inactivity. | 14:26 |
| fungi | basically if a project can't renew sufficient dpl volunteers, it's treated the same as a ptl-governed project having no ptl candidate | 14:27 |
| noonedeadpunk | moreover, I feel that DPL might be quite good choice right now when new folks are joining development, so enforce them to step-in as well as giving some responsibility | 14:27 |
| noonedeadpunk | +1 | 14:28 |
| JayF | If that's the case, maybe we need to implement something like fungi's suggestion first | 14:28 |
| fungi | we definitely have multiple dpl-governed projects listing liaisons who haven't been active in the community for years | 14:28 |
| JayF | TBH feeling a little burned from our recent experience with the security bug, and I am wary of heading down a similar path | 14:28 |
| JayF | fungi: exactly | 14:28 |
| noonedeadpunk | basically my intention with freezer right now, bring project back on rails, gather interested parties together and see them collaborating, and step down leaving them in a good shape | 14:30 |
| noonedeadpunk | and PTL is opposite of that approach | 14:30 |
| noonedeadpunk | as then everyone feels kinda safe as there's a person who will take care regardless | 14:31 |
| fungi | similarly, in the past we moved projects who couldn't consistently meet release deadlines to an independent release model, and probably now have a non-zero number of them who are just not releasing the software at all | 14:32 |
| JayF | fungi: When we address inactive policy later today, can you please mention both of those situations? I think it'd be valuable to get an action item down around auditing those projects | 14:33 |
| JayF | and limiting to dpl / independent release projects should help narrow it significantly | 14:33 |
| fungi | JayF: yeah, i think those concerns are buried in some of the notes from yesterday. i'll try to interject but it's hard to get a word in edgewise on tc calls ;) | 14:35 |
| fungi | i'll try to remember to raise my hand when the time comes | 14:36 |
| JayF | yeah I try to make sure when I'm moderating a PTG session that all raised hands get addressed | 14:36 |
| frickler | so can we just keep freezer leaderless for now and just add noonedeadpunk to the core group? would that need a resolution or could it be "just done"? | 14:52 |
| fungi | even add noonedeadpunk to the core group and encourage him to add any other interested reviewers at his discretion | 14:54 |
| noonedeadpunk | Well, I will propose ofc patch with volunteering as ptl, but I will just -1 it | 14:54 |
| JayF | I don't know if it needs a resolution, but I am in agreement that's an obvious action to take | 14:55 |
| frickler | yes, I implicitly was assuming managing the core group would be part of what was happening then | 14:55 |
| noonedeadpunk | as for me dpl feels as not wrong thing despite challanges it might bring | 14:55 |
| noonedeadpunk | and then we can vote | 14:55 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/governance master: Assign Dmitriy Rabotyagov as Freezer PTL https://review.opendev.org/c/openstack/governance/+/915727 | 14:58 |
| frickler | JayF: I think you aversion against DPL might be related to the TC not following the procedure documented at https://governance.openstack.org/tc/resolutions/20200803-distributed-project-leadership.html#liaison-assignment-duration ? so this might be more something for the TC to fix than for the freezer team? | 15:09 |
| JayF | That process, afaict, is not happening at all. | 15:10 |
| JayF | If it did, it would ease my aversion to DPL, but I've found lots of evidence that in our community generally, not just in TC, without some kind of forcing function, expecting contributors to reliably perform recurring work is ... unwise. | 15:10 |
| frickler | so how about we amend that resolution, reset projects to leaderless each cycle unless the DPL people submit a new patch for it? | 15:11 |
| frickler | that would kind of revert the load | 15:12 |
| noonedeadpunk | well, I'd see that each out of DPL list should put +1 on the patch of renewing them | 15:12 |
| JayF | That sounds like a great change IMO, I would be curious to see how the rest of the TC would like it. | 15:12 |
| noonedeadpunk | rather then submit a patch - as that could be 1 person talking for everyone | 15:12 |
| frickler | noonedeadpunk: that's a good addition, yes. it also does affect your current dpl proposal, though ;) | 15:13 |
| noonedeadpunk | yeah | 15:14 |
| noonedeadpunk | but I can easily reach out and ask for that :) | 15:14 |
| noonedeadpunk | it was never needed | 15:14 |
| noonedeadpunk | (afaik) | 15:14 |
| TheJulia | Just chiming in here, at face value I like the idea of resetting projects each cycle. That being said, if the TC does it itself, I would also have concern over the it. | 15:15 |
| frickler | well I've asked for similar approvals on release team liaison changes before | 15:15 |
| frickler | TheJulia: what exactly would be your concern? just who proposes that change? | 15:16 |
| TheJulia | frickler: who proposed the change to say a project has a leader or continues as DPL. If the TC does so, then it just continues the status quo behavior, but if it is a non-tc member who makes the proposal, then we and the whole TC can have confidence in that there are folks doing the needful in a project without direct TC engagement | 15:17 |
| JayF | that's what noonedeadpunk was getting at, I thought, about ensuring each DPL +1 such a change | 15:18 |
| TheJulia | Yeah, I just wanted to stress the need for that delineation | 15:19 |
| frickler | TheJulia: the TC (or maybe some election official) in my idea would only propose a change to drop the old DPL liaisons. then the actually involved persons could either nack that to keep the status quo or propose a followup if changes are needed or they missed the deadline | 15:19 |
| noonedeadpunk | yup, was thinking exactly about that | 15:19 |
| frickler | it might actually make sense to have the same deadline as for PTL candidacies for this I think | 15:19 |
| noonedeadpunk | (was confirming Jay's statement) | 15:20 |
| TheJulia | I think the TC should just wipe it out each cycle and force re-registration/re-volunteering | 15:20 |
| TheJulia | but there are fine details in that and it could work out in many different ways when looking at practical process | 15:20 |
| TheJulia | if nobody acks/nacks, that is a sign of a problem | 15:21 |
| TheJulia | and if that is stuck in a forever review, then what does that *really* provide feedback/insight of | 15:21 |
| frickler | well the removal would be reviewed by the TC with the usual timing, so the default action if no DPL reacts would be the project becoming leaderless once the deadline ends | 15:22 |
| frickler | that would then duplicate the event of no new PTL candidacy being submitted during the application period | 15:23 |
| JayF | election nomination period starts => DPL renewal patch does up | 15:23 |
| TheJulia | usual timing might not work well for countries with 1+ week holidays | 15:23 |
| JayF | that would give several weeks to reassert they want to remain DPL | 15:23 |
| TheJulia | Just something to also think about | 15:23 |
| TheJulia | JayF: that seems reasonable | 15:23 |
| JayF | nom period start to election period completion is 2wks+ | 15:23 |
| TheJulia | yup | 15:23 |
| frickler | if you think 2 weeks isn't enough, the same objection would hold for PTL elections? | 15:24 |
| JayF | I think it's been raised around PTL elections in the past, too | 15:24 |
| TheJulia | it has, multiple times | 15:25 |
| TheJulia | "sorry I was on vacation" coupled with "I took a vacation along side some holidays in my country" | 15:25 |
| TheJulia | it happens | 15:25 |
| frickler | ok, but that's another discussion then, isn't it? applying the same timing rules from PTL candidacy to DPL refreshing sounds just fair to me, a change should apply to both | 15:26 |
| TheJulia | With the board, I've had a couple cases where a director chimes in after 1.5-2 weeks apologizing because of work trip plus vacation plus a holiday. Stuff stacks up and not everyone takes the same holidays. :) | 15:26 |
| TheJulia | Well, if memory serves, it was originally a 1 week window | 15:27 |
| TheJulia | and I think things got better | 15:27 |
| TheJulia | The key being: "just don't expect people to respond in under 1 week" | 15:28 |
| fungi | also if the schedule is announced and published far enough in advance, people have a chance to notice that the deadline is going to occur while they're out of pocket | 15:29 |
| TheJulia | bingo, and sometimes they do, but lists never get shorter when your getting ready for any immovable date. | 15:29 |
| frickler | also the exact schedule for elections has been announced on pretty short notice recently | 15:31 |
| fungi | yes, we used to decide on election scheduling as soon as we knew upcoming release dates | 15:31 |
| frickler | otoh, I think we only received two late candidacies this cycle, so not too large of an issue I guess | 15:36 |
| TheJulia | I remember once when it was a week, we had like 7-ish | 15:36 |
| TheJulia | that seemed... really bad. | 15:37 |
| noonedeadpunk | yeah, this time PTG has overlapped with school vacations, not elections... | 16:03 |
| gmann | we can do it each cycle or or a year. I wrote in yesterday discussion in etherpad to propose something about it and we can review that. | 16:03 |
| bauzas | fwiw, every other release election is a challenge for me, as I'm usually taking August off :) | 17:01 |
| bauzas | but I got used to prepare my ballot :) | 17:01 |
| frickler | is it possible to submit the candidacy review beforehand? | 17:04 |
| fungi | yes | 17:06 |
| fungi | the only gotcha is that the directory structure may not be created yet, but you can predict it | 17:06 |
| fungi | ideally the election officials would create it far ahead of time, but that gets back to the advance scheduling point | 17:07 |
| fungi | note that it can't be merged prior to the start of the nominations period, but it can be proposed and then no further action on the part of the candidate should be required | 17:07 |
| clarkb | side note on interns feeling that "this isn't python" my experience has been you'll run into that with almost every job and ever language. Development norms build in pockets around their developers and learning to adapt to the what is going on around you is one of the valuable pieces of having internships (at least it was when I was doing them, suddenly a wild expect and perl | 18:04 |
| clarkb | appear manage those switches or damn we're using a C compiler for arm that is almost as old as I am because the FAA says so | 18:04 |
| JayF | clarkb: yeah, with my MLH fellow this cycle (CID, who has been excellent), I told him most of this pain is stuff you feel starting in any job/codebase with established norms | 18:04 |
| JayF | clarkb: it just reflects the reality | 18:05 |
| clarkb | that isn't to say we can't do better, but I don't think "needing to adapt to local dev norms" is a reason | 18:05 |
| JayF | **it just reflects the painful reality of onboarding to a new codebase | 18:05 |
| clarkb | yup exactly | 18:05 |
| JayF | I view it less of a binary and more of a venn diagram | 18:05 |
| JayF | and right now I think we've diverged more than is healthy, but that's just like, my opinion, man ;) | 18:05 |
| JayF | eventlet migration will help that 1000000x more than any style changes imo | 18:05 |
| fungi | i think we've diverged as much as we needed to (or rather, the divergence wasn't entirely of our making), but we can still all find common ground to try to come back together | 18:06 |
| JayF | Honestly part of my frustration (and this can be seen in the topics I've focused on in governance) is that this feels too much like the giant megacorps I worked for | 18:06 |
| clarkb | a lot of the same issues arise for the exact same reasons | 18:07 |
| JayF | where making the project turn takes so long that unless you're visioning out 3,5,10 years, you're never going to get pointed in the right direction | 18:07 |
| JayF | and that also means I don't neccesarily know right now how effective some of the changes we have made/are making are, and may not know for a long time | 18:07 |
| fungi | like i said in the session, we proposed a lot of solutions to the broader python community for the growing pains we faced, and were told that those weren't problems anyone else had. turns out they should have added "yet" but also they completely forgot (or didn't like to admit) that we'd already brought up solutions when it eventually happened | 18:08 |
| fungi | there are some places we actually got traction, like pip's -c option, but even then the current maintainers are trying to disappear a lot of that history and rewrite it in their own image | 18:09 |
| clarkb | we still have issues like that too. It wasn't that long ago that I think we finally convinced pypi to stop the broken fallback behavior when there were backend errors | 18:09 |
| JayF | Oh, I share those frustrations, but they don't lead to anything actionable :( | 18:09 |
| JayF | I try really, really hard to keep oriented forward because understanding history is useful for preventing the repeating of it, but often the feelings associated are not as helpful and in fact are fuel to burnout | 18:10 |
| JayF | We're where we are now, all we can control at this point is what we do from this position | 18:10 |
| fungi | indeed they don't. i just want to point out that it's not as if we haven't tried to find common ground, and it's hard to expect one established community to completely abandon its norms in order to adopt those of another community that previously seemed contemptuous of the desire to even establish norms for such things | 18:11 |
| fungi | "oh you're right we did need that after all, but we're going to do it completely differently, sorry!" | 18:12 |
| JayF | I agree-ish in the short/medium term. In the long term (assuming resources to do it; which is where this if statement fails for us), it's better for both OpenStack and the overall OSS/python community if we are the "bigger person" so to speak and try to move in the direction the community is going ... even if the reason we have to move is because of something someone else did | 18:13 |
| fungi | i don't actually hold any resentment, simply acknowledging basic inertia | 18:14 |
| clarkb | I wonder how often projects like linux run into similar discussion (I know they recently started adding rust module binding stuff for example so it does happen there). But they for example are gpl v2. Not v2 or v3 or v3. Just v2. There are reasons and community norms behind that. They write most everything in C not C++ (or C+ etc). That C has a very specific style. Some of that | 18:15 |
| clarkb | gets insulated from external norms due to being the kernel so you're the layer under syscalls and libc everyone else is using | 18:15 |
| JayF | fungi: fwiw, I don't think you do. I know I do, a little though :D | 18:16 |
| opendevreview | Goutham Pacha Ravi proposed openstack/governance master: Add gouthamr's nomintion to TC Chair for 2024.2 https://review.opendev.org/c/openstack/governance/+/915754 | 19:57 |
| * gouthamr gah | 19:59 | |
| opendevreview | Goutham Pacha Ravi proposed openstack/governance master: Add gouthamr's nomination to TC Chair for 2024.2 https://review.opendev.org/c/openstack/governance/+/915754 | 19:59 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!