On 2020-04-03 14:43, Aleksandra Fedorova wrote:
On Fri, Apr 3, 2020 at 11:59 AM Petr Viktorin <pvikt...@redhat.com> wrote:
On 2020-04-02 20:07, Stephen Gallagher wrote:
On Thu, Apr 2, 2020 at 12:56 PM Miro Hrončok <mhron...@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".
# 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.
These are linked topics.
ELN is a "build profile" applied to Fedora Rawhide sources. If we take
a working Fedora Rawhide content and apply build profile to it, and it
breaks, then there two reasons why it may break:
1) the content is different because of the conditional, and this
conditional is broken. So we fix it.
2) the build profile is different, then we fix the buildroot and build
flags, and pungi config.
As we have a working baseline, it means that eventually if we reduce
the number of differences we reach the working state. Once we have
that working state we can start _adding_ differences again while
keeping it in a working state.
# 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?
It is not a new thing which ELN changes. Red Hat developers have
always been working with Fedora on changes. If feature makes sense to
Fedora, it is not a matter of the ELN build, it is a matter of
bringing it to Fedora Rawhide.
ELN is not involved in this process.
OK, so would the following answer be correct?
That is not in the scope of ELN. As in the past, the feature can be
either added to Fedora (and ELN) on its own merits, or it can be added
directly to RHEL without affecting Fedora (and ELN) at all.
# 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?
Again, we use raw Fedora Rawhide packages which work.
And if they don't work in ELN, it's up to the ELN SIG to make Rawhide
packages work there. Right?
# 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?
In Fedora - nothing. ELN is not the answer to all the wishes. And we
don't promise that we will ever cover this case in ELN. I don't see
any similarities with Modularity here.
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.
Yes. It can not be build as ELN component, because ELN is about
building Fedora components and this one is not one of them.
It is a downstream trouble to deal with such cases. And we can discuss
our options there. But it is not Fedora and not 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.
RHEL guidelines have no specific power in Fedora discussions. We want
ELN to be part of Fedora, and ruled by Fedora. This is why we submit
it as Fedora change on Fedora infrastructure under Fedora policies.
It doesn't mean that RHEL engineers can not talk to Fedora package
maintainers. It is what open source developers do. And if you are
Fedora packager anyone can approach you and suggest something. The ask
here is to be open to the conversation, not necessarily to agree to
it.
That makes sense.
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!)
Nothing happens, really. As I said above, ELN build failures mean we
stretched too far from Rawhide. When we hit one of those, we try to
resolve it, but the ultimate fallback is always to get back closer to
Rawhide configuration.
If at some point ELN _becomes_ Fedora Rawhide, then it just stops as a
project, because it doesn't make sense anymore.
But now it does. Because we have those differences, we have some of
those rotten conditionals already, but also build flags and also
different comps setup and compose config.
It is not the specs alone, which we can change.
OK. So if a packager chooses to not care about ELN at all, leaving their
package broken in ELN, the ELN SIG can talk to them but, ultimately, the
packager is free to keep the package building in Rawhide only, and it's
up to the ELN SIG to accomodate this.
Is that right?
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)?
There are no such limits proposed.
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
