On what architectures ELN builds will happen, are you going to add more builders to koji (esp. ppc64 and s390x)?

Our intention is to have them build for all architectures. We are looking into what resources we need to provide. At present, we intend to submit all ELN builds at a lower priority than any other builds in Koji so they will not be a huge burden.

The change proposal received overly negative feedback by the packager community as represented both by RHEL¹ and non-RHEL maintainers. Despite being reworked several times, none of this feedback was reflected in the proposal, only new reasons why this is going to be done the original way were added. It seems that feedback is collected not to find the best technical solution, but rather to find ways to justify a solution that's already decided.

Key questions in the Detailed Description remain "out of scope of ELN" or not answered clearly. The proposal should address the impact on all major packaging styles, and while one side of the spectrum (packagers preferring single-spec with conditionals) is covered, there are very few concrete details on the other (packagers interested in simple spec files or completely uninterested in RHEL). The affected packagers are concerned that the current proposal does not in fact benefit Fedora (to an extent that would justify the disruptions), but rather addresses mainly a downstream RHEL concern using Fedora's resources.

While benefiting the entire Fedora/RHEL/CentOS/EPEL ecosystem is certainly a good goal, I believe that doing this in a way that alienates a significant part of our packagers is a disservice to Fedora. The concerned packagers believe that Fedora is (and should remain) the upstream for RHEL, not RHEL itself. This might be shifting us to the undesirable mindset that Fedora is only a test bed for RHEL or a RHEL alpha version.

For me this feels like a step back to the discontinued Fedora Core, where the packages that were included in RHEL could only be maintained by their RHEL maintainers. Fedora relies on the contributions of non-RHEL developers — and those often have little interest in downstream work. If we alienate the community contributors, it will ultimately lead to a worse RHEL down the road.

For the stated reasons I am -1 for this change in its current form.

As said on the mailing list, I'd appreciate if you take the feedback provided by the packagers more seriously and adjust the proposal accordingly.

As a side note, I'd like to continue the discussion on the mailing list, as I believe there's still plenty to discuss. That's why I'll also post this text there, so you can quote-reply.

¹ For any interested Red Hatters reading this: Apart form the feedback received on the devel mailing list, I discussed this internally with my Red Hat team, Python-maint .The whole team shares my concerns, as do other members of Core Services.

Alright, I read the Change proposal again, and some feedback seem to have been incorporated in the latest version. I'm still not really happy with how this is supposed to work, though - and with that I don't mean the technical implementation (which looks reasonable), but the interpersonal issues that will probably arise at some point or another when ELN SIG wants to add conditionals to a package whose maintainer doesn't want them. I am aware that there's going to be another layer of indirection between ELN and RHEL-next internally, which should resolve those issues, but I'd like to have those changes be worked out in public rather than internal to RH (which I think is the whole point of this endeavour?)

Based on the Change proposal and the feedback on the devel list (which I read almost in its entirety), I think the technical side is "fine" (even though I don't agree with some things that are just stated as fact), but the "personal" side of this Change might become problematic, when maintainers don't like the changes you're trying to put into their packages - fedora is a distro in its own right, and not only "rhelhide" - and I think the discussion on the devel list reflects that sentiment, as well. I'm a bit worried that "we'll figure something out" might just not be enough for ELN to succeed in the long run.

So I'm voting ±0 on the current proposal.

Side note: I think more people would be amenable to including "conditionals" into their packages if they weren't only shown off as %if eln this else that. I think there's more value in doing "feature flags" rather than conditionalize everything based on the dist tag, for example something like this might even be useful in fedora branches (e.g. for bootstrapping):

# at the top of the .spec file, where it's easily visible
%if 0%{?eln}
%bcond_with docs
%else
%bconf_without docs
%endif

# ...

%if %{with docs}
# do something
%endif

This makes conditionals (when they are necessary) much easier to maintain (and understand), in my experience.

There have been changes in the proposal after I have last read it before I voted -1. Scratch that vote for now, I'll vote later.

So in general I like the idea.

But remember one thing that your builds will be not very useful without koschei-in-non-scratch-mode or something similar. If you will be simply mirroring builds for ELN target, you might have a problem that some packages might break because they were built in wrong order.

Also don't forget about side tags. There anything can be tagged in, then build performed and then only some parts of builds tagged back to rawhide (or any other branch).

tl;dr I did not see any technical details how these builds will be spawned, managed over the time and so on.

fedora-repos-eln, even if will have lower priority, it still will be used if rawhide has broken dependency on a package while eln package does not.

Also, if you want to standardize conditionals, please don't do anything horrible in spec files. Make it standard part of koji (it supports setting macros already, but not in such extensible way).

I'm voting ±0 now and would like to see more technical details how this is supposed to be handled.

Updated description with the v4 announcement from sgallagh.

With the recent changes to the proposal and @sgallagh 's clarifications on the devel list, I'm changing my vote to +1.

I intent to vote in favor, but I'm monitoring the devel discussion in case it brings any valuable feedback that would make me reconsider.

The devel list discussion appears to have tapered off, so I think it's probably time to hold the formal vote.

I'm +1, obviously.

+1 too.

I think the proposal does a good job of ensuring that Fedora will not be disrupted and that this will not cause issues to maintainers who do not participate in the eln effort. I consider the eln side is to be a big unknown — until somebody does a rebuild with the changed defines, we won't know how many failures there are, and more importantly, if the failures are frequent enough to cause cascading failures. But I personally have no experience with RHEL packaging, so my intuition is very weak.

+1

+1 after reading the latest draft. Thanks for incorporating changes and clarifying things based on feedback.

+1 from me

@zbyszek Part of the problem is that RHEL packagers also don't know how many failures are there.

I think as ELN SIG we will setup a regular (bi-weekly probably) IRC meeting and reports for the "health" of ELN buildroot. So that we keep track on how many failures in packages and composes we get. This will give us the data to see if it actually works.

+1 here. I think it's a good idea worth trying out and hopefully it makes things better.

"Seven positive votes with no negative votes will immediately approve a proposal"

APPROVED +7, 1, -0

Announced in https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MOE6W2RO52Y5I6PFHZ7G7VQO6ZYV7HP7/