On Thu, Apr 2, 2020 at 12:56 PM Miro Hrončok <mhroncok(a)redhat.com> wrote:
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.
This is needlessly antagonistic, Miro. We've collected the feedback in
good faith, examined it and then identified shortcomings with it. For
the sake of clarity in the Change Proposal, I've recorded that
reasoning there.
Key questions in the *Detailed Description* remain "out of scope
of ELN" or not
answered clearly.
If something is not clear, please constructively offer that
information. I've been doing my best to rephrase and clarify anything
that has come up. Anything remaining that is "out of scope of ELN" is
literally just that. ELN's scope is largely "Make Fedora Rawhide more
useful to downstream so that downstream developers will work there
instead of internally".
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.
This is a great example of the Nirvana Fallacy. Essentially, you are
arguing that improvements for one group is not acceptable unless it
improves things for every other group too.
Downstream RHEL concerns *are* Fedora concerns. I cannot stress this
enough: Fedora and Red Hat have a highly symbiotic relationship. The
more RHEL succeeds, the more support Fedora gets from Red Hat. The
more Fedora succeeds, the better the resulting RHEL product. It is
disingenuous to imply that something that "addresses mainly a
downstream RHEL concern using Fedora's resources" is a net-negative
for Fedora.
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.
I think you're missing a major point here. The purpose of ELN is for
*that* to be the RHEL test-bed/Alpha. But we want it to stay as close
as possible to Fedora Rawhide because that is how we solve two
problems: 1) lack of consistent involvement by Red Hat engineers in
Fedora and 2) eliminate the long lag-time between when features land
in Fedora and when someone evaluates them for RHEL.
For me this feels like a step back to the [discontinued Fedora
Core](https://www.redhat.com/archives/fedora-devel-list/2007-January/msg0...,
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.
I have no idea where you're getting this from, as we've tried to be
very clear from the start that we want to make the pipeline of Fedora
-> RHEL much more clear. We're not changing access permissions on
these repositories. We're going to be opening up some of the "secret
sauce" so that more of the community can see what we are testing. They
will have greater insight into the potential usage of their packages.
For the stated reasons I am *-1 for this change in its current form*.
That is your privilege as a member of FESCo. As I've said, however, I
think you've misunderstood the situation.
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.
I have read and responded to the feedback as best I know how. Please
do not confuse "I disagree and here are my reasons" with not listening
to the feedback.
Lastly, I don't know if you reread the latest updates (that I made
around three hours ago to the Change Proposal), but I *did*
acknowledge that we are going to incorporate the possibility of
maintaining separate specs for ELN and Rawhide for any maintainer who
absolutely wants to do more manual work. The exact mechanism is going
to at least partly depend on the results of the dist-git forge move,
so I haven't incorporated that into the proposal. Functionally, it
will be very similar to maintaining a separate branch, though.