ELN branch request policy

Most packages should be able to build for ELN as-is. When changes are required, the ELN SIG strongly recommends the use of specfile conditionals in the rawhide branch. This minimizes workload for packagers, improves interoperability and guarantees that the package will always be in sync and up to date.

When conditionals are not appropriate, a dedicated ELN branch can be requested. ELN branches can be requested by filing an issue on the ELN SIG tracker; these requests will be evaluated by the SIG and put to a vote during the next meeting.

Approved ELN branches will be versioned to the current EL release and lifecycled with it. This means that e.g. an ELN branch requested for the el9 cycle will only be used during that cycle, and will be named eln9. When the next CentOS Stream cycle becomes available (el10 in this example) the package will reset to building from Rawhide. If an ELN branch is still required, the maintainer will need to request it again (and it would be named eln10 in this example).

Examples of scenarios where a dedicated ELN branch can be appropriate:

• a package needs to ship a different version in ELN vs Fedora; alternative options could be leveraging Modularity, or making a separate package altogether (e.g. foo-esr vs foo)
• packages where conditionals are overly cumbersome to maintain in rawhide

Examples of scenarios where a dedicated ELN branch is not appropriate:

• retired packages; this should be unretired and maintained as normal
• packages requiring trivial changes for ELN compatibility; these should be handled with conditionals in the specfile
• branding changes; these should be handled with conditionals