https://fedoraproject.org/wiki/Changes/ELN-Extras
== Summary == ELN-extras will be a new build target and compose similar in behavior to ELN, but closer to EPEL in function. It will be a place to prepare and maintain packages that may be desired for EPEL N+1 while RHEL N+1 is still being incubated in ELN.
== Owner == * Owner: [[User:Sgallagh| Stephen Gallagher]] sgallagh@fedoraproject.org * SIG: ELN SIG devel@lists.fedoraproject.org
== Detailed Description == This will essentially be an extension of Fedora ELN, with the primary difference being that the content in ELN-Extras will be defined by the Fedora/EPEL community, while ELN's content is largely decided upon by Red Hat management. This will offer users the opportunity to make sure their applications will work on upcoming releases of RHEL as well as providing a bootstrapping mechanism for EPEL. It will be far easier and quicker to get a compose of EPEL N+1 out the door if the initial packages have already been built for ELN-Extras.
== Benefit to Fedora == This Change will enable application developers to keep up with impending changes in RHEL even before CentOS Stream becomes available for that release. Additionally, it provides a bootstrapping mechanism for EPEL, which will mean a much shorter gap between the launch of a new RHEL major release and the availability of the EPEL repositories.
== Scope == * Proposal owners: High-level tasks
1. Create the tags and targets in Koji (see the release engineering ticket below). 2. Add support to Content Resolver for addon repositories [DONE] 3. Update the DistroBuildSync configuration to support building for ELN-Extras. 4. Configure ODCS to produce an ELN-Extras variant compose.
* Other developers: Aside from the release engineering tasks, anyone who wants to have a package appear in ELN-Extras will need to add it to the content set. This is not mandatory for any packager and we can ship the ELN-Extras repository empty if we so choose.
* Release engineering: [https://pagure.io/releng/issues #10378] * Policies and guidelines: N/A (not needed for this Change) Documentation on how to add packages to the ELN-Extras content set and how to consume its compose will be written as part of this Change.
* Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: Not specifically aligned with the currently-active Objectives. Loosely related to the previous Minimization Objective.
== Upgrade/compatibility impact == N/A, this will be an entirely new compose and thus has nothing from which to upgrade.
== How To Test == No specific testing is required for this Change, though any general OS and software management testing would be most welcome.
== User Experience == Fedora will make available a new add-on repository for ELN, maintained by the Fedora Community.
== Dependencies == This should be self-contained from a dependency perspective. The groundwork was already laid by ELN.
== Contingency Plan == * Contingency mechanism: We will not ship/advertise the existence of the ELN-Extras repository. * Contingency deadline: Final freeze * Blocks release? No
== Documentation == Documentation will be written as part of this Change.
On 11. 11. 21 15:24, Ben Cotton wrote:
anyone who wants to have a package appear in ELN-Extras will need to add it to the content set.
I have some questions:
1) How does anyone add a package to the ELN-Extras content set? 2) Who exactly is "anyone"? E.g. can non-packager users do this? 3) Are there any rules or guidelines for including new packages? Suppose an user wants to add everything, would that be allowed?
On Thu, Nov 11, 2021 at 9:31 AM Miro Hrončok mhroncok@redhat.com wrote:
On 11. 11. 21 15:24, Ben Cotton wrote:
anyone who wants to have a package appear in ELN-Extras will need to add it to the content set.
I have some questions:
- How does anyone add a package to the ELN-Extras content set?
They will need to submit a merge request against https://github.com/minimization/content-resolver-input
- Who exactly is "anyone"? E.g. can non-packager users do this?
- Are there any rules or guidelines for including new packages? Suppose an
user wants to add everything, would that be allowed?
The format for the content set additions includes a requirement to specify the maintainer for the content. If one person wants to add every package... they become responsible for maintaining every package in ELN.
Realistically, all MRs against the content set will be reviewed by the ELN SIG for suitability.
s/ELN-Extras/EPELN/
?
Vít
Dne 11. 11. 21 v 15:24 Ben Cotton napsal(a):
https://fedoraproject.org/wiki/Changes/ELN-Extras
== Summary == ELN-extras will be a new build target and compose similar in behavior to ELN, but closer to EPEL in function. It will be a place to prepare and maintain packages that may be desired for EPEL N+1 while RHEL N+1 is still being incubated in ELN.
== Owner ==
- Owner: [[User:Sgallagh| Stephen Gallagher]] sgallagh@fedoraproject.org
- SIG: ELN SIG devel@lists.fedoraproject.org
== Detailed Description == This will essentially be an extension of Fedora ELN, with the primary difference being that the content in ELN-Extras will be defined by the Fedora/EPEL community, while ELN's content is largely decided upon by Red Hat management. This will offer users the opportunity to make sure their applications will work on upcoming releases of RHEL as well as providing a bootstrapping mechanism for EPEL. It will be far easier and quicker to get a compose of EPEL N+1 out the door if the initial packages have already been built for ELN-Extras.
== Benefit to Fedora == This Change will enable application developers to keep up with impending changes in RHEL even before CentOS Stream becomes available for that release. Additionally, it provides a bootstrapping mechanism for EPEL, which will mean a much shorter gap between the launch of a new RHEL major release and the availability of the EPEL repositories.
== Scope ==
- Proposal owners:
High-level tasks
- Create the tags and targets in Koji (see the release engineering
ticket below). 2. Add support to Content Resolver for addon repositories [DONE] 3. Update the DistroBuildSync configuration to support building for ELN-Extras. 4. Configure ODCS to produce an ELN-Extras variant compose.
- Other developers: Aside from the release engineering tasks, anyone
who wants to have a package appear in ELN-Extras will need to add it to the content set. This is not mandatory for any packager and we can ship the ELN-Extras repository empty if we so choose.
- Release engineering: [https://pagure.io/releng/issues #10378]
- Policies and guidelines: N/A (not needed for this Change)
Documentation on how to add packages to the ELN-Extras content set and how to consume its compose will be written as part of this Change.
- Trademark approval: N/A (not needed for this Change)
- Alignment with Objectives: Not specifically aligned with the
currently-active Objectives. Loosely related to the previous Minimization Objective.
== Upgrade/compatibility impact == N/A, this will be an entirely new compose and thus has nothing from which to upgrade.
== How To Test == No specific testing is required for this Change, though any general OS and software management testing would be most welcome.
== User Experience == Fedora will make available a new add-on repository for ELN, maintained by the Fedora Community.
== Dependencies == This should be self-contained from a dependency perspective. The groundwork was already laid by ELN.
== Contingency Plan ==
- Contingency mechanism: We will not ship/advertise the existence of
the ELN-Extras repository.
- Contingency deadline: Final freeze
- Blocks release? No
== Documentation == Documentation will be written as part of this Change.
Dne 11. 11. 21 v 15:24 Ben Cotton napsal(a):
ELN-extras will be a new build target and compose similar in behavior to ELN, but closer to EPEL in function. It will be a place to prepare and maintain packages that may be desired for EPEL N+1 while RHEL N+1 is still being incubated in ELN.
For these not aware what ELN is:
https://docs.fedoraproject.org/en-US/eln/
Too many abbreviations. :( So the situation is:
EPEL are extra packages for RHEL.
EPEL-next are extra packages for CentOS Stream. [I still think this should be CentOS Stream {extra,epel,next}]
ELN-extras are extra packages for ELN (which is rebuild of rawhide in RHEL like compose).
Right?
Can this change proposal document the name of dist-git branches? I do not see it anywhere.
Miroslav
On Fri, Nov 12, 2021 at 7:33 AM Miroslav Suchý msuchy@redhat.com wrote:
Dne 11. 11. 21 v 15:24 Ben Cotton napsal(a):
ELN-extras will be a new build target and compose similar in behavior to ELN, but closer to EPEL in function. It will be a place to prepare and maintain packages that may be desired for EPEL N+1 while RHEL N+1 is still being incubated in ELN.
For these not aware what ELN is:
https://docs.fedoraproject.org/en-US/eln/
Too many abbreviations. :( So the situation is:
EPEL are extra packages for RHEL.
EPEL-next are extra packages for CentOS Stream. [I still think this should be CentOS Stream {extra,epel,next}]
ELN-extras are extra packages for ELN (which is rebuild of rawhide in RHEL like compose).
Right?
Can this change proposal document the name of dist-git branches? I do not see it anywhere.
That's because, like ELN, it will use the Rawhide branch. Separate branches for ELN/ELN-extras are discouraged (but we are working on ways to allow them for specific cases).