Re: [ELN] Creating a process for ELN-specific changes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 14. 05. 21 16:29, Stephen Gallagher wrote:
In nearly all cases, we want the `rawhide` branch in dist-git to
provide the sources used to build packages for ELN. This ensures that
they are kept up to date and minimizes packager effort (since they do
not have to maintain an extra branch).

However, there are some cases where changes desired for ELN (and by
extension, enterprise linux) cannot go into Rawhide. A non-exhaustive
list:
* ELN wants to build without documentation, experimental features or
similar and the maintainer refuses to include `%{rhel}` conditionals
in the spec
* Fedora wants to use the latest version of an upstream, but ELN wants
to stay on LTS releases (e.g. Firefox)
* A package is retired in Rawhide but is needed as a dependency for a
package in ELN (usually as a result of the previous example)
* A package exists solely for use in ELN (e.g. lorax-templates-rhel)

I'm sure there are other good examples, but these are what I could
come up with off the top of my head. If you have other use-cases that
we need to consider, please suggest them.

Maintaining a separate branch for ELN requires us to do the following things:
* Create an `eln` branch for the package
* Exclude the package from the Rawhide auto-rebuild

Maintaining an extra branch is more work for the packager, so it
should be avoided whenever possible. Our goal with ELN is to maximize
the value we provide to enterprise linux while minimizing the
additional load that we put on maintainers.

We may also look into the possibility of extending the auto-rebuilder
to attempt a merge-and-scratch-build from Rawhide to the ELN branch,
to reduce maintainer effort if they opt to maintain their package in
the ELN branch manually.


This is tracked in the ELN SIG as https://github.com/fedora-eln/eln/issues/56

First of all: Thanks. This is what many of us wanted from the beginning of ELN and this will allow us to crop many of our unwanted dependencies for RHEL 10+, already in ELN.

An automation that cherry-picks (rather than merges) Rawhide changes into ELN would be even more helpful. In Python Maint, we have some semi-automatic tools ready; let me know in case you want to explore them.


I however do have several concerns to discuss:


1) During the RHEL 9 development cycle, the process was more or less:

     ELN -> Fedora 34 -> CentOS Stream 9

Do we assume similar concept for RHEL 10? I.e.:

     ELN -> Fedora 40-ish -> CentOS Stream 10

If so, every change we make in ELN will be de-facto overridden by the sync from Fedora branched and hence making changes in the ELN branch will not help our RHEL-related work much. Or am I missing something?


2) Who opts in for the eln branch and who is responsible for keeping it up to date? For cases where the Fedora and RHEL maintainers are the same people, it is obviously them. But what about other cases? E.g.:

 1. Fedora maintainer of package foo refuses RHEL-only changes.
 2. RHEL maintainer of foo requests an eln branch.
 3. Fedora maintainer frequently updates foo in Rawhide.
 4. RHEL maintainer does not care about foo in Fedora for 2 years.
 5. The package in ELN is much older than the Rawhide one.

I think this could be solved by policy. Something like "If the eln branch is neglected (needs to be well defined), the package switches back to the rawhide branch."


3) Similarly, assume foo has opted in for an eln branch. The Fedora packager maintainer walks away and foo is adapted by another maintainer who wants to maintain %if-spaghetti rather than 2 distinct branches. How do they opt out? Do we "archive" the eln branch until it is requested again? Or do we merge rawhide and eln branches, sot hey have the same HEAD and than turn eln into a symbolic reference?

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux