Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V3

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

 



On Thu, Apr 2, 2020 at 12:56 PM Miro Hrončok <mhroncok@xxxxxxxxxx> 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/msg00091.html),
> 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.
_______________________________________________
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




[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