releng/tickets
15
3
Fork 2
Code Issues 79 Pull requests Projects Releases Packages Wiki Activity Actions

[fedora-scm-requests] - Update fedpkg #13369

New issue
Closed
opened 2026-05-28 09:24:30 +00:00 by humaton · 15 comments
humaton commented 2026-05-28 09:24:30 +00:00
Owner
Copy link

Update fedpkg to use the new forge repository to open tickets

Update fedpkg to use the new forge repository to open tickets
patrikp self-assigned this 2026-06-01 13:15:16 +00:00
patrikp changed title from [ fedora-scm-requests ] - Update fedpkg to [fedora-scm-requests] - Update fedpkg 2026-07-07 07:08:13 +00:00
patrikp commented 2026-07-07 07:10:16 +00:00
Member
Copy link

The migration to prod completed successfully and I was able to create a new ticket [1] by using the API and a Forgejo token. I'm working on the fedpkg changes now.

[1] releng/fedora-scm-requests#84420

The migration to prod completed successfully and I was able to create a new ticket [1] by using the API and a Forgejo token. I'm working on the `fedpkg` changes now. [1] https://forge.fedoraproject.org/releng/fedora-scm-requests/issues/84420
patrikp commented 2026-07-22 21:25:00 +00:00
Member
Copy link

PR is (finally) ready for review here:
packaging/fedpkg#636

PR is (finally) ready for review here: https://forge.fedoraproject.org/packaging/fedpkg/pulls/636
jnsamyak commented 2026-07-30 08:44:00 +00:00
Owner
Copy link

Update: I see the PR was merged yesterday, though @onosek needs to do a stable and rawhide release.

We need to flag a day for this, so possible next tuesday we will flag it.

Update: I see the PR was merged yesterday, though @onosek needs to do a stable and rawhide release. We need to flag a day for this, so possible next tuesday we will flag it.
kevin commented 2026-07-30 18:50:46 +00:00
Owner
Copy link

@jnsamyak wrote in #13369 (comment):

Update: I see the PR was merged yesterday, though @onosek needs to do a stable and rawhide release.

The builds can be done anytime for stable releases, but the rawhide build/update and the stable updates should be only done right before the time we pick for the flag day.

We need to flag a day for this, so possible next tuesday we will flag it.

Yeah, and we need to decide this ASAP and send out an announcement to devel-announce about it.

I'd propose 2026-08-04 as fine, but what time? @onosek and @patrikp can pick a time they are both active?

I'm happy to review a draft of a announcement, or I can make one up if you all like?

@jnsamyak wrote in https://forge.fedoraproject.org/releng/tickets/issues/13369#issuecomment-1072484: > Update: I see the PR was merged yesterday, though @onosek needs to do a stable and rawhide release. The builds can be done anytime for stable releases, but the rawhide build/update and the stable updates should be only done right before the time we pick for the flag day. > We need to flag a day for this, so possible next tuesday we will flag it. Yeah, and we need to decide this ASAP and send out an announcement to devel-announce about it. I'd propose 2026-08-04 as fine, but what time? @onosek and @patrikp can pick a time they are both active? I'm happy to review a draft of a announcement, or I can make one up if you all like?
onosek commented 2026-07-31 04:29:02 +00:00
Copy link

Packages (rpkg-1.70 & fedpkg-1.48) are created and are waiting in Bodhi to be moved to testing repos.

Packages (rpkg-1.70 & fedpkg-1.48) are created and are waiting in Bodhi to be moved to testing repos.
kevin commented 2026-07-31 15:24:02 +00:00
Owner
Copy link

Sigh. I do not think we should push these to testing ahead of the flag day.
That is going to break all packagers that have testing enabled...

Sigh. I do not think we should push these to testing ahead of the flag day. That is going to break all packagers that have testing enabled...
onosek commented 2026-07-31 16:14:09 +00:00
Copy link

OK, I thought that having packages in testing repos for some time is affordable risk. But let me know about specific plan.
Revoke updates for now? Before they go to testing?
Re-create updates on Monday to be pushed to testing on Tuesday and being tested (and karma gathered) the same day?
And then click "push to stable" to be actually pushed on Wednesday early morning?

