<@patrikp:matrix.org>
16:00:08
!startmeeting RELENG (2025-03-10)
<@meetbot:fedora.im>
16:00:10
Meeting started at 2025-03-10 16:00:08 UTC
<@meetbot:fedora.im>
16:00:10
The Meeting name is 'RELENG (2025-03-10)'
<@patrikp:matrix.org>
16:00:19
!chair nirik jnsamyak patrikp amedvede
<@patrikp:matrix.org>
16:00:19
!info Meeting is 60 minutes MAX. At the end of 60, it stops.
<@patrikp:matrix.org>
16:00:19
!info Agenda is at https://hackmd.io/vm6biLBcTYKtkQUH5kQkmw.
<@patrikp:matrix.org>
16:00:19
!meetingname releng
<@meetbot:fedora.im>
16:00:20
The Meeting Name is now releng
<@jnsamyak:matrix.org>
16:00:24
0/
<@jnsamyak:matrix.org>
16:00:36
Hello Hello, how's everyone doing today?
<@patrikp:matrix.org>
16:00:47
Hi. 👋
<@james:fedora.im>
16:00:50
!hi
<@zodbot:fedora.im>
16:00:51
James Antill (james)
<@nirik:matrix.scrye.com>
16:01:15
morning
<@patrikp:matrix.org>
16:02:00
!topic Init process.
<@patrikp:matrix.org>
16:02:00
Do we have anything for the init? Any blockers/tasks/issues/requests/features that need releng intervention?
<@jnsamyak:matrix.org>
16:03:09
Nothing much, can you share the progress on openh264, how's it looking?
<@patrikp:matrix.org>
16:03:46
Tarball was sent to Cisco, waiting to hear back from them. It's in the ticket.
<@jnsamyak:matrix.org>
16:04:59
I think we should start documenting it at https://pagure.io/infra-docs-fpo? If there are any changes, we will do it!
<@patrikp:matrix.org>
16:05:06
I had a question related to this, or rather to the tagging issues we ran into. How can I find out if the builds need to be tagged to any other tag other than *-openh264? Who would be a person that would know?
<@patrikp:matrix.org>
16:05:06
https://pagure.io/releng/issue/12612#comment-959964
<@nirik:matrix.scrye.com>
16:05:15
I made a empty repo for rawhide/f43...
<@nirik:matrix.scrye.com>
16:05:40
they shouldn't need to be tagged into anything else that I can think of
<@nirik:matrix.scrye.com>
16:06:09
and in fact should not be. ;)
<@patrikp:matrix.org>
16:06:18
So can I stop them getting tagged directly? I.e. through Koji? I suppose if someone needs it for some reason in the future they can open a ticket if it's an issue.
<@jnsamyak:matrix.org>
16:06:28
we need to include this to the documentation as well
<@nirik:matrix.scrye.com>
16:06:59
so, re-reading I wasn't right above...
<@nirik:matrix.scrye.com>
16:07:02
there's side tags.
<@nirik:matrix.scrye.com>
16:08:28
but we could express that in hub policy too... but... it could be a maintainer accidentally creates an update from that side tag.
<@jnsamyak:matrix.org>
16:09:10
yeah you mentioned in that the side-tags should we allowed, the patrikp changes need to add side-tags or something?
<@nirik:matrix.scrye.com>
16:10:05
yeah, you can match on sidetag in the policy... but we should I think still add it to pungi exclude... so if someone accidentally made a update with it from a side tag, it would never get composed/pushed out
<@patrikp:matrix.org>
16:11:05
What would the side tag look like for the tag policy?
<@patrikp:matrix.org>
16:12:17
Currently the idea is "only allow *-openh264 and nothing else". So we can do "only allow *-openh264 and X and nothing else", but what should the X be?
<@nirik:matrix.scrye.com>
16:13:03
something like 'is_sidetag && is_sidetag_owner :: allow' before the other rule
<@patrikp:matrix.org>
16:14:01
Alright, so do that and also the Pungi change. That was the question I had. Anything else for the init?
<@patrikp:matrix.org>
16:14:30
Moving on...
<@patrikp:matrix.org>
16:14:36
!info Here we list/discuss anything about items that are due to be done in the next week.
<@patrikp:matrix.org>
16:14:36
!topic Scheduled actions coming up in the next week.
<@patrikp:matrix.org>
16:14:36
!link https://fedorapeople.org/groups/schedule/f-43/f-43-releng-tasks.html
<@patrikp:matrix.org>
16:14:36
!link https://fedorapeople.org/groups/schedule/f-42/f-42-releng-tasks.html
<@patrikp:matrix.org>
16:14:49
Blocker review meeting is running now and go/nogo is on Thursday.
<@nirik:matrix.scrye.com>
16:15:01
we do have a rc!
<@nirik:matrix.scrye.com>
16:15:26
but we have a bunch of accepted blockers, so there will be another soon hopefully.
<@jnsamyak:matrix.org>
16:15:37
we are parelllely having a blocker meeting, and on thrusday we will decide it's a go or not
<@nirik:matrix.scrye.com>
16:15:54
there's a request for some stable packages to be pushed too. ;)
<@jnsamyak:matrix.org>
16:16:00
there was a stable puish request just now, did that, so i might think there will be one coming soonish
<@nirik:matrix.scrye.com>
16:16:01
that should hopefully clear some
<@nirik:matrix.scrye.com>
16:16:08
yeah. :) thanks
<@jnsamyak:matrix.org>
16:16:13
oh yeah did that just now
<@jnsamyak:matrix.org>
16:16:16
:D
<@jnsamyak:matrix.org>
16:17:25
Oh btw, I pushed the PR for the mass-rebuild retry logic, I need to beautify it with correct error-handling as a feature request as per the review
<@jnsamyak:matrix.org>
16:17:28
but that's all
<@jnsamyak:matrix.org>
16:18:07
I see Diego Herrera here, I hope we covered everything for epel branching, all looking good that side frend?
<@dherrera:fedora.im>
16:18:27
Hi!
<@jnsamyak:matrix.org>
16:18:29
and hello! 0/
<@nirik:matrix.scrye.com>
16:18:57
patrikp: BTW, for the pungi change, look for 'filter_packages' in the pungi repo... should be able to use that in bodhi/ansible and fedora-pungi to block openh264 from being composed.
<@dherrera:fedora.im>
16:19:28
I was just waiting for open floor to ask for a couple of prs to get merged
<@patrikp:matrix.org>
16:20:36
Anything else for scheduled actions?
<@patrikp:matrix.org>
16:20:47
And do we want to do the retrospective today or look through old tickets?
<@patrikp:matrix.org>
16:21:13
Ask away Diego, init process was a good place for it, no need to wait until the end.
<@jnsamyak:matrix.org>
16:21:45
We will do the retro today, and Diego Herrera shoot!
<@jnsamyak:matrix.org>
16:21:57
this is part of release only epel or fedora :P
<@jnsamyak:matrix.org>
16:22:12
Retro always utilise all the time
<@dherrera:fedora.im>
16:22:34
https://pagure.io/releng/pull-request/12600
<@dherrera:fedora.im>
16:22:34
it's these 2
<@dherrera:fedora.im>
16:22:34
https://pagure.io/infra-docs-fpo/pull-request/357
<@jnsamyak:matrix.org>
16:23:25
Oh i have already reviewed both, I thought you folks want to merge it, and the documentation is ready to GO?
<@dherrera:fedora.im>
16:23:31
the first one are some fixes that we already applied when we were running the process
<@dherrera:fedora.im>
16:23:31
the other one is the SOP, which was already executed :)
<@dherrera:fedora.im>
16:23:31
both regarding the EPEL 10.0 minor branchign
<@jnsamyak:matrix.org>
16:23:34
I will merge these today
<@dherrera:fedora.im>
16:23:44
thx :)
<@jnsamyak:matrix.org>
16:24:20
the doc had some merge conflicts, can you resolve that? I'll rebase the releng one and get it done!
<@dherrera:fedora.im>
16:24:48
ok, I'll resolve them after lunch ;)
<@jnsamyak:matrix.org>
16:25:42
Sure anything else, we can help you with?
<@jnsamyak:matrix.org>
16:26:37
If not we can move onto retro, in 4 mins?
<@patrikp:matrix.org>
16:27:06
Let's choose the next chair and we can do the retro until we run out of time.
<@patrikp:matrix.org>
16:27:14
!topic Choose next chair.
<@jnsamyak:matrix.org>
16:27:17
I can chair it
<@patrikp:matrix.org>
16:27:23
!info Next chair March 17: Samyak
<@patrikp:matrix.org>
16:27:40
!info Next week (March 17) we will be going over old tickets, starting from the oldest opened one.
<@patrikp:matrix.org>
16:28:01
!topic Mass Branching Retrospective part 2
<@patrikp:matrix.org>
16:28:05
Go ahead.
<@jnsamyak:matrix.org>
16:29:55
Okay so a quick recap, we did a mass branching retro part one two weeks back, where we discussed about the signing process, how to update our docs from toddlers to poddlers and how to tackle koji builders blocking at the time of the branching
<@jnsamyak:matrix.org>
16:30:31
We are still have more things to discuss, let's go over them 1:1, btw as per the abovr discussion I hjave already updated the most of the documentation
<@jnsamyak:matrix.org>
16:30:35
so let's start!
<@jnsamyak:matrix.org>
16:31:10
!info Retro Item 4️⃣: Fedora-Repos & Fedora-Release Builds
<@jnsamyak:matrix.org>
16:31:40
So we need to understand have a more good understanding of what rawhide gating is!
<@jnsamyak:matrix.org>
16:31:51
Because, why I say this?
<@jnsamyak:matrix.org>
16:32:07
There are **Timing of builds** to happen
<@jnsamyak:matrix.org>
16:32:18
- Rawhide: Build before rawhide gating.
<@jnsamyak:matrix.org>
16:32:18
- Branched version: Build internally in Koji post-gating before reopening Koji for external users.
<@jnsamyak:matrix.org>
16:32:34
How this affects us at the time of branching process!?
<@jnsamyak:matrix.org>
16:33:09
Since the koji is disabled we are unable to build these with external/personal machines access
<@jnsamyak:matrix.org>
16:34:34
My initially understanding before this release was to actually build the rawhide packages and check if they goes to stable before we disable the koji (i.e. before we start the process)\
<@jnsamyak:matrix.org>
16:35:55
but I think this is wrong, we should have these merged but we should build these after we create the bodhi releases for the new rawhide only it would make sense then, that also means we need to build these internally using koji /compose-x86-01 machine
<@nirik:matrix.scrye.com>
16:36:01
well, so... fedora-release defines %dist... so it needs updated, or packages will still be using fc42 instead of fc43 for rawhide, etc...
<@jnsamyak:matrix.org>
16:36:07
Any suggestions, on what we can do better?
<@nirik:matrix.scrye.com>
16:37:00
we could do them both after closing koji to external, sure... just need ideally to have them done/into buildroots before re-opening.
<@jnsamyak:matrix.org>
16:38:36
the docs mentioned to do rawhide before gating and branched after the rawhide gating, how does it signify in terms of release process?
<@nirik:matrix.scrye.com>
16:39:07
I'm not sure whats meant there with gating...
<@nirik:matrix.scrye.com>
16:40:16
yeah, not sure. gating is aways enabled now I think? so...
<@nirik:matrix.scrye.com>
16:40:32
those 2 notes are the only thing in the doc about gating.
<@jnsamyak:matrix.org>
16:41:24
yeah I will check with tomas once tomorrow but yeah
<@nirik:matrix.scrye.com>
16:41:26
we could ask adamw?
<@jnsamyak:matrix.org>
16:41:31
yes
<@nirik:matrix.scrye.com>
16:41:32
or tomas, sure.
<@jnsamyak:matrix.org>
16:41:53
that is also better since, he deal with that term so much :D
<@jnsamyak:matrix.org>
16:42:18
I'll do that in the releng channel post call - action item for me!
<@nirik:matrix.scrye.com>
16:42:46
looks like git blame has tomas committing those notes. ;)
<@jnsamyak:matrix.org>
16:43:11
But in conclusion, build both after closing koji to external - ideally needs to be done and landed before reopening so the tagging of package should not get affected
<@jnsamyak:matrix.org>
16:43:14
hahaha yes
<@nirik:matrix.scrye.com>
16:44:46
yeah, thats my take on it... do it before reopening, so when people do builds they get the right thing.
<@jnsamyak:matrix.org>
16:44:55
I had one more thing similar to this, which is next item on retro as well, so adding it here, I dont want us to loose all the time in one item
<@jnsamyak:matrix.org>
16:45:08
!info 5️⃣ Handling Side Tags in Mass Branching
<@jnsamyak:matrix.org>
16:45:23
How to properly merge side tags? If side tags for `fedora-repos` and `fedora-release` were merged to `f42`, should Bodhi updates still be manually pushed?
<@jnsamyak:matrix.org>
16:46:09
I think I should do a better job at writing this question - let me explain - so we do build both the packages in side tags and then we merge them to the main tag
<@nirik:matrix.scrye.com>
16:46:15
well, I think they should be updates if possible, but I am not sure if we run into gating problems with that.
<@jnsamyak:matrix.org>
16:46:17
which let bodhi not intervene
<@jnsamyak:matrix.org>
16:46:45
and we loose these updates, and we had to manually push those iirc
<@nirik:matrix.scrye.com>
16:46:46
another one to ask about I guess?
<@patrikp:matrix.org>
16:47:49
What is the link to the retro doc?
<@jnsamyak:matrix.org>
16:48:00
Let's move on to next, this will be a quick one, I suppose?
<@jnsamyak:matrix.org>
16:48:05
patrikp: https://hackmd.io/DykaMNJ1TXGjilEOokTp1A?edit
<@jnsamyak:matrix.org>
16:48:08
!link https://hackmd.io/DykaMNJ1TXGjilEOokTp1A?edit
<@patrikp:matrix.org>
16:48:09
Thanks.
<@jnsamyak:matrix.org>
16:48:39
!info 6️⃣ Cleanup: Removing Unnecessary Container Entries
<@jnsamyak:matrix.org>
16:49:06
- Branching documentation
<@jnsamyak:matrix.org>
16:49:06
- Identify redundant container references in:
<@jnsamyak:matrix.org>
16:49:06
- Koji tags
<@jnsamyak:matrix.org>
16:49:06
- Bodhi releases
<@jnsamyak:matrix.org>
16:49:06
- Clarify why they are unnecessary and document changes.
<@jnsamyak:matrix.org>
16:49:06
<@jnsamyak:matrix.org>
16:49:06
<@jnsamyak:matrix.org>
16:49:06
I see we should stop creating bodhi releases etc, for containers
<@jnsamyak:matrix.org>
16:49:16
but I want to get +1 before doing that
<@jnsamyak:matrix.org>
16:49:29
we are not generally using them anywhere, are we?
<@nirik:matrix.scrye.com>
16:49:45
Yeah, I think we should... not sure if it needs a stamp from fesco or anything. I can bring it up at the meeting tomorrow to make sure...
<@nirik:matrix.scrye.com>
16:49:55
we are not using them at all at this point.
<@jnsamyak:matrix.org>
16:49:58
yes please!
<@jnsamyak:matrix.org>
16:50:20
A confirmation would be good :D - oh we have this action item for you
<@nirik:matrix.scrye.com>
16:50:22
we are making a few containers, but all via kiwi and not using the container git namespace or bodhi
<@jnsamyak:matrix.org>
16:50:22
hehe
<@jnsamyak:matrix.org>
16:50:35
yeah
<@jnsamyak:matrix.org>
16:50:59
!info 7️⃣ Bodhi Releases & Naming Conventions
<@jnsamyak:matrix.org>
16:51:07
- The new release branch in Bodhi is named `rawhide` (not the new version number).
<@jnsamyak:matrix.org>
16:51:07
- Ensure:
<@jnsamyak:matrix.org>
16:51:07
- The branched release uses the correct new branch name.
<@jnsamyak:matrix.org>
16:51:25
The doc is actually using variable
<@jnsamyak:matrix.org>
16:51:51
which let the branch naming wrong, so I need to add one thing
<@jnsamyak:matrix.org>
16:52:24
before of the documentation start to when we update the fedora release vars each time we do a final release, we need to update the branch to rawhide
<@jnsamyak:matrix.org>
16:52:58
in this section because in hurry we/ (I) always forget to check if the branch name is correct in the bodhi releases
<@jnsamyak:matrix.org>
16:53:17
if there is a way to make it 100 times BOLD I would but oh well
<@jnsamyak:matrix.org>
16:53:25
but that's all I wanted to capture for this
<@jnsamyak:matrix.org>
16:54:01
this time I was actually live demonstrating on channel, so fabio I guess checked the issue ^^ and we fixed it then and there
<@jnsamyak:matrix.org>
16:54:08
but something to remember
<@jnsamyak:matrix.org>
16:54:15
Anyone wants to add anything?
<@nirik:matrix.scrye.com>
16:54:38
yeah, sounds good to update the doc and add a note. ;) nothing else to add
<@jnsamyak:matrix.org>
16:54:55
two quick ones
<@jnsamyak:matrix.org>
16:54:57
!info 8️⃣ Automate Branched Compose Triggering
<@jnsamyak:matrix.org>
16:55:08
Add a section in the documentation to trigger a branched compose after all processes are completed.
<@jnsamyak:matrix.org>
16:55:22
LOL - we havent mentioned it
<@nirik:matrix.scrye.com>
16:55:23
+1
<@jnsamyak:matrix.org>
16:56:02
!info 9️⃣ Mirror Manager Updates
<@jnsamyak:matrix.org>
16:56:25
oc rsh frontend-68-rf4vw
<@jnsamyak:matrix.org>
16:56:25
fedora-secondary
<@jnsamyak:matrix.org>
16:56:25
```
<@jnsamyak:matrix.org>
16:56:25
```sh
<@jnsamyak:matrix.org>
16:56:25
- **Update OpenShift pod:**
<@jnsamyak:matrix.org>
16:56:25
- **Fullfilelist update** (run from compose-branched machine).
<@jnsamyak:matrix.org>
16:56:25
- Post-redirect updates:
<@jnsamyak:matrix.org>
16:56:25
/pub/fedora-secondary/update-fullfiletimelist.lock -t /pub fedora \
<@jnsamyak:matrix.org>
16:56:25
sudo -u ftpsync /usr/local/bin/update-fullfiletimelist -l \
<@jnsamyak:matrix.org>
16:56:46
Everything is updated and shifted to openshift
<@jnsamyak:matrix.org>
16:56:53
so we need to go into pod
<@jnsamyak:matrix.org>
16:57:26
and then run it from there
<@nirik:matrix.scrye.com>
16:57:32
thats not correct...
<@nirik:matrix.scrye.com>
16:57:43
the fullfiletimelist is on the downloaad side.
<@jnsamyak:matrix.org>
16:57:44
but we need to add a documentation
<@nirik:matrix.scrye.com>
16:57:52
it should be done on compose-branched01 or the like...
<@jnsamyak:matrix.org>
16:58:01
oh okay
<@nirik:matrix.scrye.com>
16:58:32
yeah, the first point should be right, not sure on the second what that came from.
<@jnsamyak:matrix.org>
16:59:42
this time, we did update it but the mirrors weren't reflected, so I think that's where you me and adrian looked and this fixed the issue
<@nirik:matrix.scrye.com>
17:00:31
well, it should pick it up automatically... I think we had some sync problems? ie, repodata wasn't there so it wasn't detecting it.
<@patrikp:matrix.org>
17:01:03
We're past time.
<@nirik:matrix.scrye.com>
17:01:17
oops yeah.
<@jnsamyak:matrix.org>
17:01:31
okay we almost covered all the points
<@jnsamyak:matrix.org>
17:01:44
in the next call I'll just update the retro doc
<@jnsamyak:matrix.org>
17:01:49
and let everyone review it
<@jnsamyak:matrix.org>
17:01:54
and we will do a quick summay
<@jnsamyak:matrix.org>
17:01:58
and we will do a quick summary
<@jnsamyak:matrix.org>
17:02:02
and close the retro
<@jnsamyak:matrix.org>
17:02:19
but we discussed everything the branching was GOOD, we will try to make it BEST!
<@jnsamyak:matrix.org>
17:02:23
That's all
<@patrikp:matrix.org>
17:02:34
One of the better retrospectives I've been in, well done.
<@patrikp:matrix.org>
17:02:43
!info Thank you all for coming!
<@patrikp:matrix.org>
17:02:56
!endmeeting