On 2020-04-02 20:07, Stephen Gallagher wrote:
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".
# What if packages don't build on ELN?
The question isn't actually answered. Instead, the proposal answers
*how* packages will fail to build in ELN.
# If a package fails to build on ELN, what will happen?
What will the time limit be?
What exactly happens is a maintainer rejects the pull request?
# What if there is a new upstream feature RHEL wants in a package, how
will that go in?
Why is this not in scope? We're bringing RHEL development closer to
Fedora development. Non-Red Hatters don't know how a feature gets into
RHEL, and I don't blame them if they think this will affect their
workflow. Will it? How?
# What if I do not want to have %if's in my spec files?
What happens if ELN SIG cannot find a solution the maintainer is
comfortable with?
# What if I do not want to have %if's in my spec files, but I want to
see how changes show up in RHEL?
Sorry, but the answer reminds me of Modularity promises that the missing
pieces will be ready in the future.
What will the maintainer actually be expected to do in this case?
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.
It doesn't have to *improve* things for the other group, but if not, it
should clearly acknowledge that it makes things worse (or the same), and
say how. Otherwise that group will justifiably feel excluded.
Say a new package is added to RHEL, which was previously only in Fedora.
The packager doesn't want RHEL conditionals in the spec. The change
doesn't make sense upstream or in Fedora (for example, the crypto
backend needs to be replaced to comply with some regulation). Without
the change, the package (and anything depending on it) cannot be built
in ELN.
As I read the proposal, ELN will work with the packager and try to find
a good solution. However, the discussion might be under pressure of RHEL
guidelines.
What *actually* happens in this worst case? Will the macros be forced
into the package?
(If yes, please say it explicitly, so we can discuss that! If not,
hooray -- alse say that explicitly!)
Even if the worst case scenatio is very unlikely, it would help thinking
about the not-ideal-but-not-worst cases as well.
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.
Yes, that is true! The question is, does the goal justify the means? And
even before that, what exactly are the means (specifically, in terms of
limiting packager autonomy)?
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
_______________________________________________
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
