On Tue, Mar 24, 2020 at 3:17 PM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote: > > On 24. 03. 20 10:32, Aleksandra Fedorova wrote: > > As Ben is on PTO, I'd like to present the System-Wide Change > > > > https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose > > > > == Summary == > > > > The goal of the ELN project is to continuously build Fedora Rawhide > > packages and composes in the way which resembles the CentOS and RHEL > > build process and to provide a feedback loop for Fedora maintainers on > > the status of those builds. > > Form a Fedora POV, this doesn't state what's being "changed" at all. > I would appreciate if it actually said something about the ELN Buildroot and > Compose. > > > ELN is an evolution of the request for an alternate buildroot for > > newer x86_64 processors. The reasoning behind that new buildroot was > > that we expected that the next major release of RHEL would likely drop > > support for older hardware and therefore could take advantage of > > enhancements and processor extensions available for newer hardware. As > > plans for this proceeded, they expanded into a desire to do more than > > just test out the processor architecture. Instead, we want to have a > > complete alternative compose of Fedora Rawhide that resembles the way > > that Red Hat and CentOS builds their packages. The idea being that > > Fedora developers and third-party vendors who rely on Red Hat > > Enterprise Linux have a place where they can directly contribute to > > what will eventually become the next RHEL. > > I don't understand from the rest of the change how do they contribute to ELN. > > > ELN (Enterprise Linux Next) is going to be that place. What we want to > > do is establish a set of RPM conditionals that can be used for the set > > of packages that may need to be built differently for a RHEL-like > > target as compared to a Fedora one. (For example, we may want to skip > > regenerating documentation during package-build and instead use > > pre-built docs from the tarball or SRPM.) > > What set of RPM conditionals? This is more clear from the FPC ticket: > > https://pagure.io/packaging-committee/issue/955 > > But even there, it seem that any new conditionals will be discouraged, so what > are the new conditionals this change is talking about? > > > This includes: > > > > * buildroot configuration, rpm macro and compile flags, > > * comps files and the compose content, > > * compose itself and the pipeline which builds it. > > Where are those rpm macros and compile flags be defined if this builds from > master? Will there be an alternative branch for (and only for) > redhat-rpm-config, or will redhat-rpm-config be full of such new conditionals? > Are the maintainers of redhat-rpm-config on board? > > > ... Some unknown number of packages that rely on `if ! > > 0%{?fedora}` will require manual intervention. > > And many other cases, see the FPC ticket. > > > * CentOS Stream, EPEL and RHEL > > ** We are going to build Fedora packages into a compose similar to the > > multi-repo structure of CentOS and RHEL. > > This lacks any details in the description. > > > ** The feedback pipelines built for the project will allow downstream > > developers to open up their work and bring it closer to Fedora. In > > particular, it will enable projects like OpenShift to do their work in > > Fedora. > > I don't understand how. Do you have more details? > > > == Scope == > > * Proposal owners: > > ** Setup build environment for a new disttag (`eln`). > > ** Setup automation to trigger new ELN build every time there is a new > > update submitted to Fedora Rawhide. > > ** Post build result to Fedora Messaging, so that it appears in Bodhi > > and can be used as a > > [https://docs.fedoraproject.org/en-US/rawhide-gating/ gating test]. > > ** Setup automation to run periodic partial composes (via ODCS) > > without installation media to generate repositories with these > > packages. > > ** Update packaging documentation to mention new disttag and how it can be used. > > > > * Other developers: > > *: Anyone who wants to produce different content for the ELN compose > > will need to implement the new macros in their specfile. The > > overwhelming majority of packages will require no modification. > > I don't understand the meaning of "implement the new macros". Do I read it that > if I want to produce different content for the ELN compose, I need to use %if > conditionals for %{rhel}? What if I don't want such conditionals, because I > prefer to have separate branches? > > I also don't understand how this will work if only the packager who want this > will participate. Assume you need to build your package "like in the next RHEL", > so you adapt it (let's say you disable the "shakehands" feature, because you > don't plan to include "libshakehands" in future RHEL). As a consequence, > packages depending on your package and might also need adapting (becasue they > assume the shakehands feature is available by default). What if the maintainer > of a dependnign package doesn't like %{rhel} conditionals in their specs? Will > the changes be forced? Or will parts of the ELN compose fail to build or install > forever because of this? > > > == User Experience == > > > > There is no user-facing part in this change. No ELN artifacts are > > going to be shipped to the end-user. > > As a packager debugging a problem in ELN, how do I consume it? > > ----------- > > General questions/feedback follows: > > The description of this change is very vague. I don't know if it is intended or > not, but it is very unclear to me, how will this new buildroot work. For example: > > Will there be any inheritance from rawhide? After the FESCo meeting I assume > yes, but would like a record of this on the mailing list. > > > How do we bootstrap things in ELN without disturbing regular rawhide? For > example, assume the following situation: > > There is libchicken-1 and libegg-1 in rawhide as well as ELN. They require and > buildrequire each other. The maintainer needs to do an update. He does the > following in Fedora: > > - request a side tag > - builds libchicken-2 with bundled egg-2 > - builds egg-2 > - rebuilds libchicken-2 against the egg-2 package > - request a side tag merge > > What happens in ELN? Will all side tags automatically create a bound ELN side > tag? Or after the side tag is merged, libchicken and libegg will be untagged > form ELN and rebuild against the rawhide versions? > > > What happens upon ELN build failures? Assume the omelette package fails to build > in ELN because the chicken and egg problem. Who will chase this and how? Will > the omelette maintainer receive an automatic bug report to fix their package or > will an ELN developer fix this for them? Where do they commit their fixes, if > everything builds from master? > > > Will there be a way to opt-out packages (or stacks of them) from ELN if they are > not interesting for RHEL? > > > I could go on with further scenarios and what-ifs. I undrstand if the answer is > "we don't know yet". But the Change proposal should at least try to explain how > this buildroot works. I am going to answer generally in this mail, before we dive in into discussing the details. I think your approach to assessment of the Change is not fair. It is an infrastructure change, not a code one. Figuring out all of the questions you are asking is exactly what this change is about. And you are requesting that we put the entire solution into the change proposal. This is not going to work this way. And it shouldn't work this way. There is a reason why Change Template has Description section and does not have Design or Implementation. Because design and implementation are left for the owners of the change as we will figure out the details on our way to it. The goal of the Change process is to assess the idea, the impact, to check whether there is a disruption this change brings, and to find people who are interested in it. Then we can work on the change together, working through all those questions you have mentioned. You are asking good questions and I value your feedback. But yes, the current answer to most of them is "we do not know yet". For example, even though the structure of the buildroot is proposed in the releng ticket, and we would like it to inherit rawhide buildroot at this point, we may want to change it later. So I'd ask you to split the conversation into two parts: 1) what are the expectation, requirements, impact and risk for this Change This is what we do need to add into the Change proposal, as it sets the boundaries in which we should operate. 2) how it is going to work This goes to design docs and implementation. We will definitely take all comments from the mailing thread into account. As soon as we figure out the place where we track the effort (most likely, Taiga) we will transfer it all there. But we would like to postpone making decisions on those topics. Because things may change while we are working on them. And it should be ok to change them, as soon as we keep the boundaries. > > > An extra question: How does this play with modularity, if at all. Do we also > rebuild all modules? > > -- > 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 -- Aleksandra Fedorova bookwar _______________________________________________ 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
