| TheJulia | gouthamr: Yes, many words to be written, but that likely won’t happen until next week, fwiw. | 03:36 |
|---|---|---|
| TheJulia | gouthamr: That was in regards to shanghai in general | 03:37 |
| TheJulia | Just wearing a board hat, and sort of echoing what I’ve heard other multiple board members say: We would like to embrace innovation and evolution. If there is a path to accept and extend, cool. Maintenance is also critical, i.e. you cannot torpedo the existing project outright. A path *must* exist. Understand that some additional work will be required and it may require collaboration with the open dev folks to move things along. That | 03:54 |
| TheJulia | is the cost of any contributor trying to bring a new language in. It doesn’t seem like an awful path to have a new project which is the “v4 auth”. The key is to move forward, extend trust, build community. | 03:54 |
| noonedeadpunk | I have reflected on my feelings from the discussion, and I think the reason why I am so sceptical, is that the approach is a repeating pattern. This exact thing has already happened with ansible-sig, which remained unmainintained basically for couple of years for same reasons | 07:00 |
| noonedeadpunk | that it should not be futher evolved, because it should be re-written or generated from scratch, that there is no reason to bring any new modules or features with current code shape | 07:01 |
| noonedeadpunk | none of these promises has arrived, but contributors were alienated, users become dissapointed in no tracktion happening | 07:03 |
| noonedeadpunk | And I would say that in case of new project, or new language, if there is an active community and bunch of interested people working towards the same goal - it makes sense to emerge. But if it comes at a cost of splitting already stretched thin existing community, I am not sure this is actually an evolution | 07:05 |
| fungi | tc-members: please see my last comment on https://review.opendev.org/c/openstack/project-config/+/988094 | 16:10 |
| JayF | So I had an interesting chat today -- I sometimes think we change things and don't always assume that they make a difference. | 16:10 |
| JayF | Apparently leaders at my downstream are seeing "unmaintained" beside older releases and that is concerning to some folks as they wanna run maintained software. | 16:11 |
| JayF | Obviously UM means "community doesn't promise to maintain" and GR-OSS pays me to help them backport anything that doesn't get there, so it's not *really* targeted at us | 16:11 |
| fungi | tc-members: regarding 988094, your intervention is needed in order to make a delegation decision | 16:11 |
| JayF | but the messaging is starting to have an impact, and that's a good thing | 16:11 |
| fungi | JayF: very cool, sounds like it's actually working the way we wanted in that case | 16:13 |
| cardoe | fungi: thanks for the heads up | 16:13 |
| JayF | Yes, exactly. It's properly communicating that this branch teeters on the edge of being insecure. | 16:13 |
| JayF | I told my folks as long as I'm here I'll make sure they get backports even if they aren't official ones, but I hope other folks see that and either hire a "me" to help upstream support it longer, or upgrade :D | 16:14 |
| cardoe | fungi: so one funky thing for me I assume https://review.opendev.org/c/openstack/nova/+/986141 is the winning proposal (the project-config links to them all) and it's the one that's +1'd by multiple folks without -1 is that it mentions nova-approvers and nova-reviewers groups but the project-config has nova-core and nova-reviewers | 16:15 |
| fungi | JayF: also obviously if a vendor is carrying downstream backports and maintaining a fork of an old version, then their fork is "maintained" it's merely upstream's old branches which are unmaintained | 16:16 |
| fungi | cardoe: 988094 was the one which got a +1 from the ptl, not 986141 | 16:17 |
| JayF | fungi: yeah, in the case of my downstream they use more or less upstream code, and I have backported OSSA stuff in the past for them (or suggested alternate workarounds). So in their case it's more I gave my downstream peer a problem to go prove we maintain it... but in the big picture it means our messaging is working :D | 16:17 |
| frickler | tc-members: to me the situation is clear: we have delegated all power nova-wise to Uggla, so that's where the decision whom to add lies, both as reviewers and cores. and I'm kind of confused that we even need to have this discussion | 16:17 |
| cardoe | fungi: 988094 links to 986141 | 16:18 |
| cardoe | frickler: I agree. | 16:19 |
| cardoe | tc-members: we should give it to Uggla and let the PTL sort this out the rest of the way. | 16:19 |
| dansmith | TBH, I take Uggla's comment as "if" not "that" the core team has agreed | 16:20 |
| dansmith | I've been pretty out of it the last few weeks but last I sort of knew this to be entirely unclear consensus-wise | 16:20 |
| fungi | cardoe: my understanding of the naming skew between the proposal and the implementation is consistency with other teams and clarity (calling a group that can't add workflow +1 approved "approvers" is confusing at best) | 16:20 |
| fungi | if the plan going forward is to have nova-approvers granted workflow +1 and nova-reviewers granted only code-review +2 then it's a fairly minor additional patch later to add a new nova-approvers group to replace the nova-core group i guess | 16:22 |
| fungi | cardoe: yeah, so reading the proposed policy in 986141, 988094 is half of the implementation and then the other half would be effectively replacing the nova-core group with a nova-approvers group | 16:26 |
| fungi | but is essentially just a name change, not any adjustment in permissions | 16:27 |
| cardoe | Yeah it all seems sensible to me. | 16:31 |
| Uggla | Since I am not currently a Nova core reviewer, I do not know whether there have been any private discussions among the existing core team about this proposal. | 17:03 |
| Uggla | I had also not understood that the administration of these groups was intended to be delegated to the PTL. I am not opposed to taking on that responsibility, provided the current core members are comfortable with it. | 17:03 |
| Uggla | However, I would distinguish the administrative management of the groups from decisions about their membership. In my view, adding or removing members should require consensus among the existing cores/approvers, rather than being decided by the PTL alone. | 17:03 |
| fungi | Uggla: deciding to delegate those decisions to some process within the team is entirely normal, yes. ultimately it's still the ptl's decision as to how to delegate their responsibilities as team leader | 17:06 |
| fungi | https://docs.openstack.org/project-team-guide/ptl.html#core-member-maintenance covers this pretty well, i think | 17:07 |
| Uggla | Thanks, understood. I hadn’t realized that managing these groups was ultimately a PTL responsibility. I’m fine with taking that on, and my preference would be to base membership changes on consensus among the existing cores/approvers. | 17:19 |
| fungi | i highly recommend (re?)reading at least the ptl chapter of the project teams guide and thinking about how you manage or delegate the various responsibilities listed there | 17:31 |
| fungi | odds are you're probably already doing that through patterns and workflows you've inherited from your predecessors, but it helps to be conscious of them | 17:32 |
| frickler | ok, since the current situation made the whole TC nova-reviewers, which I find even more unfortunate, I've gone ahead and added Uggla and dropped the TC afterwards. if any of the tc-members disagrees, feel free to ask me or any other infra-root for a correction | 17:45 |
| fungi | thanks! i just didn't want to be the one making that decision since i'm not on the tc, but happy to take further action as directed by the tc | 17:46 |
| cardoe | frickler: sounds good to me | 17:48 |
| fungi | in the future, if Uggla wants someone different added as initial group members, designating a tact sig liaison for the nova team would be the simplest a way around that | 17:49 |
| * gouthamr is reading scrollback | 17:49 | |
| fungi | we haven't really had official tact sig liaisons for ptl model teams in the past, but now that we're tracking other kinds of liaisons in governance it wouldn't be hard to add | 17:50 |
| * gouthamr agrees with the comment to gmaan | 17:51 | |
| gmaan | frickler: indeed, having other than nova current team to +2 group seems strange and risky for me | 17:54 |
| gmaan | not sure why existing team is not considered as responsible for the new sub group that team is making | 17:55 |
| fungi | well, they didn't have the ability to approve changes, and their +2 votes would disappear as soon as the tech-committee was no longer included | 17:55 |
| gouthamr | hmmm, i don't want to muddy the waters here.. i will stand by the action frickler took.. Uggla: please do read up the PTL responsibilities; you're probably already doing all of this. honestly, if the nova core team would like to control this without you, DPL is what is better suited for the project team. You are the PTL now, and you will be for the Indri cycle, so i expect any core-reviewer driven action to occur only in 2027.2 if it | 17:55 |
| gouthamr | does | 17:55 |
| gmaan | current nova-core is controlled without PTL right? and so does it was for glance in past | 17:56 |
| gouthamr | Uggla: fungi may have mentioned this elsewhere, but, remember, you must control who can get added/removed from the core team | 17:56 |
| fungi | gmaan: effectively but not officially | 17:56 |
| gmaan | well, its strange to me. I am not sure if stephenfin was not clear enough about ths new subgroup that nova-core is the initial member of this group | 17:57 |
| fungi | if Uggla wanted to replace the entire nova-core team today, that's officially possible by the power granted through election to ptl | 17:57 |
| gmaan | if not officially then it conflict with the 'a non-core to be PTL' | 17:57 |
| fungi | stephenfin is also not the nova ptl, so can't make that decision. only Uggla can (or has to clearly delegate that decision) | 17:57 |
| gmaan | fungi: ok then this is a loop hole in out process either we should stop non-core to be PTL or let core group be managed by core members | 17:58 |
| fungi | gmaan: or trust the people you elect. this is not a loophole, it's an intentionally designed governance relief valve by which the contributors of any team can elect a new leader to remove the current core reviewers | 17:59 |
| gmaan | is it somehwre officialy stated that 'core team is manaaged by the existing core membes' | 17:59 |
| gmaan | trust is fine which is why we have Uggla or glance PTL in fast who was non core and i feel that is good | 17:59 |
| fungi | it is implicit from the tc charter. it would have to be explicitly mentioned somewhere if that wasn't the case | 18:00 |
| gmaan | but you said officially they can remove all core which is technical loop hole to me | 18:00 |
| fungi | the ptl is the person in charge of deciding how the team operates, full stop. they can delegate that responsibility, but it's their choicew | 18:00 |
| fungi | gmaan: not a loophole, actually intentional to prevent capture by a self-perpetuating oligarchy that makes choices counter to the will of the contributors | 18:01 |
| gmaan | anyways, having tc +2 on nova repos seems odd to me.If it is not ok to add nova-core to their sub group them either we should delete the group immidiatly (cc stephenfin ) 2. keep it empty until the initial members things is resolved | 18:02 |
| fungi | well, they don't at this point, so whatever limited perception issue that might have created is resolved already | 18:02 |
| gmaan | ok,thanks | 18:03 |
| gouthamr | fungi: maybe we use the "owners" concept of gerrit groups to enforce some of this? how is that populated today? | 18:05 |
| frickler | so one technical note: the "group is managed by its members" part is implemented in gerrit by the owner of the group getting set to the group itself | 18:05 |
| gouthamr | jinx | 18:05 |
| frickler | gouthamr: indeed, I was just going to write a second note: | 18:06 |
| fungi | yes, we do use that in a variety of places | 18:06 |
| fungi | it's possible to e.g. set Uggla as the owner of nova-reviewers and not as a member, but then the owner can add themselves as a member anyway | 18:06 |
| frickler | if I understand the sentiment correctly, the nova-core group would like the nova-reviewers group to be owned by nova-core, not be self-owned | 18:06 |
| gouthamr | https://review.opendev.org/admin/groups/election-core is an example, the "tech-committee" group owns this | 18:06 |
| fungi | if uggla decides to make nova-core the owner of nova-reviewers that's fine. it doesn't address the original dilemma however | 18:07 |
| gouthamr | is that done on the gerrit-ui alone? | 18:08 |
| gouthamr | i.e., not enforced via project-config? | 18:08 |
| fungi | no, we don't have any direct management of gerrit group settings in project-config | 18:09 |
| fungi | i did look and am not seeing a way to set a group owner through gerrit's ssh api, though it can be done through the webui or rest api | 18:09 |
| gmaan | frickler: yes, that was the original proposal and agreement by nova team on nova-reviewer path proposed by stephenfin | 18:10 |
| fungi | it looks like the `gerrit create-group` ssh api command has a `--owner` option but that assumes manual pre-creation of the group if we were to do something with that | 18:10 |
| gmaan | and if that is implemented this way (nova-core cannot be member of it or control this group) then it seems a trap to me :) | 18:10 |
| fungi | gmaan: the process to do that is Uggla is made an initial member of the nova-reviewers group, Uggla sets nova-core as the owner of nova-reviewers, then optionally self-removes after | 18:11 |
| gmaan | owner/memebr thigns is ok but we just need to make sure we do not change the symantic or existing +2 group which is what team should decide | 18:12 |
| fungi | as a fallback, at any time the team's ptl or tact sig liaison (or the tc) can ask someone on the tact sig to make those configuration adjustments | 18:13 |
| gmaan | fungi: yeah that sems ok to me now. I am just wondering if any implementation change in gerrit or so making change in +2 permissions without nova team discussion. whicih seems it does as Uggla added as initial member. But team trust Uggla so less risky now | 18:13 |
| JayF | It's not clear, at this point in the discussion, if folks are disagreeing on the end state, how to get there, or both? | 18:14 |
| gmaan | I mean Uggla can bring tyhis in nova and add nova-core or remove himself or continue added, whatever it is but with nova team discussion | 18:14 |
| JayF | (or nothing, as can sometimes happen in these -tc chats) | 18:14 |
| gmaan | my main concern here is 'we are allowing non core to be PTL which is great' but have a loop hole to grant non-core to core permission via PTL path even for short/initial term when new groups created or so | 18:16 |
| fungi | ultimately it had the desired effect of getting someone on the tc to affirm that this is up to the ptl to decide, as the elected representative of the nova contributors | 18:16 |
| gmaan | I think with 'allow non-core to be PTL' we need to adjuts the PTL official responsiblity also? | 18:16 |
| fungi | gmaan: again, it's not a loophole (at least not in governance). it has been the intent since the beginning that ptls make these decisions, and can decide to make themselves a core reviewer (or anyone else) | 18:17 |
| gmaan | otherwise I am seeing PTL a default path to have core permission which can be risky for many case, till now we had trusted people in this catagory but we never know in future | 18:17 |
| frickler | gmaan: the PTL is allowed to become core by the TC anytime they choose so, with an option for the remainder of the team to avoid that | 18:17 |
| fungi | the ptl can decide not to be a core reviewer for their team, but that's the ptl's decision | 18:17 |
| frickler | s/with/without | 18:18 |
| frickler | except electing a different PTL next time | 18:18 |
| fungi | gmaan: well, yes, i thought it would be obvious that contributors shouldn't elect a representative they don't trust to lead the team, but maybe that's worth reiterating somewhere | 18:19 |
| gmaan | that is what can create issue on team side. if team choose a non-core PTL to lead them but not self-approve (self or via TC) the +2 permissions but later it happen | 18:19 |
| bauzas | sorry, wasn't paying attention to the conversation, but yeah this seems to me a good safety valve | 18:19 |
| bauzas | (fact that PTL can gain power over cores if required) | 18:19 |
| gmaan | they trust to lead them but not +2 yet. that was glance case and nova case | 18:19 |
| JayF | gmaan: fungi: This is why I start freaking out when governance diversity slips. There's a lot of power in PTL/TC, and just in practice we don't wield it much. | 18:20 |
| gmaan | lead should not mean +2 or merging code if it is then we have gap | 18:20 |
| fungi | that's an agreement the team comes to with their ptl, and the ptl is agreeing not to exercise certain assigned duties instead leaving them completely to delegates | 18:20 |
| bauzas | yeah, I defer that to be a project specific discussion | 18:21 |
| JayF | gmaan: I think it's wise of someone to not use power (to use PTL power to modify core group to unilaterally add themselves) even when they have it. But the power existing is important for structural reasons | 18:21 |
| gmaan | yes when trust is there and that is why it is not an issue till now | 18:21 |
| bauzas | I don't particularly want to remove the safety valve | 18:21 |
| bauzas | and yeah, this was implicit that being PTL gives you power over cores | 18:22 |
| JayF | yeah, the safety valve is a good thing, and it's a testament to our community that it's never been made to whistle :) | 18:22 |
| bauzas | with power comes great responsibilities and that's why we have trust | 18:22 |
| JayF | we disagree sometimes on what to do, or how to do it but folks in the community cooperate with the consensus | 18:22 |
| JayF | and that's how things keep working over time | 18:22 |
| fungi | when it comes to officially representing the team's decisions, it's still up to the ptl to convey those to the tc, the tact sig, and the rest of the community because, outside that team, the ptl is still recognized as the decision-maker | 18:22 |
| bauzas | right | 18:23 |
| bauzas | for that particular case we're talking about, I'm cool with letting Uggla choose what he wants to do for a starter for nova-approvers | 18:24 |
| bauzas | I'm not opinionated by that, | 18:24 |
| bauzas | I think he just wanted to express that he'd like the existing nova-core team define the process about adding new members to nova-approvers, which isn't yet agreed on the existing proposal | 18:25 |
| bauzas | but that's his choice | 18:26 |
| fungi | makes sense, and once the nova team comes to a decision, Uggla can ask someone on the tact sig to make configuration adjustments if needed | 18:32 |
| gouthamr | my takeaway: a lot of this is not really normal or apparent, so worth being explicit.. non core PTLs have been rare exceptions. we all see the value - it is great service for the team.. but, it needs us to write down a process so we don't run into fundamental questions like this. Maybe we need a TaCT liaison that is a core nominated for any team that has a non-core reviewer as a PTL. | 18:37 |
| bauzas | I personnally believe the existing process works | 18:54 |
| bauzas | but maybe the expectations that a PTL has power rights for nominations someone's else core isn't that known so I'd rather fix that by doc rather than a new process | 18:55 |
| gouthamr | bauzas: that part is written here: https://docs.openstack.org/project-team-guide/ptl.html#core-member-maintenance | 18:56 |
| bauzas | that's project team guide, not a governance doc hence my point | 18:57 |
| bauzas | people can think this doc as a guideline, not as someone enforced | 18:57 |
| bauzas | something* (not someone) | 18:58 |
| bauzas | let's make it clear that's not only a guideline and I'm cool | 18:58 |
| gouthamr | i'm unclear why you're pushing for this distinction between a guideline vs something on the charter | 19:04 |
| gouthamr | (i'm not pushing back, but, i want to know what we're not considering so we can fix this) | 19:05 |
| bauzas | I'm cool with the existing, I'm just noting that the existing can be misunderstood in terms of its possibilities, | 19:06 |
| bauzas | but on the other side, I don't particularly want that to be a new policy | 19:06 |
| bauzas | and I'm just saying the PTL guidelines are nice but are just guidelines, so maybe that's the root cause of the confusion | 19:07 |
| frickler | https://governance.openstack.org/tc/reference/charter.html#project-team-leads is the governance definition of PTL, does that help? | 19:13 |
| frickler | maybe https://governance.openstack.org/election/#elected-positions should reference that instead of https://docs.openstack.org/project-team-guide/ptl.html and then only have the latter as additional information | 19:14 |
| bauzas | yup, https://governance.openstack.org/tc/reference/charter.html#project-team-leads could be slightly amended by saying something about the mandate of the PTL for electing new cores eventually if required, but that's a big maybe (I don't know if that's really worth the effort) | 19:18 |
| fungi | that's what i meant when i said the charter would have to explicitly state if a ptl didn't have that responsibility, because by default it gives them full responsibility for decisions about how the team operates (and that includes deciding who the core reviewers are) | 19:29 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!