On Wed, Mar 25, 2020 at 11:47 AM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote:
>
> 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.
(snip)
> 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?
What about using an additional "eln" branch in dist-git?
- For most packages, the master branch should be able to be merged
into eln regularly (or even automatically, triggered by master
commits).
- For the packages that need "unacceptable in master" adjustments, an
automatic rebase on top of new master commits could be attempted, and
if that fails, human intervention is necessary anyway.
Fabio
> > 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
_______________________________________________
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
