| gmann | frickler: thanks. I will close the open reviews, yes we need to abandon those. did the same for OpenStack-chef also | 01:22 |
|---|---|---|
| gmann | frickler: for RDO CI, i also noticed that, I think we can just override it. | 01:23 |
| tkajinam | frickler gmann afair RDO CI does not block merge so you can merge the change | 01:59 |
| tkajinam | I'll drop a message in #rdo to ask the team to remove that job | 01:59 |
| opendevreview | Jake Yip proposed openstack/election master: Add Jake Yip candidacy for Magnum 2024.2 PTL https://review.opendev.org/c/openstack/election/+/910132 | 03:47 |
| *** dasm is now known as Guest1011 | 04:31 | |
| *** Guest1011 is now known as dasm | 04:31 | |
| opendevreview | Takashi Kajinami proposed openstack/election master: Adding Takashi Kajinami candidacy for Puppet OpenStack PTL https://review.opendev.org/c/openstack/election/+/910136 | 04:32 |
| opendevreview | Takashi Kajinami proposed openstack/election master: Adding Takashi Kajinami candidacy for Storlets PTL https://review.opendev.org/c/openstack/election/+/910137 | 04:36 |
| opendevreview | Takashi Kajinami proposed openstack/election master: Adding Takashi Kajinami candidacy for Storlets PTL https://review.opendev.org/c/openstack/election/+/910137 | 04:39 |
| opendevreview | Takashi Kajinami proposed openstack/election master: Adding Takashi Kajinami candidacy for Puppet OpenStack PTL https://review.opendev.org/c/openstack/election/+/910136 | 04:42 |
| opendevreview | Takashi Kajinami proposed openstack/election master: Adding Takashi Kajinami candidacy for Heat PTL https://review.opendev.org/c/openstack/election/+/910138 | 04:47 |
| opendevreview | Takashi Kajinami proposed openstack/election master: Adding Takashi Kajinami candidacy for Puppet OpenStack PTL https://review.opendev.org/c/openstack/election/+/910136 | 04:49 |
| opendevreview | inspurericzhang proposed openstack/election master: Adding Eric Zhang candidacy for Venus https://review.opendev.org/c/openstack/election/+/909570 | 06:09 |
| frickler | gmann: tkajinam: seems I'll need to forcefully drop the RDO CI V-1 vote from the affected patch | 07:20 |
| frickler | gmann: it also looks like we'll either need to delete content from stable branches, too, or we can drop the affected projects from zuul configuration. I guess I'd prefer the latter. cf. https://review.opendev.org/c/openstack/tripleo-ci/+/910059 | 07:21 |
| opendevreview | Slawek Kaplonski proposed openstack/election master: Slawek Kaplonski candidacy for TC https://review.opendev.org/c/openstack/election/+/910154 | 09:31 |
| *** tosky_ is now known as tosky | 09:40 | |
| opendevreview | suzhengwei proposed openstack/election master: Add suzhengwei candidancy for Masakari https://review.opendev.org/c/openstack/election/+/910205 | 10:40 |
| opendevreview | Erno Kuvaja proposed openstack/election master: Erno Kuvaja for Telemetry PTL https://review.opendev.org/c/openstack/election/+/910226 | 12:33 |
| opendevreview | Yasufumi Ogawa proposed openstack/election master: Adding Yasufumi Ogawa candidancy for Tacker https://review.opendev.org/c/openstack/election/+/910233 | 14:21 |
| opendevreview | Sylvain Bauza proposed openstack/election master: Sylvain Bauza candidacy for Nova 2024.2 PTL https://review.opendev.org/c/openstack/election/+/910235 | 14:55 |
| opendevreview | Michal Nasiadka proposed openstack/governance master: Add magnum-capi-helm to Magnum project https://review.opendev.org/c/openstack/governance/+/910240 | 15:58 |
| opendevreview | Michal Nasiadka proposed openstack/governance master: Add magnum-capi-helm to Magnum project https://review.opendev.org/c/openstack/governance/+/910240 | 15:59 |
| JayF | tc-members: if there is anyone who intends on running for TC chair next cycle, if you let me know I'm happy to include you (can be >1) in planning for TC PTG | 16:07 |
| JayF | I know in Ironic community, we traditionally have the incoming PTL, if there's an apparent consensus choice, do the PTG planning since they're planning the cycle they run :) | 16:08 |
| frickler | I wouldn't mind if such an intention would be made public, too. but of course can't enforce this | 16:15 |
| JayF | I certainly wouldn't be sneaking off in private meetings to go schedule PTG stuff with some mystery candidate :D | 16:15 |
| frickler | given that (unless I missed some) we still haven't enough candidacies yet to fill the seats that are to be reelected, it might also be helpful if people who do not intend to re-run state so | 16:16 |
| JayF | I am not running next cycle; but I was going to not say such a thing until after this election | 16:17 |
| JayF | but consider that a public declaration :D | 16:17 |
| opendevreview | James Page proposed openstack/election master: Add jamespage TC candidacy https://review.opendev.org/c/openstack/election/+/910249 | 16:55 |
| JayF | gmann: https://review.opendev.org/c/openstack/governance/+/908859/ will need to be rebased to remove the timeline modification if we want to get it marked inactive soon | 17:23 |
| opendevreview | Yasufumi Ogawa proposed openstack/election master: Adding Yasufumi Ogawa candidancy for Tacker https://review.opendev.org/c/openstack/election/+/910233 | 17:56 |
| opendevreview | Yasufumi Ogawa proposed openstack/election master: Adding Yasufumi Ogawa candidancy for Tacker https://review.opendev.org/c/openstack/election/+/910233 | 18:07 |
| opendevreview | Yasufumi Ogawa proposed openstack/election master: Adding Yasufumi Ogawa candidancy for Tacker https://review.opendev.org/c/openstack/election/+/910233 | 18:08 |
| gmann | JayF: on Murano inactive, the dependencies was to make sure we followed the process. we are passed m-2 and I did not find anywhere our current process tells that we can mark project inactive after that and how its releases will be for that cycle | 18:35 |
| JayF | We *can* mark projects inactive at any time. Marking them inactive after C-2 just does not remove them from the release. | 18:35 |
| gmann | that is why I made doc update change first so that we agree on that part first | 18:35 |
| JayF | I would say, in my estimation, we're unlikely to reach consensus on that first part with someone on the releases team asking us explicitly to not do it. | 18:36 |
| JayF | But there's still value in marking Murano inactive, since we know what gets released (ugh) will likely have critial, unfixed bugs due to its inactivity | 18:36 |
| gmann | that is the open question, if we mark them inactive after m-2 and their gate is broken then is it worth to release those? | 18:36 |
| JayF | Releases team, in gerrit, answered that with an emphatic "yes" | 18:36 |
| gmann | so what is motive of marking project Inactive in that cycle, we can do in next cycle before m-2 | 18:37 |
| gmann | what we can add in doc is release team can decide on the releases if we mark any project inactive after m-2 | 18:37 |
| gmann | let me try to modify the doc change today considering the release team feedback and we will see how it goes | 18:38 |
| JayF | That sounds like a reasonable compromise, but we'd have to ask what they thought. | 18:38 |
| JayF | I do think there's value in doing inactive even if we still release it | 18:38 |
| gmann | if still stuck then I can remove that dependency and we can have vote on that | 18:38 |
| JayF | because bluntly, I'd likely push a PR to that readme saying it's inactive | 18:38 |
| JayF | and warning against use | 18:38 |
| JayF | (to openstack/murano*) | 18:39 |
| JayF | we'd see if it got to merge :D | 18:39 |
| fungi | worth getting this topic onto the release meeting agenda too, i don't recall them discussing it explicitly yet | 18:39 |
| gmann | yeah, README warning sounds good idea and external communication about it. we do not do that but worth to do it for inactive projects | 18:39 |
| JayF | Well, in projects inactive before X-2 we communicate that by pulling them from the release | 18:40 |
| JayF | We missed that with Murano; so now we're in a pickle where a readme warning might be the best thing we have | 18:40 |
| gmann | doing it for all is not bad idea too, not releasing is ok but I am not 100% sure that user will be checking that until they reach to the time to upgrade to that release | 18:41 |
| JayF | I agree 100% with you that my preference is not to release it | 18:42 |
| JayF | but unless/until I'm willing to help releases team with work related to releases, I'm going to defer to their judgement on these timing things | 18:42 |
| gmann | sure | 18:42 |
| gmann | let me modify the doc saying release is up to release team but we should update README file at least | 18:43 |
| opendevreview | Carlos Eduardo proposed openstack/election master: Add Carlos da Silva candidacy for Manila PTL https://review.opendev.org/c/openstack/election/+/910259 | 18:43 |
| gmann | I think that is still good signal even release is happening | 18:43 |
| gmann | by not releasing I was trying to avoid 1. unnecessary work on release team and 2. not to release with broken code but let release team decide on that part | 18:44 |
| JayF | Yeah, same. I don't fully understand why stopping release at this point causes them pain but bluntly I don't have the time to dig into that default now so I am trusting them | 18:45 |
| gmann | yeah, will push the new version soon i boot up my VM | 18:46 |
| gmann | frickler: on TripleO, removing stable branch content is lot of work. maybe zuul configuration idea is better to proceed. but one question, it will not end up with zuul config errors right? | 18:47 |
| clarkb | gmann: if we remove tripleo from the zuul config entirely then any other projects that may have references to tripleo jobs or roles could have errors | 18:49 |
| clarkb | But it is probably a more direct way to indicate the removal and then just trim off the bits in other places | 18:49 |
| JayF | clarkb: is that a feature not a bug? That those projects would be forced to drop dep on tripleo? | 18:49 |
| frickler | I'd think so. we've been doing similar things for other cleanups | 18:50 |
| gmann | clarkb: other places (projects), we have mostly cleaned up but its tripleo-cI repo defining tripleO jobs and tripleo other repo using those in stable branch | 18:50 |
| gmann | master branches cleanup is done so we are good on that part | 18:51 |
| clarkb | JayF: ya if your project says "I want to run this job" then you delete that job it is accurately reporting the issue | 18:51 |
| gmann | frickler: ok, sounds good. | 18:51 |
| clarkb | gmann: we should be able to remove all of the tripleo repos from zuul config loading | 18:51 |
| clarkb | but then you won't be able to merge new changes without updating project-config | 18:52 |
| gmann | yeah we are doing those with noop job and then at the end remove complete configuration. | 18:53 |
| frickler | we removed master content for all but two or so repos already. so I'd just leave those two repos in zuul for a moment longer | 18:53 |
| gmann | frickler: you mean till stable/wallaby (that is last stable in Tripleo - most probably) goes EOL and then we can remove tripleo-ci content (zuul file ) later? | 18:55 |
| frickler | actually one merged, so only https://review.opendev.org/c/openstack/tripleo-ci/+/910059 remaining, this has the errors gmann was referring to | 18:55 |
| gmann | yeah this repo define the jobs which are used in stable branches | 18:55 |
| frickler | gmann: well tripleo is eol completely according to my understanding. so 1) remove all other repos from zuul 2) merge that patch which should then check green 3) also remove tripleo-ci from zuul | 18:56 |
| gmann | frickler: question on 3rd step, will not that still fail like it is currently? | 18:58 |
| gmann | i mean in https://review.opendev.org/c/openstack/tripleo-ci/+/910059 | 18:58 |
| frickler | that's step 2. the current error should go away once zuul no longer fetches config from tripleo-validations | 18:59 |
| frickler | step 1+3 will be project-config changes | 19:00 |
| gmann | frickler: ah yeah got it. let me do that way. | 19:00 |
| gmann | we should merge the governance change first before 1) but i think it is worth to try this way and we know tripleo is going | 19:01 |
| gmann | tripleo-ci being branchless is leading us to do that way otherwise stable branch jobs handle by themself only | 19:02 |
| frickler | well yeah it would be really unlucky if the gov patch would get rejected at this stage | 19:05 |
| gmann | yeah | 19:05 |
| frickler | hmm, different question, I don't think we need PTLs for inactive projects? certainly we won't need one for openstack_chef. cf. https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/ITB5QKWZGU2DHMZSEW6ERGUXACGT55O7/ | 19:11 |
| gmann | frickler: for retiring one yes, I will remove chef and tripleo from there. For inactive, I think it is still ok to have PTL and if they can make it active. | 19:13 |
| JayF | I don't hate it being included, gives someone a last chance to squeal "I care" before we put the project to bed for good. | 19:13 |
| gmann | if we see PTL is not working to make it active and project is almost dead then we can discuss to retire it | 19:13 |
| JayF | Do we need to add anything to TC agenda outta these discussions? | 19:15 |
| JayF | I'm about to finalize it so speak now :D | 19:15 |
| * JayF going to add Murano | 19:16 | |
| opendevreview | Ghanshyam proposed openstack/governance master: Modify the timeline for project to move to Inactive state https://review.opendev.org/c/openstack/governance/+/908880 | 19:18 |
| gmann | frickler: JayF ^^ please check if this looks ok now? | 19:19 |
| gmann | updating README file can be challenge as it need gate green and some core member to merge it but I added it in doc if we can do that in some cases | 19:20 |
| JayF | If there's ever a case where force-merging a patch is acceptable, updating the readme to say "CI doesn't work" when CI doesn't work has to be one :D | 19:20 |
| frickler | ack. I'll defer closer looking at that update to tomorrow though | 19:23 |
| opendevreview | Ghanshyam proposed openstack/election master: Remove retired OpenStack-Chef from election https://review.opendev.org/c/openstack/election/+/910261 | 19:26 |
| opendevreview | Brian Haley proposed openstack/election master: Add Brian Haley (haleyb) candidacy for Neutron PTL https://review.opendev.org/c/openstack/election/+/910263 | 19:34 |
| opendevreview | Tatiana Ovchinnikova proposed openstack/election master: Adding Tatiana Ovchinnikova candidacy for Horizon PTL https://review.opendev.org/c/openstack/election/+/910272 | 20:52 |
| opendevreview | Tatiana Ovchinnikova proposed openstack/election master: Adding Tatiana Ovchinnikova candidacy for Horizon PTL https://review.opendev.org/c/openstack/election/+/910272 | 20:54 |
| -opendevstatus- NOTICE: Gerrit on review.opendev.org will be restarted to perform a minor upgrade to the service. | 22:34 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!