OK, I thought that having packages in testing repos for some time is affordable risk. But let me know about specific plan. Revoke updates for now? Before they go to testing? Re-create updates on Monday to be pushed to testing on Tuesday and being tested (and karma gathered) the same day? And then click "push to stable" to be actually pushed on Wednesday early morning?
kevin commented 2026-07-31 16:29:57 +00:00
Owner
Copy link

IMHO, just revoke the request to testing... wait and when we have the flag day/time, resubmit them for testing.
We can then do a special testing push to move them to testing, get people to confirm they work and mark stable, then do a special stable push to move them stable.

IMHO, just revoke the request to testing... wait and when we have the flag day/time, resubmit them for testing. We can then do a special testing push to move them to testing, get people to confirm they work and mark stable, then do a special stable push to move them stable.
onosek commented 2026-07-31 16:39:49 +00:00
Copy link

Sure, I can do that.
Just need to note that the migration functionality is just a part of the full release of rpkg&fedpkf. A number of changes is released together. Although I don't think any critical issue would appear, I can't say it would be 100% perfect. The suggested process is short, and there is very limited space for fixing possible bugs.

Sure, I can do that. Just need to note that the migration functionality is just a part of the full release of rpkg&fedpkf. A number of changes is released together. Although I don't think any critical issue would appear, I can't say it would be 100% perfect. The suggested process is short, and there is very limited space for fixing possible bugs.
kevin commented 2026-07-31 16:51:01 +00:00
Owner
Copy link

Yeah, I suppose we could also leave it in testing and direct maintainers to install from there for a few days... just more communications work.

Yeah, I suppose we could also leave it in testing and direct maintainers to install from there for a few days... just more communications work.
kevin commented 2026-08-01 19:42:20 +00:00
Owner
Copy link

So, given we haven't sent out an announcement yet, I think we should push this to next thursday at the earilest...

possible email:

Subject: scm-requests moving to forge, new fedpkg needed

Thursday (2026-08-06) at 14 UTC we will be disabling the existing pagure scm requests ticketing system. 
At the same time new fedpkg updates will be pushed to testing (and then stable as soon as they have gotten testing).

The existing fedpkg version ( 1.47 ) will try and request new packages and branches from the old pagure repo and
after the time above it will fail as that repo will be disabled.

Maintainers will need to update to the new fedpkg version ( 1.48 ) after the above time/date in order to submit new
scm requests (new branches, new package additions, etc). 

Thanks for your understanding
So, given we haven't sent out an announcement yet, I think we should push this to next thursday at the earilest... possible email: ``` Subject: scm-requests moving to forge, new fedpkg needed Thursday (2026-08-06) at 14 UTC we will be disabling the existing pagure scm requests ticketing system. At the same time new fedpkg updates will be pushed to testing (and then stable as soon as they have gotten testing). The existing fedpkg version ( 1.47 ) will try and request new packages and branches from the old pagure repo and after the time above it will fail as that repo will be disabled. Maintainers will need to update to the new fedpkg version ( 1.48 ) after the above time/date in order to submit new scm requests (new branches, new package additions, etc). Thanks for your understanding ```
jnsamyak commented 2026-08-03 09:08:47 +00:00
Owner
Copy link

Thank you for writing this uo @kevin, it got missed. But I talked to @patrikp regarding this. We should do this ideally on Wednesday because this is something we need to test out, and I'm out for the last working days for my exams. I have asked him to send an email asap in sometime so it should hit it.

If there is any more traction needed, we will discuss this tonight in our releng weekly call, and then do the communication in the channel, etc;

With branching around the corner, each day counts.

Thank you for writing this uo @kevin, it got missed. But I talked to @patrikp regarding this. We should do this ideally on Wednesday because this is something we need to test out, and I'm out for the last working days for my exams. I have asked him to send an email asap in sometime so it should hit it. If there is any more traction needed, we will discuss this tonight in our releng weekly call, and then do the communication in the channel, etc; With branching around the corner, each day counts.
onosek commented 2026-08-03 09:20:10 +00:00
Copy link

When we discussed the plan on the weekly Matrix meeting, I mentioned I am on holiday 5-9 Aug. Although the rpkg&fedpkg builds are prepared, updates are in an "unpushed" state. Do you need me for this operation to be present, or are you able to push updates without me?

When we discussed the plan on the weekly Matrix meeting, I mentioned I am on holiday 5-9 Aug. Although the rpkg&fedpkg builds are prepared, updates are in an "unpushed" state. Do you need me for this operation to be present, or are you able to push updates without me?
patrikp commented 2026-08-03 09:49:01 +00:00
Member
Copy link

