On 02. 04. 20 19:21, Aleksandra Fedorova wrote:
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 literally addressed this part three times already here on the
mailing list. And three times I got ignored, with someone posting the
same concern again.
If you'd like to have a conversation, please listen to the replies you get.
Hi Aleksandra, sorry for the late reply, I needed to take a break from this.
I am trying very hard to listen and to follow the entire thread. Forgive me if
I've missed some replies or if I don't understand some properly. My vote is
based on the change proposal as written. Could you please also address this in
the proposal?
I'll reiterate again:
ELN is a tool to develop Fedora. Conditionals for ELN packages are
going to be applied in those places where it makes sense and where it
is approved by the Fedora packager.
The change proposal literally says that if a package fails to build in ELN,
conditionals will be updated via a pull request that states a time limit. That
does not imply approval.
Yes, we believe that adding the flexibility in Fedora deptrees and
feature choices is beneficial to Fedora. It is Fedora flexibility,
which can then be used by downstream, whatever the downstream would
be. We are not going to enforce this vision, but we'd like to work
with people who share it, to test if this can actually work.
I am all for flexibility. I am all for e.g. adding bconds to enable/disable
certain things in Fedora instead of patching it out in downstreams.
However I believe that adding "if rhel, use prebuilt docs" is not adding any
flexibility, it adds a layer of downstream specific "hacks" to our specs.
IIRC it was you, who used an upstream-downstream analogy between a software
project packaged in Fedora and Fedora and between Fedora and ELN/RHEL/EL. Sorry
if it was somebody else participating in this discussion.
I will try to use that analogy here: We do not send patches to CPython that add
"%ifdef FEDORA, use /usr/lib64" into their source files. That does not add
flexibility. We send patches to CPython that add the "--withplatlib" option that
we set in our specs to /usr/lib64.
The change proposal literally says that if I do not want to have %if's in my
spec files the ELN SIG may provide a PR as described above or will discuss
alternative approaches on an individual basis with me.
That is very vague. What's going to be in the PR if not conditionals? What are
the alternate approaches for packagers who don't share this vision? It was
repeatedly said in the recent e-mails here that ELN might fallback to regular
rawhide builds in that case. Can this be documented in the proposal please?
You seem to describe this as "some packages are maintained by packagers who
share the ELN vision and others be packagers who don't, so we'll work with the
ones who do". But in my opinion, it is not that simple. One of my concern is
drive-by contributors. What if the Fedora maintainer shares the ELN vision, but
the drive-by contributor doesn't know anything about the ELN differences and
they just want to provide some Fedora enhancement or bugfix, and it breaks the
ELN build? Should such otherwise valuable contribution be rejected because they
don't share the vision and this particular package is part of the "ELN-friendly
set"?
We discard branching as the part of the ELN proposal, exactly because
of the concern that Fedora infrastructure is going to be used by
downstream maintainers to develop downstream packages. We DO NOT want
that. That's why we say: if Fedora packager and downstream can not
come up with the common solution on how to incorporate downstream
changes in Fedora Rawhide, then downstream work can not and should not
happen in Fedora (and as ELN is Fedora, it should not happen in ELN
either).
From what part of the proposal do I deduce this particular approach? Is this
your personal approach you will persuit as a member of the ELN SIG or something
that's worth describing in the proposal?
Branching and dist git sync to downstream can and will happen, but on
downstream terms and on downstream infrastructure. This work doesn't
belong to Fedora, and therefore doesn't need to be discussed here in
this change proposal.
That's fair.
Now you blame us for thing which we haven't proposed.
I am not blaming anyone for anything. I am providing my feedback and opinions on
a change proposal as well as summarizing feedback by others. Can we please take
a step back and not assume blaming? If my language implied blaming, it was not
intended.
And it is hard to have a proper conversation about technical details,
when the goal of the effort is repeatedly misunderstood and
misinterpreted.
If something is repeatedly misunderstood and misinterpreted, maybe it is not
described well? Or maybe the audience doesn't have all the context?
What are the exact goals of ELN? The proposal says "the main goal of ELN is to
rebuild Fedora Rawhide as if it were RHEL." To me, that sounds like an "XY
goal". That is https://en.wikipedia.org/wiki/XY_problem but imagine goals
instead of problems. What is the problem this goal is trying to solve?
For example: If the problem is that branching RHEL from Fedora is painful
because hundreds of %fedora/%rhel conditionals are broken every time, should
there be a "Make conditionals used in Fedora specs future proof for next RHEL
releases" goal? Or if the problem is that Fedora and RHEL are way too different,
should there be a "Make Fedora and RHEL more similar to each other" goal? Or if
the problem is that Fedora doesn't want AVX2 as the default, but we need to test
this now, should there be a "Create a space where changes not yet ready for
rawhide can happen" goal? Etc.
I realize that the goal might be a combination of those or a completely
different one, so don't take those examples very literally. My point is that I
don't understand "rebuild Fedora Rawhide as if it were RHEL" as a goal, but
rather a transitive-goal to achieve something that you've "addressed three times
already on the mailing list" yet I still cannot grasp it from the proposal.
Thanks for not giving up on me.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
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
