| opendevreview | Tony Breeds proposed openstack/election master: Exclude projects under the distributed leader model https://review.opendev.org/c/openstack/election/+/887668 | 11:32 |
|---|---|---|
| opendevreview | Tony Breeds proposed openstack/election master: Add a Sorting function. https://review.opendev.org/c/openstack/election/+/887669 | 11:32 |
| opendevreview | Tony Breeds proposed openstack/election master: Add a tool to update the releases repo https://review.opendev.org/c/openstack/election/+/887690 | 11:32 |
| opendevreview | Tony Breeds proposed openstack/election master: Exclude projects under the distributed leader model https://review.opendev.org/c/openstack/election/+/887668 | 12:19 |
| opendevreview | Tony Breeds proposed openstack/election master: Add a Sorting function. https://review.opendev.org/c/openstack/election/+/887669 | 12:19 |
| opendevreview | Tony Breeds proposed openstack/election master: Add a tool to update the releases repo https://review.opendev.org/c/openstack/election/+/887690 | 12:19 |
| knikolla | o/ | 14:52 |
| JayF | o/ | 14:54 |
| JayF | FYI: I will be out of town travelling (to London!) next week and will be generally unavailable in IRC and out of my usual TZ. If you need something urgently, please send an email. | 15:45 |
| gmann | tc-members: I think we need to discuss and conclude the EM future. and get Cinder team in agreement to wait until TC decide on EM things. It seems they want to progress on marking all EM to EOL for cinder https://lists.openstack.org/pipermail/openstack-discuss/2023-July/034335.html | 17:19 |
| knikolla | gmann: yep, agree. I'm planning to send out 2 proposal by EOD tomorrow and we can discuss during next TC meeting. | 17:20 |
| gmann | and we need to talk to cinder team also to wait until we make any decision. that is important | 17:21 |
| fungi | to be clear though, the current stable maintenance policy already says they can do that. does this mean the policy was written to allow behaviors counter to expectations? | 17:25 |
| JayF | Yeah, I'm not sure how we intend to convince them not to retire their EM unless someone on the TC is going to be that EM-extending volunteer. | 17:33 |
| JayF | We can't setup systems like EM, with a built in carrot (community supports it, it stays supported) and stick (community doesn't support it, it goes away) and then circumvent the consequences on the backend from nobody stepping up to maintain those old branches. | 17:34 |
| JayF | If someone feels pain from cinder retiring EM early; that's a sign that someone should step up and volunteer the effort needed to maintain it. | 17:34 |
| gmann | its not about cinder only here, it is about consistency in OpenStack stable policy implementation across projects. it does not matter we have policy issue or coordination issue, impact is on operators: | 17:38 |
| gmann | 1. it will stop integration testing for all other projects need cinder, it will be unit/functional tests only (I do not think we want to make more work on QA to take/keep cinder EOL tag working in integration testing) | 17:38 |
| gmann | 2. If we end up that there is any CVE fix in other project need backport in cinder project then that project has no way to EOL their branch. | 17:39 |
| gmann | this is not normal way where a project EOLing all EM, this is happening first time and whatever the reason is it is clearly introduce inconsistency for operators and we need to stop/solve that | 17:40 |
| fungi | so to circle back around to my initial question, where the stable policy says project teams can choose to eol branches at any time once they reach em, we don't actually mean that? | 17:40 |
| knikolla | ++, the current policy as written allows project teams to EOL their projects when they want. Any new policy that we approve is also not going to require a project team to maintain their EM branches. | 17:41 |
| gmann | yes it is policy unclear communication I think we all agreed to that and fail to communicate EM clearly | 17:41 |
| gmann | yeah, that is what the issue is, policy written unclear and we made mistake there. is that enough reason to make our operator suffer for this inconsistency ? | 17:42 |
| knikolla | Therefore, based on my message above, I'm okay with Cinder EOL-ing their branches before the TC arrives at a decision about EM in general. | 17:43 |
| JayF | I don't think that's the issue, gmann | 17:43 |
| JayF | The issue is that there is no group of humans willing to maintain older cinder releases. | 17:43 |
| gmann | actual expectation is oldest EMs going to EOL one by one, I do not think anyone in sydney summit discussion considered this situation where a project want to EOL all EM | 17:43 |
| JayF | No matter how we reword the policy, until we find someone willing to perform that effort it won't be performed. | 17:43 |
| knikolla | ++ JayF. | 17:43 |
| fungi | i'm still unclear on what suffering this inflicts on operators when the choice is between the branch being unmaintained with no real signal that it's effectively abandoned vs being clearly eol | 17:43 |
| gmann | knikolla: if cinder EOL then how you keep nova not to do? how you test? | 17:44 |
| knikolla | gmann: Nova can use the last known good version of Cinder. If they want to patch, they can carry over patches to that old version. The burden is on Nova, not on Cinder. | 17:45 |
| gmann | I am seeing the consensus clearly here that if cinder EOL all EM then all integrated project are force/endup doing the same | 17:45 |
| fungi | so you're saying nova developers get to take over maintaining cinder's em branches? | 17:45 |
| knikolla | By carry over I mean keep them in their repo and apply through git. | 17:45 |
| gmann | knikolla: that is why they will have to EOL all their EM. | 17:45 |
| JayF | If there is someone invested enough in Nova stable branches to support them back far, they should find that same investment if glance is a depednency | 17:46 |
| fungi | (or cinder in this case) | 17:46 |
| gmann | knikolla: do you think any project can do that? as they have less bandwidth to maintain current EM process , you think they can do this extra things? | 17:46 |
| JayF | I think don't think they can do those extra things, but neither can cinder by their own admission | 17:46 |
| knikolla | gmann: I don't think they can or want. But I do want to let them do it if they somehow can. | 17:46 |
| gmann | we know putting extra work for Em maintenance is not possible, just expecting project to do more is mistake. it will end up all EM to EOL | 17:47 |
| JayF | at some point accepting that fewer supported releases may be a semi-obvious follow on from less overall project participating | 17:47 |
| JayF | **participation | 17:47 |
| fungi | if having an eol dependency means you can't maintain your own project, then your choice is clear: either take on maintenance of that dependency or drop maintenance for your project | 17:47 |
| knikolla | fungi: ++ | 17:47 |
| gmann | I am not sure if there will be any benefits of TC EM solution if cinder make all EM to EOL. all project will have to do that and that is all | 17:48 |
| fungi | the "extra work" is already there. you're saying force extra work for one group of people in order to avoid making extra work (or a hard choice) for another group of people | 17:48 |
| JayF | From a TC perspective, we have a project saying "we do not have the resources to maintain these branches" -- we can't force them to have those resources, or to expend resources they don't have | 17:48 |
| gmann | fungi: it is integrated projects in openstack not any external deps or standalone case | 17:48 |
| gmann | and i think that is why we are here to keep consistency in OpenStack projects | 17:49 |
| JayF | If supporting releases for longer than 18 months is so desirable that we can't accept the retirement of EM branches, we should consider an "LTS" style system with less overall things to maintain | 17:49 |
| fungi | i'm aware. but how can nova continue to support its stable/wallaby branch if cinder's is not maintained? their options are to either become the maintainers of that branch or drop their own | 17:49 |
| gmann | JayF: that is what the issue here and we tried/trying to solve it if things become inconsistent. | 17:49 |
| fungi | the cinder team already has said it doesn't want to maintain those branches and asserted that nobody else is willing to either. are you saying nova developers will do it? | 17:50 |
| knikolla | We can't force anyone to maintain anything, honestly. Even if we as the TC go and say, hey Cinder, maintain your EM branches. They can't if they don't have the resources. | 17:50 |
| gmann | current EM policy/process is problem and we need to find some solution before project take their own decision to delete all EM and introduce inconsistency | 17:50 |
| JayF | I'm onboard to trying to solve that consistency, I don't think any route to it involves us telling the Cinder team what they should or should not retire. It should be a helping hand or an acceptance of the less-supported reality of those old branches. | 17:51 |
| gmann | that is why i am saying we have to do it before that happen. if cinder goes to EOL all EM then I do not think any benefits of TC decision. | 17:51 |
| gmann | then everything in our policy is good and let projects to do on EM. | 17:52 |
| knikolla | gmann: ok, so hypothetically, what if TC decides Cinder can't EOL their EM branches? | 17:52 |
| knikolla | What does that change? | 17:52 |
| gmann | knikolla: I am saying we need a consistent decision here, if TC delaying that then yes we need to ask cinder to wait until TC have any agreement on what to do on EM | 17:53 |
| gmann | we might agree on what cinder is proposing but we need to do that before | 17:53 |
| gmann | if ship is sailed then not mush benefits of discussing the problem | 17:54 |
| fungi | if the demand is for a consistent decision, probably the only completely consistent decision that can be reached (reflecting the reality of the situation) is to stop doing em across all projects | 17:54 |
| knikolla | fungi: ++ | 17:54 |
| gmann | cinder marking all their EM to EOL is ship sailed for me even some of us can expect other project to do more work for their EM but that is not practical | 17:55 |
| knikolla | All paths start from accepting that reality and trying to create a scenario where some projects that have the resources, can maintain releases for longer than the rest of openstack | 17:55 |
| gmann | fungi: yeah, i am ok with that now but it should happen with proper discussion and agreement not the way it is happening now | 17:55 |
| fungi | the alternative i see is to let the cinder team go forward with their (currently allowed by policy) decision, and then see where that leaves the other projects and whether they want to do the additional work to have em branches which are testing with frozen unmaintained cinder versions or follow suit and close theirs too | 17:56 |
| JayF | That discussion not happening in the past is an indictment of the TC in some ways | 17:56 |
| JayF | we've been sitting on the status quo of a policy that assumes huge amounts of interested contributors | 17:56 |
| JayF | even though we knew it was not reflective of the reality | 17:56 |
| gmann | I was expecting that to happen in forum sessions or in ML after that but it did not happen. | 17:56 |
| gmann | I was in impression that Cinder team is waiting for that and will not proceed on EOL but that is also not the case | 17:57 |
| JayF | I appreciate Cinder making the hard move that we haven't, of admitting what they are and aren't maintaining pretty up front | 17:57 |
| fungi | and also remember they're still asking for input on that decision | 17:57 |
| gmann | JayF: I am not saying maintain EM, i am saying if it happen from project side and other project force to do that then it clear TC failure to make policy/process for this problem | 17:58 |
| JayF | I think we agree on that point, that we've waited too long for a policy/process improvement here | 17:58 |
| fungi | the tc rushing to block their ability to make a choice for themselves rather than providing them with earnest feedback seems maybe even a little hostile | 17:58 |
| gmann | yeah, they are asking but they clearly said TC discussion on that is separate thing and their proposal is not waiting for that | 17:58 |
| gmann | patches are proposed also | 17:58 |
| JayF | Admittedly if they were in the forum session to get guidance | 17:59 |
| JayF | that was not anywhere near getting to an endpoint | 17:59 |
| gmann | that is why I am saying TC has to react here fast | 17:59 |
| JayF | so I can appreciate their bias for action in the face of seemingly-endless discussion | 17:59 |
| knikolla | gmann: ++, it is completely a failure of the TC which pushed the can down the road and put bandaids on the problem throughout the years rather than face it head-on. | 17:59 |
| fungi | that session could have blocked out a full day and not reached a conclusion because the two sides in the discussion don't share a common view of reality | 17:59 |
| JayF | fungi: I'm interested in you going further on that track/topic | 18:00 |
| gmann | we have solved such issue with adhoc meeting in past and avoid inconsistency, that is one way here | 18:00 |
| fungi | JayF: the people who say we should keep branches open because it allows contributors to do something that no contributors are interested in doing is rooted in a disbelief of the (demonstrated) absence of interest in anyone actually doing that work | 18:01 |
| gmann | moving to OFTC network is one good example. where projects wanted to move to different platforms and before that happen TC had those adhoc meeting and decided consistent way | 18:01 |
| fungi | JayF: whereas we also have active contributors saying that continuing to prop up the fantasy of extended maintenance contributions is actively harming their ability to maintain newer versions of their project | 18:03 |
| JayF | fungi: "EM is a fantasy" is pretty close to my interpretation of the reality in some projects now | 18:04 |
| fungi | the only way i see to get both camps on the same page is to either conclusively prove or disprove the existence of extended maintainers | 18:04 |
| fungi | because in the end it boils down to a cost/benefit analysis | 18:05 |
| JayF | I'll let you know when I meet someone maintaining an Ironic EM branch that isn't already a general contributor in the community | 18:05 |
| fungi | is the benefit of hoping someone will take on maintenance of those branches greater than the cost to the actual contributors? | 18:05 |
| JayF | (hint: a large majority of EM-backported ironic driver fixes were backported by me, because I didn't want people running old broken crap) | 18:05 |
| JayF | fungi: the real thing is, there are people who said at the forum -- I'm in this group -- that if you have something you say is "Ironic X" and it's bad, it reflects on me | 18:06 |
| gmann | I think we already discussed/know the problem and need to find the solution. that is what community/opratator expect from us | 18:06 |
| JayF | fungi: there is no EM solution where me, as a person who is deeply personally invested in Ironic, would be able to ignore it being maintained badly | 18:06 |
| knikolla | ++ JayF. It is still Ironic and bears the Ironic brand. | 18:07 |
| knikolla | One of the proposals and the one I'm pushing for boils down to: | 18:10 |
| knikolla | Projects are required to opt-in every cycle to keep a project under extended maintenance. If a project doesn’t opt-in the EM branch is automatically closed.... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/EXZeGcNJyEYyuBtZISoeJCtL>) | 18:10 |
| fungi | also implied in that proposal is that the onus is on the extended maintainers of that project to keep any testing they deem important working, which may mean switching integration jobs from pulling branches of deps to pulling tags (either release or eol tags) for those instead | 18:16 |
| knikolla | ++. It starts from the assumption that core team == em team. | 18:16 |
| knikolla | Or rather the reality. | 18:17 |
| fungi | it also places the costs squarely on the shoulders of the people making the decision of whether those costs are outweighed by the benefits they provide | 18:17 |
| fungi | when one group of people are allowed to make a decision which foists the costs of their choice onto another group of people, their perceptions of that cost vs benefit will invariably have a skewed perspective | 18:19 |
| JayF | Bluntly, I'm not sure this proposal does prevent this, as gmann has somewhat shone a light on | 18:19 |
| JayF | because of the interdependant nature of openstack projects, there is absolutely going to be friction and lost goodwill when a project others' depend on EOL | 18:20 |
| gmann | yeah, not sure how this solve the issue? this is what the current way is. project check EM status and make them EOL. solution here we need is how we can do that in coordinated way. | 18:20 |
| JayF | and when that causes a domino-EOL effect due to a bug which needs a change in $EOLService to fix, it's going to cause a lot of discord | 18:20 |
| JayF | I'm not even saying I disagree with the proposal, it's hugely better than the status quo | 18:20 |
| knikolla | This changes EM from being the rule to the exception. | 18:20 |
| JayF | but we're still putting the cores of the individual projects into a pinch | 18:20 |
| gmann | yeah | 18:20 |
| gmann | and un cordinated way of moving EM to EOL | 18:21 |
| JayF | I think there's no way in the current structure of OpenStack to really coordinate it | 18:21 |
| JayF | given we have projects ranging from Ironic, which could probably EM for a lot longer than others due to our standalone modes of testing | 18:22 |
| fungi | that proposal offers a way for a team to choose to continue maintaining something while bearing the costs of doing so, rather than relying on someone else (who may not exist) to shoulder some of that cost | 18:22 |
| JayF | to smaller teams which don't even do EM now | 18:22 |
| gmann | at least it can go gradually, oldest EM to EOL not like project A EOL all EM and other no and operators are confused with EM | 18:22 |
| gmann | what is what currently team is doing, 1. checking sttaus 2. do work and bearing the cost of maintenance. | 18:23 |
| gmann | *that is what | 18:23 |
| fungi | in your view, what is the limit on the number of em branches a team can choose to eol in a given time period, let's say in the course of one development cycle? | 18:23 |
| knikolla | We can coordinate on removing all EM branches and start from a clean slate. Or coordinate in removing old branches and blocking Cinder until we have caught up. | 18:23 |
| JayF | What is blocking cinder? Telling them "no, support these branches" (we don't really have this capability) or telling them "you have to keep your lack of maintenance quiet by keepign the branch open" (a form of lying to operators) | 18:25 |
| fungi | obviously the limit on number of em branches that can go eol in a cycle needs to be <=1 or the number of em branches will continue to grow, and <1 if you want them to be able to shrink at all | 18:25 |
| gmann | at least it should go gradually from oldest to latest EM not all simultaneously | 18:25 |
| JayF | This is sorta where I get hung up: until/unless you solve the problem of nobody who knows how wants to maintain Cinder andw e can't force them to" | 18:25 |
| fungi | er, >=1 or >1 | 18:25 |
| knikolla | ++ JayF. i consider the current EM branches mostly a lie. | 18:25 |
| JayF | ** This is sorta where I get hung up: until/unless you solve the problem of "nobody who knows how wants to maintain Cinder and we can't force them to" it all seems moot | 18:26 |
| fungi | gmann: sure, i'm asking you to define "gradually" | 18:26 |
| gmann | JayF: it is "we at community level trying to find some consistent solution so please wait for cinder next step" | 18:26 |
| gmann | fungi: what we used to do and doing currently. for example train going to EOL this cycle and next cycle few more | 18:26 |
| knikolla | gmann: the consistent solution is the “currently supported branches” policy. Those we support as an integrated release. | 18:26 |
| fungi | also what is the timebound you plan to put on making that decision, or are you asking the cinder team to wait indefinitely (and maybe forever, or just until they give up and move out of openstack or simply quit in favor of a project which allows them some autonomy)? | 18:27 |
| gmann | knikolla: we have EM concept in our policy which is problem and that is what we need to solve, kill them or find a consistent solution | 18:27 |
| fungi | gmann: what we've been doing is unsustainable. we've been eol'ing fewer than 1 branch a cycle, so the number of branches can grow without bound | 18:27 |
| gmann | “currently supported branches” is completely different thing here | 18:28 |
| knikolla | gmann: the em policy says it can go away any time right? | 18:28 |
| JayF | knikolla: to be explicit, because I know I've picked at it some: I'd RC+1 your proposal as written as a straightline improvement to existing EM policy, even if it's not a panacea | 18:28 |
| JayF | knikolla: and we need to be more willing to change policy in a better-but-not-perfect direction imo | 18:28 |
| gmann | fungi: yeah, and we can make them better instead of having few projects EOLing everything | 18:28 |
| gmann | knikolla: yeah, I am saying that is problem and we need to solve it :) | 18:28 |
| gmann | what our current policy allow us to do does not mean there is no problem | 18:29 |
| fungi | so a counterproposal to knikolla's clean-slate suggestion would be to eol... 2 branches per cycle (maybe at 3-month intervals) until we catch up to the number of branches we intend to maintain? | 18:29 |
| gmann | problem is EM policy and process and we need to solve them or just kill the EM concept | 18:29 |
| fungi | just trying to figure out what the *concrete* suggestions here are | 18:29 |
| JayF | fungi: My counter would be unless we get the Cinder team to change their mind, that's just choosing to lie about how cinder is supported for "n" cycles | 18:30 |
| fungi | also perhaps commit to having a decision for the cinder team by the end of july? after which they can proceed with their plan if the tc can't reach consensus before then? | 18:30 |
| gmann | I am not suggesting here anything that is what I am asking TC to act fast to discuss that. we are not at all starting the discussion and project started the work to kill EOL | 18:30 |
| JayF | committing to a shared deadline with the cinder team is a great idea actually | 18:30 |
| JayF | because it'll force us into taking action | 18:30 |
| gmann | I am saying "TC should act fast and conclude the things" as forum sessions did not and procject start doing their own way inconsistently | 18:31 |
| knikolla | ++ on committing to a decision by end of July. | 18:31 |
| fungi | yes. to be clear, i'm just trying to get people to propose absolute numbers rather than vague concepts like "gradually" and "eventually" | 18:31 |
| gmann | JayF: yes, that is what I am sating since starting. | 18:31 |
| gmann | saying | 18:31 |
| knikolla | ++ thanks fungi. | 18:32 |
| gmann | and in previous meetings also we said that, let discuss on ML and TC decide the single solution whether it is good, bad or very bad | 18:32 |
| gmann | anyways I replied to cinder email to wait for TC decision. | 18:32 |
| knikolla | thanks gmann | 18:33 |
| fungi | yes, but if you ask them to wait for you and then don't actually have a discussion that comes to a conclusion, there needs to be a fallback action they're authorized to take | 18:33 |
| knikolla | which is kill it all with fire. | 18:33 |
| JayF | They are authorized to do what they proposed on the mailing list, already AFAICT, unless we pass a policy to the contrary or ask them politely to wait | 18:33 |
| fungi | yes, i agree | 18:34 |
| JayF | I think asking them politely to wait and then /actually solving the problem/ would be idea | 18:34 |
| JayF | *ideal | 18:34 |
| gmann | fungi: yes, that is my main intension, fail to decide anything is also one clear direction that we can do what is proposed. but reacting after cinder EOL all EM is not benefit to anyone | 18:34 |
| knikolla | Asking them to wait allows us to take a coordinated removal of EM branches if we decide to go that path, which is a good outcome if that is the decision | 18:35 |
| knikolla | (and how many) | 18:35 |
| fungi | this sounds like the start of an agenda | 18:35 |
| gmann | that is why I am saying if cinder do next step and do EOL all EM then I do no think any value in discussion as ship is sailed | 18:35 |
| gmann | I replied that in email to wait until TC agree to anything which can be kill EM process | 18:36 |
| JayF | It'd be a valuable input to see if CI could continue to run against -eol tags | 18:36 |
| gmann | and I am asking here TC to decide early and not to wait for a month or so | 18:36 |
| JayF | with the understanding that a CVE touching that interface point/spanning projects would be unfixable, there's no need to prematurely retire the branch out of fear of a bug that doesn't exist :D | 18:36 |
| gmann | JayF: it cannot in practical, we tried at the time or pike where uncoordinated EOling happened | 18:37 |
| gmann | *time of pike | 18:37 |
| knikolla | gmann: I am okay with a coordinated EM EOL as a start to a new policy, but not that being the only policy decision we take. | 18:38 |
| fungi | what i'm getting from the cinder team is that they want to be able to tell operators "get off this version, we're not confident in our ability to fix future bugs (even security-related ones)" rather than "eh... you might be fine running this as long as nobody finds a severe bug in it down the road" | 18:39 |
| knikolla | We need to reform EM into a policy that does bring something useful for teams that do want to do it. | 18:39 |
| JayF | I will check with Ironic contributors, but I suspect Ironic would continue to desire supporting releases longer than 18 months | 18:39 |
| knikolla | ^^ opening the door for that, but not mandating it. | 18:39 |
| JayF | and likely have the infrastructure to do it as we have multiple integration tests that do not depend on devstack/significant amounts of opestack | 18:39 |
| knikolla | So reconciling my previous proposal to that: we can remove 2-3 EM branches every cycle until we're caught up, then shift it to a opt-in model with some support requirements (period gate, green gate). | 18:40 |
| fungi | a good proposal will also take the slurp cadence into consideration, so we can say "openstack commits to actively maintaining $x slurp branches and their intervening not-slurp counterparts" | 18:41 |
| gmann | opt-in model is no different than what we have currently which is the problem we are trying to solve | 18:41 |
| knikolla | gmann: the problem we have now is that action is required to get out of EM. So you're the bad team for doing it. | 18:41 |
| knikolla | Instead of action required to stay in, which puts the burden on the maintaining team. | 18:42 |
| fungi | gmann: right now we have a bunch of abandoned branches which only go eol when someone else cleans them up, and in the meantime they sit around running (permanently failing) ci jobs and otherwise wasting resources | 18:42 |
| knikolla | gmann: if we want to maintain branches in a coordinated fashion, we can discuss extending our officially supported number of releases. But I don't think we want to do that. | 18:43 |
| gmann | knikolla: problem here is to find a ways that EM are 1.less maintenance cost to upstream 2. communication of what EM is 3. most important is that coordinated way of doing things | 18:43 |
| fungi | continually re-opting-into em for another cycle (or another pair of cycles if we tie it to slurp cadence) means we get to clean up abandoned things automatically | 18:44 |
| knikolla | gmann: I do not think those are the correct problems to focus. The goal is to bring value. Value to users and value to developers. | 18:44 |
| gmann | problem here started when Cinder want to EOl all EM so uncoordinated way. before that no one was interested to see the issue even i raised many times in past from QA perspective as as well project bandwidth | 18:45 |
| knikolla | Value to users whose projects want to support a release for longer. And value to developer to be allowed to do so. | 18:45 |
| fungi | they may be the same problems, but a better way of framing them | 18:45 |
| gmann | knikolla: that is what better communication of what EM is and coordinated way to do things is, value to users and developers | 18:45 |
| knikolla | If nobody wants to provide that value, than we are harming the optics of OpenStack. | 18:45 |
| knikolla | So applying that to your 3 points mentioned above | 18:46 |
| knikolla | 1. Less maintenance cost to upstream - projects who don't have the cycles to maintain branches have no maintenance burden | 18:46 |
| knikolla | 2. communication of what EM is - the EM name now actually will match what is happening. | 18:47 |
| fungi | an incorrectly framed problem can lead to a suboptimal solution, so i agree that reframing the problems to focus on benefit to users and contributors helps people both make better choices as to how to address the problems and puts them in a better position to explain those choices in ways that the people who feel let down or disadvantaged by them at least understand the reasoning | 18:47 |
| knikolla | 3. most important is that coordinated way of doing things - we are coordinating supporting OpenStack across all projects for the supported releases. And anything beyond that assume no, unless the project team communicates that. | 18:47 |
| knikolla | This allows specific teams who did the math and the benefits outweigh the costs, to provide value to their users by supporting a release for longer than the integrated release. | 18:49 |
| gmann | this is the discussion on my proposal to reduce the number of EM branches and it seems that does not solve the issue https://etherpad.opendev.org/p/tc-xena-ptg#L344 | 18:49 |
| fungi | for #3 i think it's important that if the tc feels like this is not something individual project teams should be able to decide for themselves, that it's clearly outlined as an expectation for being included in openstack (one community, not a collection of independent projects) | 18:49 |
| knikolla | fungi: making it required, with some standards of support would make it indistinguishable from an actually supported release. | 18:51 |
| gmann | knikolla: I am that is what current way is 1. project only check/fix things 2. if gate broken they propose to EOL or fix gate. | 18:51 |
| fungi | knikolla: yes, that's what i'm suggesting. if the tc decides projects will be maintaining stable branches for longer, extend the maintained duration | 18:52 |
| knikolla | gmann: It's not only about the broken gate. There was an expectation from operators that those branches were actually supported. | 18:52 |
| gmann | yeah, that is what currently is. i am finding difficulty to see the difference in this solution from what is happening currentyl | 18:53 |
| knikolla | gmann: the difference is that the new EM proposal is "a project team can choose to officially support a release in EM". This communicates guarantees to their users. | 18:54 |
| gmann | and expectation is what communication problem we have for EM. not sure how to solve it. even a single EM we will keep will have same issue and expecation from operator | 18:54 |
| knikolla | I don't think so. Because the project team will choose to support that release and if they cannot do so they will shut down the branch. | 18:55 |
| gmann | knikolla: then why it is moved to EM and why not 'supported maintained branch'. in that case do not move it to EM only and directly move to EOL if project cannot maintain it | 18:55 |
| fungi | knikolla: what i mean is that for your #3, that coordinated maintenance duration should just be "maintained" state, not some combination of maintained followed by a minimum mandated em period | 18:56 |
| knikolla | Because supported maintained branch is a coordinated release concept. | 18:56 |
| knikolla | Exactly. The proposal moves it to EM if the team doesn't want to maintain it. By default. | 18:56 |
| knikolla | fungi: ah, yes, that's what I meant. | 18:56 |
| gmann | but you are project have to maintain EM otherwise move to EOL | 18:56 |
| gmann | *are saying | 18:57 |
| fungi | gmann: "someone" has to maintain those branches, right? and the project team is (currently) expected to at least delegate that maintenance to the people who will be doing it if they don't. that's the reality of how the acls are structured | 18:57 |
| gmann | I think it is lot of typing here, I feel we should better coordinate the discussion in adhoc meeting or ML. adhoc meeting or a sequence of call can speed up the discussion. | 18:58 |
| fungi | ml will also be a lot of typing, but is a great suggestion (and one which has already been made several times, just needs to actually happen) | 18:59 |
| knikolla | gmann: I'll send out the proposal tomorrow and we can discuss on Gerrit. | 18:59 |
| gmann | call is better idea like we did in such cases and concluded fast | 18:59 |
| knikolla | Then we have a few days to collect our thoughts for the Tuesday meeting. | 18:59 |
| gmann | is tuesday meeting video call? | 18:59 |
| knikolla | Yes. | 18:59 |
| gmann | k | 19:00 |
| fungi | history suggests that trying to discuss this on a call will go the same way as the forum session. lots of people trying to repeat their entrenched positions and most participants who want to provide feedback failing to be able to get a word in edgewise | 19:00 |
| gmann | you are sending on gerrit or ML? I think we said ML in meeting | 19:00 |
| gmann | yes but fast way to conclude. but doing it first on ML was the initial idea in last to last week meeting | 19:00 |
| knikolla | Both. Technically our house rules mandate sending policy proposal that we put on Gerrit to the ML as well. | 19:01 |
| knikolla | I think Gerrit is more beneficial for this discussion at this stage. | 19:01 |
| gmann | ok but what we agree in TC meeting was to start the ML first and then propose anything in gerrit | 19:01 |
| gmann | I think ML and call first and if we have anything nearby solution then gerrit | 19:02 |
| knikolla | gmann: I don't think that was a binding decision. What are your concerns about sending it to ML and not Gerrit initially? | 19:02 |
| gmann | if we have any solution which is more close to agreement then gerrit is ok | 19:02 |
| JayF | I think the opposite: having concrete proposals to talk about might focus the discussion instead of having it meander like the conversation at the forum | 19:03 |
| fungi | waiting to propose (perhaps competing) solutions in resolutions or policy edits makes sense if you don't have a good idea of what you want the proposals to include, but i don't see any harm in doing the ml discussion in parallel and pointing people to the proposals if they're fairly concrete already | 19:03 |
| JayF | yeah, I was about to suggest someone put up a competing resolution if they don't know knikolla's approach | 19:03 |
| JayF | s/know/agree with/ | 19:04 |
| knikolla | I don't know about agreement, but I do have a proposal that can concretize this discussion. If my proposal gets disagreements that are not reconcilable through Gerrit than a new proposal is warranted. | 19:04 |
| gmann | knikolla: JayF https://meetings.opendev.org/meetings/tc/2023/tc.2023-06-27-18.00.log.html#l-27 | 19:04 |
| gmann | https://meetings.opendev.org/meetings/tc/2023/tc.2023-06-20-17.59.log.html#l-55 | 19:05 |
| knikolla | gmann: I understand that that is what was said there, but I don't see that as a decision or a binding decision. | 19:05 |
| gmann | that is what we said to go with right? | 19:06 |
| gmann | my idea to put it on ML and call/meeting is we will be close to solution/agreement and then propose that to gerrit | 19:06 |
| gmann | because we need to speed up the discussion | 19:07 |
| * JayF is stepping away | 19:07 | |
| gmann | but I am ok with anything, and next week we can have discuss in TC call or more follow up call to conclude it. | 19:07 |
| gmann | let's try to close this by next week if we can | 19:08 |
| fungi | having a set of proposals to either choose from or adjust seems like it would speed up the discussion | 19:08 |
| fungi | there's no reason those proposals can't be in the form of changes in gerrit | 19:08 |
| knikolla | I understand your concerns in not sticking to the previously discussed and agreed process. I believe that putting those both in Gerrit and ML would speed up the discussion and lead to more productive feedback. | 19:09 |
| fungi | and having them already in gerrit potentially avoids additional charter-mandated delays if the ml discussion concludes quickly | 19:11 |
| knikolla | ++, and I would like to apologize for delaying getting those out last week due to being sick. | 19:13 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!