Well, after a discussion with Samyak, I sent the announcement email with the flag day date of Wednesday, August 5th. Of course just after I clicked send I read onosek's comment above (email is currently awaiting approval).

We should be able to push the updates ourselves I believe.

Well, after a discussion with Samyak, I sent the announcement email with the flag day date of Wednesday, August 5th. Of course just after I clicked send I read onosek's comment above (email is currently awaiting approval). We should be able to push the updates ourselves I believe.
jnsamyak commented 2026-08-05 18:47:24 +00:00
Owner
Copy link

Migration is done for this, please in case of any migration query related to this, feel free to comment on: #13108; OR if you see any bug/issue, please file a new ticket in our repo tracker.

Thank you for your patience here.

Migration is done for this, please in case of any migration query related to this, feel free to comment on: https://forge.fedoraproject.org/releng/tickets/issues/13108; OR if you see any bug/issue, please file a new ticket in our repo tracker. Thank you for your patience here.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
twoweek-stable
rawhide-stable
Labels
Clear labels   
after freeze

   
automation

   
backlog
Tasks that will take longer then ~4 hours to do

  
blocked

   
change-ack
Changes that have releng work and are accepted

  
change-nak
Changes that have releng work and have been rejected

  
change-noreleng
Changes that do not have any releng work

  
changes
  
Closed As
Can't Fix
 Closed with the reason of Can't Fix

  
Closed As
Duplicate
 Closed with the reason of Duplicate

  
Closed As
Fixed
 Closed with the reason of Fixed

  
Closed As
Fixed with Explanation
 Closed with the reason of Fixed with Explanation

  
Closed As
Get back later
 Closed with the reason of Get back later

  
Closed As
Grooming
 Closed with the reason of Grooming

  
Closed As
Insufficient data
 Closed with the reason of Insufficient data

  
Closed As
Invalid
 Closed with the reason of Invalid

  
Closed As
It's all good
 Closed with the reason of It's all good

  
Closed As
taiga
 Closed with the reason of taiga

  
Closed As
upstream
 Closed with the reason of upstream

  
day-to-day
These are small, self-contained tasks that are part of normal operations but are async from sprint planning.

  
dev

   
docs

   
easyfix

   
epel

   
f26

   
f27
Fedora 27

  
f28
Fedora 28

  
f29
Fedora 29

  
f30

   
f31

   
f32

   
f33
Fedora 33

  
f34

   
f35
Fedora 35

  
f36

   
f37

   
f38

   
f39
Fedora 39

  
f40

   
f41
Fedora 41

  
f42
Fedora 42

  
f43
Fedora 43

  
f44
Fedora 44

  
f45
Fedora 45

  
fedora

   
groomed

   
high-gain

   
high-trouble

   
in-progress

   
in-review

   
investigation

   
legal

   
low-gain

   
low-trouble

   
mass rebuild

   
medium-gain

   
medium-trouble

   
meeting

   
mini-initiative

   
new_artifact
New artifact for fedora release

  
ops

   
pdc_retirement

   
rawhide

   
RCA
Root cause analysis

  
review

   
script

   
sidetarget

   
sprint-0

   
sprint-1
Releng Sprint 1 Tracker

  
sprint-2
Sprint 2

  
sprint-3
Releng Sprint 3 Tracker

  
sprint-4
RelEng Spring 4 Tracker

  
sprint-5
RelEng Sprint Tracker 5 (Nov 18 - Dec 02)

  
unfrozen
Revisit after freeze

  
waiting on external
  
Backlog Status
Needs Review
 Needs to go through refinement

  
Backlog Status
Ready
 Ready for sprint

  
chore

   
documentation
  
points
01
 A task that is simple, small, and has very little uncertainty. It should be easy enough for any team member to pick up and complete quickly, without a lot of discussion or research.

  
points
02
 This is a task that is slightly more complex or larger than a "1." It might involve two or three simple steps, but the outcome is still very clear and there's little uncertainty.

  
points
03
 Medium-sized task with some noticeable complexity. It might require a bit more thought or collaboration. The steps are well-defined, but it's not a trivial change.

  
