#12925 Restructure scripts directory for better organization and maintainability
Closed: Fixed by jnsamyak. Opened by jnsamyak.

The current scripts/ directory contains 65+ files with minimal organization, making it difficult to navigate and maintain. This proposal outlines a comprehensive restructuring to improve developer experience and repository maintainability.

Current Problems

1. I think we can do better with the structure, poor organization

Flat structure: 65+ scripts scattered in the main directory
Inconsistent naming: Mix of underscores, hyphens, and different conventions
Unclear relationships: Related scripts are not grouped together
Hard to discover: New contributors struggle to find relevant scripts

2. Obsolete Content (Already Addressed)

✅ Module-related scripts removed (post-F39 module retirement)
✅ PDC-related scripts removed (post-F40 PDC retirement)

3. Maintenance Challenges

Scripts with similar functionality in different locations
No clear ownership boundaries for different teams
Difficult to understand dependencies between scripts

Proposed Structure

scripts/
├── builds/
   ├── compose/                # Compose and build tools  
   └── koji/                   # Koji-specific utilities
├── release_process/
   ├── mass-rebuilds/          # Mass rebuild orchestration
   ├── staging/                # Release staging tools
   ├── atomic/                 # Atomic/OSTree releases
   ├── branching/
      ├── fedora/                 # Fedora branching tools
      └── epel/                   # EPEL branching tools 
   ├── staging || syncing/                # Beta/Final Release Scripts
   ├── torrents/               # Torrent generation
   └── signing/                # Package signing tools
├── packages/
   ├── lifecycle/              # Package lifecycle management
   ├── maintenance/            # Package health monitoring
   ├── orphaned/               # Orphaned package processing
   └── distgit/                # Dist-git operations
├── quality-assurance/
   ├── testing/                # QA and testing tools
   ├── critpath/               # Critical path management
   └── ftbfs/                  # FTBFS handling
├── sync/
   ├── primary/                # Primary arch sync
   └── secondary/              # Secondary arch sync
├── infrastructure/
   ├── messaging/              # Fedora messaging tools
   └── ├── governance/
   └── fesco/                  # FESCo policy tools
├── utilities/                  # General utilities
└── misc/                       # Uncategorized scripts

My questions:

  • Are the proposed categories logical and complete?
  • Any scripts that would be difficult to categorize?
  • Concerns about potential disruption during migration?
  • The releng scripts are used at various places, dist-git, ansible, bodhi, koji so this is a MAJOR work which should be moved gradually so we dont end up breaking a lot of things :)

