On Fri, Mar 27, 2020 at 11:07:41AM -0400, Stephen Gallagher wrote:
> == Summary ==
> ELN is a new buildroot and compose process for Fedora that will take
> Fedora Rawhide dist-git sources and emulate a Red Hat Enterprise Linux
> compose. Feedback from this build, compose and integration testing
> will be provided to Fedora packagers so that they can see the
> potential impact of their changes on RHEL development.
Thanks, the new page is much better. Esp. this new summary is
massively better.
Some specific things which are still unclear:
> Setup automation to trigger new ELN build every time there is a new
> update submitted to Fedora Rawhide.
Does "update" in this context mean the automatic bodhi update used for
gating? What does "submitted" mean — the time when the update is
requested, on when the update is pushed to rawhide, or ... ?
> Post build result to Fedora Messaging, so that it appears in Bodhi
> and can be used as a gating test
Continuing with the previous question, is the "gating test" for the
original rawhide update?
> The SIG will [...] maintain infrastructure required to build packages and composes;
Does this mean that some new person will join releng?
> we will not be shipping any content produced from ELN directly to
> the general public (such as on the standard mirror network
Hmm, so those packages will be pulled directly from koji? Is the
additional load acceptable?
> Contingency mechanism: If this effort doesn’t land in Fedora 33 we
> review it and decide whether it needs to be moved further to Fedora
> 34 or be cancelled.
OK, and what about the case where it is enabled, and then during the
way it turns out to be too much hassle? Is there some sunset procedure
planned?
> What if there is a feature RHEL wants in a package, how will that go in?
> That is not in the scope of ELN.
Does "not in scope" mean that the question is not answered, or does
it mean that ELN is not relevant to the question?
The latter seems a bit impossible. ELN is all about making rawhide
packages more like the packages in RHEL, and this naturally means
adding and removing features or changing dependencies or configuration
falls into the scope of ELN. I.e. if I'm a RHEL maintainer, opening
a PR against Fedora dist-git with a bunch of '%if %{eln}' conditionals
or not seems the most straightforward way to push towards having a
feature in RHEL...
Zbyszek
_______________________________________________
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