points
05
 A significant piece of work. It has more complexity and a higher degree of uncertainty than smaller tasks. It might require some research, a design discussion, or collaboration across multiple teams.

  
points
08
 Complex task with a lot of uncertainty. It's often the largest size that a team will consider for a single sprint. It likely requires a detailed breakdown and multiple team members to complete.

  
points
13
 Any task that feels like it's a "13" or more is considered an Epic. These are too large and uncertain to be worked on in a single sprint and should be broken down.

  
Priority
High
 This is for work that is critical and needs to be addressed in the next sprint. It's often for urgent bugs, important features, or a major piece of technical debt that is blocking other work.

  
Priority
Low
 This is for work that is good to do but not urgent. It's a candidate for being worked on when there's extra time or when it rises in importance. It can stay in the backlog for a longer period.

  
Priority
Medium
 This is for important work that should be done soon, but isn't as urgent as a high-priority item. It will likely be considered for the next 1-2 sprints.

  
release-process
All the tickets that are done in order for release process.

  
Sprint Status
Blocked
 Work items that cannot progress due to external dependencies, blockers, or issues that need resolution.

  
Sprint Status
Done
 Work items that have been completed, reviewed, and integrated. No further work is needed within the current sprint.

  
Sprint Status
In Progress
 Work items currently being worked on by a team member. Active development, research, or implementation is happening.

  
Sprint Status
Review
 Work items that are complete but need review, testing, or approval before being marked as done.

  
Sprint Status
To Do
 Work items that are committed to the sprint but haven't been started yet. These items are ready to be picked up by team members.

  
Technical Debt
Work that addresses shortcuts, workarounds, or suboptimal implementations that were done previously to meet deadlines. These items improve code quality, maintainability, or performance without adding new features.

  
Work Item
Bug
 Issues where the system is not working as intended or designed. Bugs represent deviations from expected behavior.

  
Work Item
Epic
 Large initiatives that are broken down into multiple smaller work items (user stories, tasks, bugs). Epics represent significant features or projects that span multiple sprints.

  
Work Item
Spike
 Time-boxed research, investigation, or proof-of-concept work to reduce uncertainty or explore solutions. Spikes help inform future development decisions.

  
Work Item
Task
 Used to break down larger user stories into smaller, manageable implementation pieces. They focus on the specific technical steps needed to deliver the user story's value.

  
Work Item
User Story
 User-facing features or functionality that can be framed from a user perspective, describing what someone wants to accomplish and why.

No labels
after freeze
automation
backlog
blocked
change-ack
change-nak
change-noreleng
changes
Closed As
Can't Fix
Closed As
Duplicate
Closed As
Fixed
Closed As
Fixed with Explanation
Closed As
Get back later
Closed As
Grooming
Closed As
Insufficient data
Closed As
Invalid
Closed As
It's all good
Closed As
taiga
Closed As
upstream
day-to-day
dev
docs
easyfix
epel
f26
f27
f28
f29
f30
f31
f32
f33
f34
f35
f36
f37
f38
f39
f40
f41
f42
f43
f44
f45
fedora
groomed
high-gain
high-trouble
in-progress
in-review
investigation
legal
low-gain
low-trouble
mass rebuild
medium-gain
medium-trouble
meeting
mini-initiative
new_artifact
ops
pdc_retirement
rawhide
RCA
review
script
sidetarget
sprint-0
sprint-1
sprint-2
sprint-3
sprint-4
sprint-5
unfrozen
waiting on external
Backlog Status
Needs Review
Backlog Status
Ready
chore
documentation
points
01
points
02
points
03
points
05
points
08
points
13
Priority
High
Priority
Low
Priority
Medium
release-process
Sprint Status
Blocked
Sprint Status
Done
Sprint Status
In Progress
Sprint Status
Review
Sprint Status
To Do
Technical Debt
Work Item
Bug
Work Item
Epic
Work Item
Spike
Work Item
Task
Work Item
User Story
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Current Sprint ( 2026-07-27 to 2026-08-09 )
Assignees
Clear assignees
No assignees
patrikp
5 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Blocks
#13108 Migration of fedora-scm-requests to Forgejo
releng/tickets
#13414 [fedora-scm-requests] Archive the repository on Pagure and the older one to forge as well
releng/tickets
Depends on
#13368 [fedora-scm-requests] - move the repository
releng/tickets
Reference
releng/tickets#13369
No description provided.