On 2020-04-03 14:43, Aleksandra Fedorova wrote:
On Fri, Apr 3, 2020 at 11:59 AM Petr Viktorin
<pviktori(a)redhat.com> wrote:
>
> On 2020-04-02 20:07, Stephen Gallagher wrote:
>> 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".
>
> # 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.