On 24. 03. 20 19:55, Aleksandra Fedorova wrote:
On Tue, Mar 24, 2020 at 6:01 PM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote:
On 24. 03. 20 16:23, Aleksandra Fedorova wrote:
I think your approach to assessment of the Change is not fair.
Ouch. It's just that reading the proposal raises all of those questions. Sorry
if that's not fair.
Sorry if that sounded offensive. I didn't really mean it. And I am not
against asking questions, please do.
I do think that not all questions need to be answered now. Not all an
be answered and not all should. So I was trying to propose splitting
it up into what needs to be decided now, and why. And what can be left
later.
But going too meta probably was a wrong move by me here. So let's get
back to the actual questions.
Thank You, Aleksandra.
The main risk I see is that this will generate a need for mass pushing various
conditionals all over Fedora. And while some maintainers like those, some don't.
And I'm afraid this is not fair to them, if we approve this without knowing.
Do you have a suggestion, how to make it clear that there will be no
enforcement?
It should describe how do the ELN/RHEL maintainers achieve changes over Fedora
(if needed) other than %if 0%{?rhel} conditionals in case the Fedora maintainers
don't want those. If the conditionals are the only way to achieve the goal,
there will either be "enforcement" or there will be "breakage".
We've put it in the proposal that we are going to provide feedback in
terms of test results visible on the bodhi page using Rawhide Gating.
There are no plans to make gating on that test mandatory, as we leave
it to package maintainers to configure gating in general.
So let's assume for the sake of the argument, that Python is broken in ELN and
the Python maintainers don't want 0%{?rhel}/0%{?eln} conditionals in their spec
files. Now all 3600+ Python packages will fail to build in ELN because of this
and the feedback provided in bodhi will be moot. What will happen then?
We may also propose pull requests with changes to some packages when
we'd like to suggest a fix for the dependency or adjust compile flags.
Adding the conditionals? What happens if the maintainer says "I don't like
conditionals in my spec files, please, maintian this in ELN separately please"?
If that is not possible two things can happen: More pressure to accept the Pull
Request ("it is just a simple %if and it will fix 3600 packages..."), or even
provenpackagers pushing changes. (The other way is to keep ELN broken, but that
defies the purpose of ELN.)
Side note: I realize perfectly that package maintainer should not be absolute
dictators and that they don't "own" their package, but that they are rather
"stewards" (in fact, I argue we should make this more clear). However changes
like this can create unmaintainable %if spaghetti (we've been there with the
Python 2 -> 3 transition) and hence I think the person who primarily needs to
maintain the package has something to say about whether they want a certain
packaging idiom in "their" specs.
The change should at least describe what level of involvement is required from
other contributors. It it is "no involvement needed" and "we will not bother you
with conditionals" than I see no risk for Fedora (distro) (but I see a huge risk
for the ELN project, because it will be unable to fix itself).
The answer here is that we _may_ bother you with conditionals, but we
don't know yet how often it may happen.
Do you want us to keep track on usage of %{eln} in spec files? I think
this is doable.
Stephen made it clear that the usage of %{?eln} will be very rare. What I worry
is added overhead with %{?rhel}/%{?fedora} conditionals. Keeping track won't
help -- hundreds (thousands?) of packages already use those and hundreds
(thousands?) don't. What I worry about is that this will become the only way to
achieve things.
2) how it is going to work
This goes to design docs and implementation. We will definitely take
all comments from the mailing thread into account. As soon as we
figure out the place where we track the effort (most likely, Taiga) we
will transfer it all there. But we would like to postpone making
decisions on those topics. Because things may change while we are
working on them. And it should be ok to change them, as soon as we
keep the boundaries.
I don't see a reason to postpone this discussion. It may affect critical design
decisions. And we have seen in the past that postponing some problems for later
(e.g. upgrade path or switching streams in Modularity) can lead to a serious
design issues that are very hard to fix later.
I wasn't proposing to postpone the conversation. I suggested to split
it into two groups.
OK, sorry for misunderstanding what you say. I don't know how to classify my
feedback to this two groups (I don't really feel the need either), but feel free
to do that when you triage it.
And for first group to add a question on "why should we know the
answer to it right now? What does it change? Which risk or requirement
it addresses".
We need answers to those questions before we start pushing stuff to packages
maintained by community maintainers who would only consider this a RHEL's
business and feel frustrated/betrayed/disappointed by this.
I'm not just being paranoid: This happened in the past - Fedora packagers were
asking questions, the questions were dismissed ("nah, we'll solve this later")
and after several releases, it kicked us (and the "I've told you so and you
didn't listen" answers to that were very bitter and the problem paralyzed the
community for months and several Fedora releases).
So back to buildroot inheritance question as example. We have the
conversation in the releng ticket [1] where the current Koji tag
structure is proposed. With eln buildroot inheriting Fedora Rawhide
buildroot at this point.
If I understand correctly, you are saying this information needs to be
in the Change proposal.
Yes. What this buildroot is and how it works is an essential part of the change
but is not described in the proposal at all.
So if three weeks after we've got the access to the tags we decide to
remove the inheritance as we collect enough ELN packages in its own
buildroot, would you expect us to file another Change Proposal for
another Fedora release to update that?
No. What I ask is that you thought this thru based on the feedback here and in
that FPC ticket and releng ticket and you make a plan. That plan shall be
described in that change and not just in some Taiga. It's completely fine if the
proposal says something like:
"The buildroot will inherit form rawhide in order to bootstrap itself, later a
decision might be made to disable this inehritence once we collect enough ELN
packages in its own buildroot. This can change back and forward as needed."
This let's you do basically anything you want but it also communicates your
plans clearly to the community. Not saying anything is worse.
--
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