(Also, this doesn't contain mbs and pdc related scripts, because I did those cleanups here: https://pagure.io/releng/pull-request/12924), Would you recommend retiring the ODCS-related script as well?


Metadata Update from @jnsamyak:
- Issue assigned to jnsamyak

Metadata Update from @jnsamyak:
- Issue tagged with: high-gain, high-trouble

I have been hearing about how releng, needs restuctuing from folks working in or with releng, so I'm finally giving this a thought and putting a proactive effort on getting these done, the README will be followed after this migrations happens, and I request you folks to have some patience as well here!

The suggested structure looks good to me. Just one thing comes to my mind. Maybe it would also be good to have those scripts divided by SOPs where it used. So it will have an additional folder with symbolic links to scripts that are used in different SOPs, but it might overcomplicate the structure, so it is up to discussion.

Huge +1 for the effort, it can't be overstated how much we need this.

As for the proposed structure itself, also +1, looks clean, consistent, and entirely reasonable. Besides, we can always adjust it later on if need be.

The structure seems ok to me... we can always adjust it more down the road.

About:

No clear ownership boundaries for different teams

Can we add a common header to all scripts telling who is responsible for it/who can change it?
Of course this is the releng repo, so everything could be changed by releng, but for example the fesco sig policy stuff should be approved by fesco before changes, etc.

Inconsistent naming: Mix of underscores, hyphens, and different conventions

Perhaps top level could have a CONVENTIONS file that explains what to do about that?
ie, 'always use lower case, always end python scripts with .py, no hyphens only _ ' or whatever?

Thanks for working on this. Really needed!

All of these things will need to change in the infra ansible repo when this changes (at least):

roles/distgit/files/retired-packages.cron:30 4 * * * root TMPDIR=`mktemp -d /tmp/releng.XXXXXXX` && chmod 755 $TMPDIR && pushd $TMPDIR >& /dev/null && git clone -q https://pagure.io/releng.git && cd releng/scripts && bash get_retired_packages.sh && popd >& /dev/null && rm -fr $TMPDIR
roles/openshift-apps/bodhi/templates/critpathcron.yml.j2:              git clone --depth 1 --single-branch https://pagure.io/releng.git
roles/releng/files/ftbfs.sh:GITREPO=https://pagure.io/releng.git
roles/releng/templates/sig_policy.j2:30 9 * * 1 root touch /tmp/fedora-compose-sig_policy && TMPDIR=`mktemp -d /tmp/sig_policy.XXXXXXXXXX` && chmod 755 $TMPDIR && cd $TMPDIR && git clone https://pagure.io/releng.git && cd releng/scripts/fesco/sig-policy && python sig_policy.py && rm /tmp/fedora-compose-sig_policy

pungi-fedora will also need changes.

I and @humaton discussed this in our 1:1 call, that we should look into restructuring this first, and then we will do the migrations so when we come to make changes to our documentation, we can simply look into it at all once!

BTW, the EPEL branching scripts won't be necesary. we are droping those in favor of the new ansible playbooks

https://pagure.io/releng/pull-request/12929

Metadata Update from @dherrera:
- Custom field blocking adjusted to 12931

Metadata Update from @dherrera:
- Custom field blocking reset (from 12931)
- Issue unmarked as blocking: #12931

Metadata Update from @dherrera:
- Custom field blocking adjusted to 12931
- Issue marked as blocking: #12931

The structure looks reasonable and as @kevin mentioned it would be good to have CONVENTIONS file or README file with guidelines for writing new scripts.

Also ownership in README file in each category would be appreciated or in header comment of each script.

I think the FTBFS, FTI, and orphaned packages process scripts should be in the same parent directory. They're all FESCo policies that involve cleaning up the distribution by orphaning and/or retiring packages.

(@jnsamyak asked me to add this here).

Okay, I gave @gotmax23 comment a thought, and yeah these are all valid, and on the top of that, I think one of the point of orphaned is also a part of release process Retire FTBFS and orphaned packages; so best approach will be to have a symlink defined between those, I have addressed it in the PR as well. The new structure looks like this:

.
├── builds
   ├── compose
      └── README.md
   ├── koji
      └── README.md
   └── README.md
├── CONVENTIONS.md
├── infrastructure
   ├── fesco
      ├── bug-filing -> release_process/bug-filing/
      └── orphaned -> packages/orphaned
   ├── messaging
      └── governance
   └── README.md
├── misc
   ├── README.md
   ├── rename_script_helper.sh
   └── validate_conventions.py
├── packages
   ├── distgit
   ├── lifecycle
   ├── maintenance
   ├── orphaned
   └── README.md
├── quality-assurance
   ├── critpath
   ├── README.md
   └── testing
├── README.md
├── release_process
   ├── atomic
   ├── bug-filing
      └── ftbfs
   ├── mass-branching
      ├── epel
      ├── fedora
      └── README.md
   ├── mass-rebuilds
      └── README.md
   ├── README.md
   ├── signing
   ├── staging
   └── torrents
├── sync
   ├── primary
   ├── README.md
   └── secondary
└── utilities
    └── README.md
32 directories, 18 files

Thanks. Also, is there a reason the fesco scripts are listed under an infrastructure directory? FESCo and Infrastructure are two separate groups.

Is it intentional that release_process is written with an underscore while everything else uses a hyphen (e.g. quality-assurance, mass-branching)?

Might we consider having a release-process/end-of-life subdirectory?

Thanks. Also, is there a reason the fesco scripts are listed under an infrastructure directory? FESCo and Infrastructure are two separate groups.

The issues we have at releng are sure approved from fesco, but those are heavily linked with the infrastructure team, etc, hence I classified it under infra, and the script that needs fesco intervention should go as a sub-subdirectory from that. Having an independent file doesn't make sense, because we aren't listing policies

Is it intentional that release_process is written with an underscore while everything else uses a hyphen (e.g. quality-assurance, mass-branching)?

It is a typo, it should be a - and not _. I'll check on pr once

Might we consider having a release-process/end-of-life subdirectory?

If there are scripts concerning that, rightfully, it should go there.

Metadata Update from @jnsamyak:
- Issue tagged with: sprint-1

The restructuring work, has been done, and is in monitoring status right now. I'm closing this as fixed, and next steps will be migration for forgejo #12931

Metadata Update from @jnsamyak:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

Metadata