On Wed, Mar 25, 2020 at 02:06:59PM +0100, Aleksandra Fedorova wrote: > Hi, Miro, > > On Wed, Mar 25, 2020 at 1:28 PM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote: > > > > On 25. 03. 20 12:49, Aleksandra Fedorova wrote: > > > Going back to the questions. See comments inline. > > > > Thanks. > > > > >>> 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. > > > > > > It says that we are going to continuously build el-like compose. We > > > are adding new pieces of infrastructure to make that happen. > > > This is an infrastructure change, which doesn't change Fedora content. > > > > It will eventually change Fedora sources. But even with "this doesn't change > > anything" argument, I find the current summary confusing a bit without reading > > the rest of the proposal. Can a second sentence like "A new buildroot will be > > added Koji that will automatically build packages from master but it have a > > different set of macros and config." be added? > > > > >>> 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. > > > > > > By contributing to Fedora Rawhide sources and consuming them as ELN > > > repositories for testing purposes. > > > > The change proposal literally says "There is no user-facing part in this change. > > No ELN artifacts are going to be shipped to the end-user." > > > > As a contributor, how do I consume the content if I cannot consume the content? > > As I understand it, the "end-user" and "user-facing" terms must have different > > meanings in this context, right? What is this meaning? > > Looks like terminology issue. For me user is a person who uses > released Fedora, like Fedora 31 Workstation, on their laptop, or > Fedora 32 IoT edition on their Raspberry Pi, or a minimalistic Fedora > for Fedora server. > Basically anyone who needs Fedora to solve their own problems, which > are not related to development of the distribution. > > Fedora Rawhide is not a user-facing branch in Fedora, because it's > purpose is to develop Fedora, not something else. > Same with ELN. It is not a Fedora Server edition, there is no reason > to ever use it on a server. It is a rebuild of Fedora Rawhide, and > it's purpose is the development of Fedora, and help others to > contribute to that development. > > So it is facing contributors, not users. > > Different types of contributors though. OK, we should be on the same page wrt. to the meaning of "end-user". But what about developers: if one wanted to use eln for the purposes for which they currently use rawhide, how would they go about it? (In particular: running rawhide on their personal computer to find bugs early, compiling upstream projects on rawhide for compatibility testing, using rawhide when doing new packages, running rawhide just to have everything newest). > > >>> 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? > > > > > > As a nitpick, it doesn't say _new_ conditionals there. As we don't > > > want to branch Fedora Rawhide we need a possibility for certain > > > package to be built differently in the ELN environment. > > > > The ticket says the "new" conditionals (with %{eln}) will be discouraged. > > Hence the means to achieve the goal will be the "old" conditionals (with > > %{rhel}/%{fedora}). Correct? > > > > > For that we need rpm conditionals based on disttag. > > > > This might be a terminology dispute and bike shedding, but I still don't > > understand what does "conditionals based on disttag" means. I've asked for an > > example in the FPC ticket and apparently the conditionals are not to be based on > > disttag. I think a very thorough decision should be maade regarding the > > conditionals and dist tag: > > > > - should %{fedora} be defined at all? > > - should %{eln} be versioned? > > - should the dist tag be versioned? (see Neal's point with the Koji nevr check) > > > > We can surely do it in the FPC ticket, but people are not gonna find that > > discussion there. > > > > > This is a chicken and egg problem, to be honest. To figure out the > > > details we need FPC and others contribution, but then to start talking > > > to FPC we need a Change Proposal so that you get the idea what are we > > > trying to achieve and why. > > > > As a member of the FPC I don't think you need to involve FPC at all at this > > point other than getting feedback. And I don't see a chicken and egg problem in > > here - you have the proposal and we are discussing it. > > > > >>> ... Some unknown number of packages that rely on `if ! > > >>> 0%{?fedora}` will require manual intervention. > > >> > > >> And many other cases, see the FPC ticket. > > > > > > Let's discuss it in the ticket then? > > > > I'd rather discuss this here and only come to FPC for approval of new guidelines > > when ready. The FPC members who are likely to discuss this are already > > discussing this here. Why spitting the discussion into two places? > > Sorry, my understanding of why we need RelEng and FPC tickets was > completely the opposite. Mailing list discussion about the Change is > generic, and gets side-tracked to one side or the other and digging > through it to get the pieces which are relevant to FPC topic is > harder. While ticket has a fixed topic, discussion associated to it > and the outcome of that discussion. I don't see how you can prevent > people from discussing the topic in the ticket and move it to the > mailing list. > > If you see FPC ticket as a "request to vote" only, why do we need it > then? Can't we just invite FPC representative to vote on a FESCo > ticket? IMO, it is too early to involve FPC, because it is very unclear what the goals are, and what kind of differences from existing Fedora packaing are indended. Once that part has been clarified, then FPC can decide the specific form of macros and other packaging changes that best implements those goals and adjust the packaging guidelines. So yes, let's please discuss this here. > > However, if you prefer to discuss this in the FPC ticket, sure. There is plenty > > of feedback now (from people who I assume have come because they have read my > > e-mail with the link, but maybe they were just subscribed to the FPC > > tickets...). FESCo and FPC tickets are IMHO not a good place to discuss ideas > > like this: > > > > - there are no threads > > - people there are not "equal" (one group is in the position of power) > > - people usually don't follow new tickets > > > > >>> * 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. > > > > > > I am not sure what kind of details you expect. > > > > > > Will it help if I add a link to CentOS compose? Like this one > > > http://mirror.centos.org/centos/8.1.1911/ > > > > Partially, yes. Bot mostly: Who decides how is this new repo split into multiple > > repos - is it a Fedora (aka FESCo) level decision, or does releng maintain this, > > or is it part of the ELN configuration maintained by the change owners? Can > > Fedora contributors contribute to this, or is it an internal RH decision? > > Ok, going to update that. > > > >>> ** 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? > > > > > > For third-parties who develop services and tools for CentOS and RHEL > > > it is important to have development environment which is close to what > > > they will achieve in the released version. > > > Fedora Rawhide is the future RHEL, but as it is packed differently it > > > is harder to rely on it, when you plan the future of your third-party > > > service. > > > > > > ELN compose is a preview of what may happen if we take current Fedora > > > Rawhide and try to make CentOS/RHEL out of it, like right now. It is a > > > preview of issues we are going to have as well. > > > > Let's not repeat Neal here: > > > > https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/MQVV4AAXLLYJCU5AHPOP5MJOEUVKZCT2/ > > > > "Nothing has ever stopped any project from using Fedora..." > > > > >> 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? > > > > > > Do you have specific example or asking generally? > > > > There are some examples elsewhere in this thread. But I am asking generally. > > > > > I think that not having eln-branch is very important part of the > > > concept as we don't want to fork Fedora. By using conditionals in spec > > > files we do create variants of the rpm, but at list we get them > > > automatically synced with the upstream sources. So whenever you update > > > the package in Rawhide, ELN binary package is updated too. > > > > > > Conditionals create problems indeed, we should use them carefully. I > > > would prefer if instead of conditionals we find ways how to make > > > Fedora packages more flexible, change from Requires to Suggests for > > > example, or split into subpackages. > > > But in this case I think conditionals are a much better choice than > > > branching, as when done once, they require less maintenance on their > > > way to downstream. > > > > Sure They are good for downstream. RHEL clearly benefits from this. > > But they impose additional cognitive overhead on the community maintainers in > > Fedora. > > > > > > > We add conditional in Rawhide, we inherit it in branched Fedora, we > > > consume it in CentOS Stream, we get it in EPEL. All of it happens > > > automatically once we have the ELN compatibility in Rawhide. > > > > This is all nice only as long as you prefer conditionals over branching. For a > > Fedora maintainer who doesn't, this is just "unnecessary cruft" in the spec file. > > It is not really about personal preferences. These are two different > approaches with different purposes, different results and different > requirements. > There are consequences on choosing one other the other. > > Branching means forking Fedora Rawhide into something else. Which > eventually will lead to new downstream tree which will ignore the rest > of Fedora and just use the fork instead. It can be done, but I think > it will damage Fedora as a project. IMO, that significantly overstates the difference between the two. In particular, branching is exactly what happens every six months when we start a new release, and yes, it is possible for the branches to diverge, but no, it is also possible to keep the branches synchronized and actually for many packages this is what happens. For any specific package, whether the branches are similar or divergent depends on the situation of the package and maintainer choices. Also, a side note: with the planned changes to do away with changelogs and release tags in .spec, branches have the potential to become identical (i.e. we would still have branches, to know what to build where, but they would point to the same commit). Heavy ifdeffery in spec files is something of a past. Different maintainers have different preferences, but I think it is fair to say that we have moved significantly in the direction of simplified spec files and less conditionals. I think you shouldn't discount the separate branch approach just yet. > > >> 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? > > > > > > We don't have power to enforce anything, and we don't want it. > > > > > > We'd like to find such problematic places and start a conversation for > > > them. See if we can negotiate a better solution: split into > > > subpackages, maybe use modules even. There is no one good answer which > > > fits for all, it needs to be resolved on a case by case basis. > > > > > > Yes, there is a risk that it won't work. And we have a very clean > > > contingency plan for it: we shutdown the whole thing. > > > It will be unfortunate, but it is an option. > > > > What is to stop us saying "stop acting like we can stop doing this now and start > > over at this point" when we realize this is hurting the Fedora community, but we > > need to ship next RHEL? (Sspeaking from experience. Things like this were said.) > > I don't understand your question. Nothing ever stops anyone from > saying anything. But it is FESCo and Fedora Council who have the > decision power. > > But if you look at the change you'll see that it has no blocking > features whatsoever. We are not changing how Fedora is built and how > it is released. > So if you have a worry that this change is hard to cancel, please > explain why you think so. Whenever we do something, we have some obligation towards our users and fellow contributors. I do packages, and if create a package, I have to take into account that the package be used and I cannot yank it next week. Or maybe I can, but it'll make people unhappy. The same principle applies in case of eln, but on a much larger scale. Miro mentioned the potential need to keep eln around to ship next RHEL. But there are other cases: openshift upstream was mentioned. If they hypothetically decide to rework their development process to base it on eln, just dropping it one day would not be inconsequential. If eln is to be advertised for serious use, then I would at least expect the contingency mechanism to include a transition mechanism. Maybe move people over to rawhide, or maybe promise 6 months of heads-up before removal. Neither seems easy or satisfactory. Zbyszek _______________________________________________ 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
