4:32 a.m.
As Ben is on PTO, I'd like to present the System-Wide Change
https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
== Summary ==
The goal of the ELN project is to continuously build Fedora Rawhide
packages and composes in the way which resembles the CentOS and RHEL
build process and to provide a feedback loop for Fedora maintainers on
the status of those builds.
== Owner ==
* Name: [[User:Bookwar| Aleksandra Fedorova]]
* Email: alpha(a)bookwar.info
* Name: [[User:Sgallagh | Stephen Gallagher]]
* Email: sgallagh(a)redhat.com
== Detailed Description ==
This Change supersedes the previously-approved [[Changes/Additional
buildroot to test x86-64 micro-architecture update|Change]] to enable
an additional buildroot. During development, its scope has expanded to
include the entire process of how the Fedora sources are built and
composed into shippable artifacts.
ELN is an evolution of the request for an alternate buildroot for
newer x86_64 processors. The reasoning behind that new buildroot was
that we expected that the next major release of RHEL would likely drop
support for older hardware and therefore could take advantage of
enhancements and processor extensions available for newer hardware. As
plans for this proceeded, they expanded into a desire to do more than
just test out the processor architecture. Instead, we want to have a
complete alternative compose of Fedora Rawhide that resembles the way
that Red Hat and CentOS builds their packages. The idea being that
Fedora developers and third-party vendors who rely on Red Hat
Enterprise Linux have a place where they can directly contribute to
what will eventually become the next RHEL.
ELN (Enterprise Linux Next) is going to be that place. What we want to
do is establish a set of RPM conditionals that can be used for the set
of packages that may need to be built differently for a RHEL-like
target as compared to a Fedora one. (For example, we may want to skip
regenerating documentation during package-build and instead use
pre-built docs from the tarball or SRPM.)
This includes:
* buildroot configuration, rpm macro and compile flags,
* comps files and the compose content,
* compose itself and the pipeline which builds it.
Under this umbrella we are going to have:
* RPM variables for conditionals to allow tweaking rpm spec files
* A new Koji tag which allows control of the buildroot,
* A fork of the pungi configuration which describes the compose configuration,
* A pipeline which builds a periodic compose based on that configuration,
* Storage for such composes and additional pipelines which will verify
the quality of the compose and test additional scenarios on top of it.
The RPM variables:
* `%{dist}` will return `.eln` (no numerical suffix)
* `%{fedora}` will return `.fcXX` (where XX is the Fedora version
represented by Rawhide).
* `%{rhel}` will be set and will return a number one higher than the
most recent major release of Red Hat Enterprise Linux (at present,
that will be `9`).
* `%{eln}` will be set and will expand to `%{rhel}`
The reasoning behind this approach is so that we break as little as
possible when we implement this new build and compose. Existing
packages that are using conditionals such as `if 0%{?rhel} > 7` will
transition over to building "like RHEL" automatically. Any packages
that do not have a shared Fedora/RHEL specfile will continue to build
as normal. Some unknown number of packages that rely on `if !
0%{?fedora}` will require manual intervention.
The `%{eln}` variable will be set primarily to allow for the
possibility of needing conditionals that apply to ELN only and should
not carry over to RHEL, but we expect its use to be exceptionally
rare.
== Benefit to Fedora ==
Who benefits from the implementation of this feature:
* Fedora Infrastructure
** As we are going to try and test new, more easily maintainable
infrastructure for composes.
* Fedora Minimization
** As we are going to modify the compose content according to
minimization goals and provide feedback to Fedora maintainers on the
results
* CentOS Stream, EPEL and RHEL
** We are going to build Fedora packages into a compose similar to the
multi-repo structure of CentOS and RHEL.
* Fedora Community
** The feedback pipelines built for the project will allow downstream
developers to open up their work and bring it closer to Fedora. In
particular, it will enable projects like OpenShift to do their work in
Fedora.
** Making Fedora friendlier to its downstream will justify bringing
more resources and more contributions to Fedora Rawhide. So that
downstream not only tries to catch up with Fedora going forward, but
actively participates in Fedora development and testing.
** The tooling developed for this project will allow further
development of changes in Fedora Infrastructure without blocking the
regular Fedora packaging and release process.
== Scope ==
* Proposal owners:
** Setup build environment for a new disttag (`eln`).
** Setup automation to trigger new ELN build every time there is a new
update submitted to Fedora Rawhide.
** Post build result to Fedora Messaging, so that it appears in Bodhi
and can be used as a
[https://docs.fedoraproject.org/en-US/rawhide-gating/ gating test].
** Setup automation to run periodic partial composes (via ODCS)
without installation media to generate repositories with these
packages.
** Update packaging documentation to mention new disttag and how it can be used.
* Other developers:
*: Anyone who wants to produce different content for the ELN compose
will need to implement the new macros in their specfile. The
overwhelming majority of packages will require no modification.
* Release engineering: [https://pagure.io/releng/issue/9154 #9154]
* Policies and guidelines:
[https://pagure.io/packaging-committee/issue/955 #955]
* Trademark approval: not needed. There is no new shippable artifact.
== Upgrade/compatibility impact ==
N/A
Though it is a System Wide change it doesn’t impact Fedora upgrades,
as it is a development environment tracking Fedora Rawhide.
== How To Test ==
There is going to be a development snapshot of the state of the ELN
repositories.
It is under discussion whether this snapshot will have its own
installation media. For now the preferred way to test ELN composes
would be to use standard Fedora Rawhide images and then include ELN as
an additional repository.
== User Experience ==
There is no user-facing part in this change. No ELN artifacts are
going to be shipped to the end-user.
== Dependencies ==
There is no dependency on other changes, though some of the
infrastructure services like ODCS composes and Fedora CI will be
involved.
== Contingency Plan ==
* 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 cancelled.
* Contingency deadline: N/A as it is a continuous process in Fedora
Rawhide and it is not pinned to a specific release.
* Blocks release? No
* Blocks product? No
Additional risk: Infrastructure resources taken by ELN builds can
create load on Fedora build system
Mitigation: In case of such load we cancel or reschedule ELN tasks
(package and compose builds and tests) on request from the Fedora
Infrastructure team. At least initially, we will also set ELN tasks to
low-priority, similar to how COPR does it.
== Documentation ==
https://fedoraproject.org/wiki/ELN
See also previous discussions:
* "Alternative buildroot as a development tool" @ devel
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
== Release Notes ==
N/A
Though it is a System-Wide Change it has no user-facing component. We
may announce it through other channels.
--
Aleksandra Fedorova
bookwar
5:14 a.m.
On Tue, Mar 24, 2020 at 5:33 AM Aleksandra Fedorova <alpha(a)bookwar.info> wrote:
The RPM variables:
* `%{fedora}` will return `.fcXX` (where XX is the Fedora version
represented by Rawhide).
This will break things. %fedora has always returned an integer, why do
you want to change it to return a "DistTag"-ish value?
--
真実はいつも一つ！/ Always, there's only one truth!
5:23 a.m.
On 24. 03. 20 11:14, Neal Gompa wrote:
On Tue, Mar 24, 2020 at 5:33 AM Aleksandra Fedorova
<alpha(a)bookwar.info> wrote:
>
> The RPM variables:
>
> * `%{fedora}` will return `.fcXX` (where XX is the Fedora version
> represented by Rawhide).
This will break things. %fedora has always returned an integer, why do
you want to change it to return a "DistTag"-ish value?
That is a mistake, see:
https://pagure.io/packaging-committee/issue/955#comment-636113
I'll update it on the wiki.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
5:43 a.m.
On 24/03/2020 09:32, Aleksandra Fedorova wrote:
ELN is an evolution of the request for an alternate buildroot for
newer x86_64 processors. The reasoning behind that new buildroot was
that we expected that the next major release of RHEL would likely drop
support for older hardware and therefore could take advantage of
enhancements and processor extensions available for newer hardware. As
plans for this proceeded, they expanded into a desire to do more than
just test out the processor architecture. Instead, we want to have a
complete alternative compose of Fedora Rawhide that resembles the way
that Red Hat and CentOS builds their packages. The idea being that
Fedora developers and third-party vendors who rely on Red Hat
Enterprise Linux have a place where they can directly contribute to
what will eventually become the next RHEL.
For those of us who know little about the details of RHEL and CentOS
can you elaborate on what is different in the way that they build their
packages compared to Fedora?
* Other developers:
*: Anyone who wants to produce different content for the ELN compose
will need to implement the new macros in their specfile. The
overwhelming majority of packages will require no modification.
What is the impact on "other developers" who don't want to do those
things? Is there an expectation that Fedora packagers will make any
necessary changes to ensure their packages build in this environment
and continue to respond to issues to keep them building there?
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
7:08 a.m.
Dne 24. 03. 20 v 11:43 Tom Hughes via devel napsal(a):
On 24/03/2020 09:32, Aleksandra Fedorova wrote:
> ELN is an evolution of the request for an alternate buildroot for
> newer x86_64 processors. The reasoning behind that new buildroot was
> that we expected that the next major release of RHEL would likely drop
> support for older hardware and therefore could take advantage of
> enhancements and processor extensions available for newer hardware. As
> plans for this proceeded, they expanded into a desire to do more than
> just test out the processor architecture. Instead, we want to have a
> complete alternative compose of Fedora Rawhide that resembles the way
> that Red Hat and CentOS builds their packages. The idea being that
> Fedora developers and third-party vendors who rely on Red Hat
> Enterprise Linux have a place where they can directly contribute to
> what will eventually become the next RHEL.
For those of us who know little about the details of RHEL and CentOS
can you elaborate on what is different in the way that they build their
packages compared to Fedora?
The attempt to explain this was in the following paragraph you have trimmed:
What we want to do is establish a set of RPM conditionals that can be
used for the set of packages that may need to be built differently for a
RHEL-like target as compared to a Fedora one. (For example, we may want
to skip regenerating documentation during package-build and instead use
pre-built docs from the tarball or SRPM.)
One of the main concerns are package dependencies, RHEL is lets say
~4000 SRPM. But if you just take the same RPMs from Fedora, it would
pull in additional dependencies.
So for RHEL, we typically trim dependencies such as bindings for various
languages, associated tests, test frameworks, documentation tools, etc.
> * Other developers:
> *: Anyone who wants to produce different content for the ELN compose
> will need to implement the new macros in their specfile. The
> overwhelming majority of packages will require no modification.
What is the impact on "other developers" who don't want to do those
things? Is there an expectation that Fedora packagers will make any
necessary changes to ensure their packages build in this environment
and continue to respond to issues to keep them building there?
I am not the change owner. However, I believe that there is not
definitive answer to this question and part of the challenge is to find
the answer.
Believe it or not, although I maintain packages in RHEL, I don't want to
see Fedora packages polluted with conditionals, so I hope there will be
some "overlay" git branch, allowing to `git rebase` packages from
Fedora. Others will be in favor of the conditionals. I don't see this
different then the current discussion if we should merge branches
between Fedora versions and keep conditionals for RHEL/EPEL or not.
Vít
Tom
7:13 a.m.
On 24/03/2020 12:08, Vít Ondruch wrote:
Dne 24. 03. 20 v 11:43 Tom Hughes via devel napsal(a):
> On 24/03/2020 09:32, Aleksandra Fedorova wrote:
>
>> ELN is an evolution of the request for an alternate buildroot for
>> newer x86_64 processors. The reasoning behind that new buildroot was
>> that we expected that the next major release of RHEL would likely drop
>> support for older hardware and therefore could take advantage of
>> enhancements and processor extensions available for newer hardware. As
>> plans for this proceeded, they expanded into a desire to do more than
>> just test out the processor architecture. Instead, we want to have a
>> complete alternative compose of Fedora Rawhide that resembles the way
>> that Red Hat and CentOS builds their packages. The idea being that
>> Fedora developers and third-party vendors who rely on Red Hat
>> Enterprise Linux have a place where they can directly contribute to
>> what will eventually become the next RHEL.
>
> For those of us who know little about the details of RHEL and CentOS
> can you elaborate on what is different in the way that they build their
> packages compared to Fedora?
The attempt to explain this was in the following paragraph you have trimmed:
Ah OK I think I misunderstood.
I thought the above was saying there were fundamental architectural
differences in the way the builds worked, rather than just that people
might choose to make different choices in the spec file.
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
7:25 a.m.
On Tue, Mar 24, 2020 at 12:13:57PM +0000, Tom Hughes via devel wrote:
I thought the above was saying there were fundamental architectural
differences in the way the builds worked, rather than just that people
might choose to make different choices in the spec file.
RHEL supports building non-modular RPM packages on top of modules. While
Fedora forbids it. Probably this is not a fundamental difference, but a big
one.
I believe the proposed change covers it in the pungi configuration.
-- Petr
9:55 p.m.
On Tuesday, March 24, 2020 5:25:30 AM MST Petr Pisar wrote:
On Tue, Mar 24, 2020 at 12:13:57PM +0000, Tom Hughes via devel
wrote:
> I thought the above was saying there were fundamental architectural
> differences in the way the builds worked, rather than just that people
> might choose to make different choices in the spec file.
RHEL supports building non-modular RPM packages on top of modules. While
Fedora forbids it. Probably this is not a fundamental difference, but a big
one.
I believe the proposed change covers it in the pungi configuration.
-- Petr
In that case, it looks like this change could potentially fix RHEL if it goes
through? Or are you saying it'd try to force that policy onto Fedora?
--
John M. Harris, Jr.
Splentity
3:06 a.m.
On Tue, Mar 24, 2020 at 07:55:12PM -0700, John M. Harris Jr wrote:
On Tuesday, March 24, 2020 5:25:30 AM MST Petr Pisar wrote:
> On Tue, Mar 24, 2020 at 12:13:57PM +0000, Tom Hughes via devel wrote:
> > I thought the above was saying there were fundamental architectural
> > differences in the way the builds worked, rather than just that people
> > might choose to make different choices in the spec file.
>
> RHEL supports building non-modular RPM packages on top of modules. While
> Fedora forbids it. Probably this is not a fundamental difference, but a big
> one.
>
> I believe the proposed change covers it in the pungi configuration.
>
> -- Petr
In that case, it looks like this change could potentially fix RHEL if it goes
through? Or are you saying it'd try to force that policy onto Fedora?
I'm saying that the change descibes that ELN will have a separate pungi and
tagging configurations. And because tagging default module streams into a build
root is based on them, it can allow having default streams in ELN without
forcing that policy onto Fedora. Whether it will be so or not is up to the
implementation the change owners will choose. So far we heard that the
implementation is unclear.
-- Petr
5:22 a.m.
On Wed, Mar 25, 2020 at 09:06:06AM +0100, Petr Pisar wrote:
On Tue, Mar 24, 2020 at 07:55:12PM -0700, John M. Harris Jr wrote:
> On Tuesday, March 24, 2020 5:25:30 AM MST Petr Pisar wrote:
> > On Tue, Mar 24, 2020 at 12:13:57PM +0000, Tom Hughes via devel wrote:
> > > I thought the above was saying there were fundamental architectural
> > > differences in the way the builds worked, rather than just that people
> > > might choose to make different choices in the spec file.
> >
> > RHEL supports building non-modular RPM packages on top of modules. While
> > Fedora forbids it. Probably this is not a fundamental difference, but a big
> > one.
> >
> > I believe the proposed change covers it in the pungi configuration.
> >
> > -- Petr
>
> In that case, it looks like this change could potentially fix RHEL if it goes
> through? Or are you saying it'd try to force that policy onto Fedora?
>
I'm saying that the change descibes that ELN will have a separate pungi and
tagging configurations. And because tagging default module streams into a build
root is based on them, it can allow having default streams in ELN without
forcing that policy onto Fedora. Whether it will be so or not is up to the
implementation the change owners will choose. So far we heard that the
implementation is unclear.
It sounds like tagging default module streams into the build root
would be _technically_ possible. But OTOH, I understood that the
intent is to rebuild packages from rawhide on the fly, and having
module streams in the build root would cause noticeable changes in
the availability and versions of build dependencies, and would
make following rawhide with automatic rebuilds much harder.
I'm just speculating of course, a clarification from the Change
owners would be welcome.
Zbyszek
9:16 a.m.
On 24. 03. 20 10:32, Aleksandra Fedorova wrote:
As Ben is on PTO, I'd like to present the System-Wide Change
https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
== Summary ==
The goal of the ELN project is to continuously build Fedora Rawhide
packages and composes in the way which resembles the CentOS and RHEL
build process and to provide a feedback loop for Fedora maintainers on
the status of those builds.
Form a Fedora POV, this doesn't state what's being "changed" at all.
I would appreciate if it actually said something about the ELN Buildroot and
Compose.
ELN is an evolution of the request for an alternate buildroot for
newer x86_64 processors. The reasoning behind that new buildroot was
that we expected that the next major release of RHEL would likely drop
support for older hardware and therefore could take advantage of
enhancements and processor extensions available for newer hardware. As
plans for this proceeded, they expanded into a desire to do more than
just test out the processor architecture. Instead, we want to have a
complete alternative compose of Fedora Rawhide that resembles the way
that Red Hat and CentOS builds their packages. The idea being that
Fedora developers and third-party vendors who rely on Red Hat
Enterprise Linux have a place where they can directly contribute to
what will eventually become the next RHEL.
I don't understand from the rest of the change how do they contribute to ELN.
ELN (Enterprise Linux Next) is going to be that place. What we want
to
do is establish a set of RPM conditionals that can be used for the set
of packages that may need to be built differently for a RHEL-like
target as compared to a Fedora one. (For example, we may want to skip
regenerating documentation during package-build and instead use
pre-built docs from the tarball or SRPM.)
What set of RPM conditionals? This is more clear from the FPC ticket:
https://pagure.io/packaging-committee/issue/955
But even there, it seem that any new conditionals will be discouraged, so what
are the new conditionals this change is talking about?
This includes:
* buildroot configuration, rpm macro and compile flags,
* comps files and the compose content,
* compose itself and the pipeline which builds it.
Where are those rpm macros and compile flags be defined if this builds from
master? Will there be an alternative branch for (and only for)
redhat-rpm-config, or will redhat-rpm-config be full of such new conditionals?
Are the maintainers of redhat-rpm-config on board?
... Some unknown number of packages that rely on `if !
0%{?fedora}` will require manual intervention.
And many other cases, see the FPC ticket.
* CentOS Stream, EPEL and RHEL
** We are going to build Fedora packages into a compose similar to the
multi-repo structure of CentOS and RHEL.
This lacks any details in the description.
** The feedback pipelines built for the project will allow
downstream
developers to open up their work and bring it closer to Fedora. In
particular, it will enable projects like OpenShift to do their work in
Fedora.
I don't understand how. Do you have more details?
== Scope ==
* Proposal owners:
** Setup build environment for a new disttag (`eln`).
** Setup automation to trigger new ELN build every time there is a new
update submitted to Fedora Rawhide.
** Post build result to Fedora Messaging, so that it appears in Bodhi
and can be used as a
[https://docs.fedoraproject.org/en-US/rawhide-gating/ gating test].
** Setup automation to run periodic partial composes (via ODCS)
without installation media to generate repositories with these
packages.
** Update packaging documentation to mention new disttag and how it can be used.
* Other developers:
*: Anyone who wants to produce different content for the ELN compose
will need to implement the new macros in their specfile. The
overwhelming majority of packages will require no modification.
I don't understand the meaning of "implement the new macros". Do I read it
that
if I want to produce different content for the ELN compose, I need to use %if
conditionals for %{rhel}? What if I don't want such conditionals, because I
prefer to have separate branches?
I also don't understand how this will work if only the packager who want this
will participate. Assume you need to build your package "like in the next RHEL",
so you adapt it (let's say you disable the "shakehands" feature, because you
don't plan to include "libshakehands" in future RHEL). As a consequence,
packages depending on your package and might also need adapting (becasue they
assume the shakehands feature is available by default). What if the maintainer
of a dependnign package doesn't like %{rhel} conditionals in their specs? Will
the changes be forced? Or will parts of the ELN compose fail to build or install
forever because of this?
== User Experience ==
There is no user-facing part in this change. No ELN artifacts are
going to be shipped to the end-user.
As a packager debugging a problem in ELN, how do I consume it?
-----------
General questions/feedback follows:
The description of this change is very vague. I don't know if it is intended or
not, but it is very unclear to me, how will this new buildroot work. For example:
Will there be any inheritance from rawhide? After the FESCo meeting I assume
yes, but would like a record of this on the mailing list.
How do we bootstrap things in ELN without disturbing regular rawhide? For
example, assume the following situation:
There is libchicken-1 and libegg-1 in rawhide as well as ELN. They require and
buildrequire each other. The maintainer needs to do an update. He does the
following in Fedora:
- request a side tag
- builds libchicken-2 with bundled egg-2
- builds egg-2
- rebuilds libchicken-2 against the egg-2 package
- request a side tag merge
What happens in ELN? Will all side tags automatically create a bound ELN side
tag? Or after the side tag is merged, libchicken and libegg will be untagged
form ELN and rebuild against the rawhide versions?
What happens upon ELN build failures? Assume the omelette package fails to build
in ELN because the chicken and egg problem. Who will chase this and how? Will
the omelette maintainer receive an automatic bug report to fix their package or
will an ELN developer fix this for them? Where do they commit their fixes, if
everything builds from master?
Will there be a way to opt-out packages (or stacks of them) from ELN if they are
not interesting for RHEL?
I could go on with further scenarios and what-ifs. I undrstand if the answer is
"we don't know yet". But the Change proposal should at least try to explain
how
this buildroot works.
An extra question: How does this play with modularity, if at all. Do we also
rebuild all modules?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
10:23 a.m.
On Tue, Mar 24, 2020 at 3:17 PM Miro Hrončok <mhroncok(a)redhat.com> wrote:
On 24. 03. 20 10:32, Aleksandra Fedorova wrote:
> As Ben is on PTO, I'd like to present the System-Wide Change
>
> https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
>
> == Summary ==
>
> The goal of the ELN project is to continuously build Fedora Rawhide
> packages and composes in the way which resembles the CentOS and RHEL
> build process and to provide a feedback loop for Fedora maintainers on
> the status of those builds.
Form a Fedora POV, this doesn't state what's being "changed" at all.
I would appreciate if it actually said something about the ELN Buildroot and
Compose.
> ELN is an evolution of the request for an alternate buildroot for
> newer x86_64 processors. The reasoning behind that new buildroot was
> that we expected that the next major release of RHEL would likely drop
> support for older hardware and therefore could take advantage of
> enhancements and processor extensions available for newer hardware. As
> plans for this proceeded, they expanded into a desire to do more than
> just test out the processor architecture. Instead, we want to have a
> complete alternative compose of Fedora Rawhide that resembles the way
> that Red Hat and CentOS builds their packages. The idea being that
> Fedora developers and third-party vendors who rely on Red Hat
> Enterprise Linux have a place where they can directly contribute to
> what will eventually become the next RHEL.
I don't understand from the rest of the change how do they contribute to ELN.
> ELN (Enterprise Linux Next) is going to be that place. What we want to
> do is establish a set of RPM conditionals that can be used for the set
> of packages that may need to be built differently for a RHEL-like
> target as compared to a Fedora one. (For example, we may want to skip
> regenerating documentation during package-build and instead use
> pre-built docs from the tarball or SRPM.)
What set of RPM conditionals? This is more clear from the FPC ticket:
https://pagure.io/packaging-committee/issue/955
But even there, it seem that any new conditionals will be discouraged, so what
are the new conditionals this change is talking about?
> This includes:
>
> * buildroot configuration, rpm macro and compile flags,
> * comps files and the compose content,
> * compose itself and the pipeline which builds it.
Where are those rpm macros and compile flags be defined if this builds from
master? Will there be an alternative branch for (and only for)
redhat-rpm-config, or will redhat-rpm-config be full of such new conditionals?
Are the maintainers of redhat-rpm-config on board?
> ... Some unknown number of packages that rely on `if !
> 0%{?fedora}` will require manual intervention.
And many other cases, see the FPC ticket.
> * CentOS Stream, EPEL and RHEL
> ** We are going to build Fedora packages into a compose similar to the
> multi-repo structure of CentOS and RHEL.
This lacks any details in the description.
> ** The feedback pipelines built for the project will allow downstream
> developers to open up their work and bring it closer to Fedora. In
> particular, it will enable projects like OpenShift to do their work in
> Fedora.
I don't understand how. Do you have more details?
> == Scope ==
> * Proposal owners:
> ** Setup build environment for a new disttag (`eln`).
> ** Setup automation to trigger new ELN build every time there is a new
> update submitted to Fedora Rawhide.
> ** Post build result to Fedora Messaging, so that it appears in Bodhi
> and can be used as a
> [https://docs.fedoraproject.org/en-US/rawhide-gating/ gating test].
> ** Setup automation to run periodic partial composes (via ODCS)
> without installation media to generate repositories with these
> packages.
> ** Update packaging documentation to mention new disttag and how it can be used.
>
> * Other developers:
> *: Anyone who wants to produce different content for the ELN compose
> will need to implement the new macros in their specfile. The
> overwhelming majority of packages will require no modification.
I don't understand the meaning of "implement the new macros". Do I read it
that
if I want to produce different content for the ELN compose, I need to use %if
conditionals for %{rhel}? What if I don't want such conditionals, because I
prefer to have separate branches?
I also don't understand how this will work if only the packager who want this
will participate. Assume you need to build your package "like in the next
RHEL",
so you adapt it (let's say you disable the "shakehands" feature, because
you
don't plan to include "libshakehands" in future RHEL). As a consequence,
packages depending on your package and might also need adapting (becasue they
assume the shakehands feature is available by default). What if the maintainer
of a dependnign package doesn't like %{rhel} conditionals in their specs? Will
the changes be forced? Or will parts of the ELN compose fail to build or install
forever because of this?
> == User Experience ==
>
> There is no user-facing part in this change. No ELN artifacts are
> going to be shipped to the end-user.
As a packager debugging a problem in ELN, how do I consume it?
-----------
General questions/feedback follows:
The description of this change is very vague. I don't know if it is intended or
not, but it is very unclear to me, how will this new buildroot work. For example:
Will there be any inheritance from rawhide? After the FESCo meeting I assume
yes, but would like a record of this on the mailing list.
How do we bootstrap things in ELN without disturbing regular rawhide? For
example, assume the following situation:
There is libchicken-1 and libegg-1 in rawhide as well as ELN. They require and
buildrequire each other. The maintainer needs to do an update. He does the
following in Fedora:
- request a side tag
- builds libchicken-2 with bundled egg-2
- builds egg-2
- rebuilds libchicken-2 against the egg-2 package
- request a side tag merge
What happens in ELN? Will all side tags automatically create a bound ELN side
tag? Or after the side tag is merged, libchicken and libegg will be untagged
form ELN and rebuild against the rawhide versions?
What happens upon ELN build failures? Assume the omelette package fails to build
in ELN because the chicken and egg problem. Who will chase this and how? Will
the omelette maintainer receive an automatic bug report to fix their package or
will an ELN developer fix this for them? Where do they commit their fixes, if
everything builds from master?
Will there be a way to opt-out packages (or stacks of them) from ELN if they are
not interesting for RHEL?
I could go on with further scenarios and what-ifs. I undrstand if the answer is
"we don't know yet". But the Change proposal should at least try to explain
how
this buildroot works.
I am going to answer generally in this mail, before we dive in into
discussing the details.
I think your approach to assessment of the Change is not fair.
It is an infrastructure change, not a code one. Figuring out all of
the questions you are asking is exactly what this change is about. And
you are requesting that we put the entire solution into the change
proposal. This is not going to work this way. And it shouldn't work
this way.
There is a reason why Change Template has Description section and does
not have Design or Implementation. Because design and implementation
are left for the owners of the change as we will figure out the
details on our way to it.
The goal of the Change process is to assess the idea, the impact, to
check whether there is a disruption this change brings, and to find
people who are interested in it. Then we can work on the change
together, working through all those questions you have mentioned.
You are asking good questions and I value your feedback. But yes, the
current answer to most of them is "we do not know yet".
For example, even though the structure of the buildroot is proposed in
the releng ticket, and we would like it to inherit rawhide buildroot
at this point, we may want to change it later.
So I'd ask you to split the conversation into two parts:
1) what are the expectation, requirements, impact and risk for this Change
This is what we do need to add into the Change proposal, as it sets
the boundaries in which we should operate.
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.
An extra question: How does this play with modularity, if at all. Do we also
rebuild all modules?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
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@lists.fedoraproject.org
--
Aleksandra Fedorova
bookwar
11:59 a.m.
On 24. 03. 20 16:23, Aleksandra Fedorova wrote:
I am going to answer generally in this mail, before we dive in into
discussing the details.
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.
It is an infrastructure change, not a code one. Figuring out all of
the questions you are asking is exactly what this change is about. And
you are requesting that we put the entire solution into the change
proposal. This is not going to work this way. And it shouldn't work
this way.
The way I see it, it, the change proposal currently describes an "idea".
I would like it to describe how things are planned to work (at least an initial
plan for that).
There is a reason why Change Template has Description section and
does
not have Design or Implementation. Because design and implementation
are left for the owners of the change as we will figure out the
details on our way to it.
The goal of the Change process is to assess the idea, the impact, to
check whether there is a disruption this change brings, and to find
people who are interested in it. Then we can work on the change
together, working through all those questions you have mentioned.
I wasn't aware that this is the change process goal. Most of the (approved)
changes in Fedora actually describe what's going to happen. Changes that only
describe the end goal are often rejected or significantly amended.
"Change proposals should be shared as early as possible, before the change is
implemented and even in the very early state of the idea, to gather community
feedback and review."
https://docs.fedoraproject.org/en-US/program_management/changes_policy/
This exactly happened here and I am glad it did. But in my opinion, outright
rejecting the feedback is not fair either.
You are asking good questions and I value your feedback. But yes,
the
current answer to most of them is "we do not know yet".
For example, even though the structure of the buildroot is proposed in
the releng ticket, and we would like it to inherit rawhide buildroot
at this point, we may want to change it later.
So I'd ask you to split the conversation into two parts:
1) what are the expectation, requirements, impact and risk for this Change
This is what we do need to add into the Change proposal, as it sets
the boundaries in which we should operate.
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.
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).
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 think it would be unfair if this Change in fact has a large impact to average
contributors, but we only realize this once they are impacted (and discontented).
So, forgive me for being unfair, but I'd rather be unfair to a Change proposal,
than being unfair to our contributors.
I realize some will consider this "stop energy", but I'm not trying to stop
or
fight ELN (in fact, I am quite exited about it) -- I just ask for more
information before we can assess it.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1:55 p.m.
On Tue, Mar 24, 2020 at 6:01 PM Miro Hrončok <mhroncok(a)redhat.com> wrote:
On 24. 03. 20 16:23, Aleksandra Fedorova wrote:
> I am going to answer generally in this mail, before we dive in into
> discussing the details.
>
> 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.
> It is an infrastructure change, not a code one. Figuring out all
of
> the questions you are asking is exactly what this change is about. And
> you are requesting that we put the entire solution into the change
> proposal. This is not going to work this way. And it shouldn't work
> this way.
The way I see it, it, the change proposal currently describes an "idea".
I would like it to describe how things are planned to work (at least an initial
plan for that).
> There is a reason why Change Template has Description section and does
> not have Design or Implementation. Because design and implementation
> are left for the owners of the change as we will figure out the
> details on our way to it.
>
> The goal of the Change process is to assess the idea, the impact, to
> check whether there is a disruption this change brings, and to find
> people who are interested in it. Then we can work on the change
> together, working through all those questions you have mentioned.
I wasn't aware that this is the change process goal. Most of the (approved)
changes in Fedora actually describe what's going to happen. Changes that only
describe the end goal are often rejected or significantly amended.
"Change proposals should be shared as early as possible, before the change is
implemented and even in the very early state of the idea, to gather community
feedback and review."
https://docs.fedoraproject.org/en-US/program_management/changes_policy/
This exactly happened here and I am glad it did. But in my opinion, outright
rejecting the feedback is not fair either.
> You are asking good questions and I value your feedback. But yes, the
> current answer to most of them is "we do not know yet".
> For example, even though the structure of the buildroot is proposed in
> the releng ticket, and we would like it to inherit rawhide buildroot
> at this point, we may want to change it later.
>
> So I'd ask you to split the conversation into two parts:
>
> 1) what are the expectation, requirements, impact and risk for this Change
> This is what we do need to add into the Change proposal, as it sets
> the boundaries in which we should operate.
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?
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.
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.
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.
> 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.
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".
I think it would be unfair if this Change in fact has a large impact to average
contributors, but we only realize this once they are impacted (and discontented).
So, forgive me for being unfair, but I'd rather be unfair to a Change proposal,
than being unfair to our contributors.
I realize some will consider this "stop energy", but I'm not trying to stop
or
fight ELN (in fact, I am quite exited about it) -- I just ask for more
information before we can assess it.
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.
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?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
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@lists.fedoraproject.org
[1] https://pagure.io/releng/issue/9154
--
Aleksandra Fedorova
bookwar
4:26 a.m.
Dne 24. 03. 20 v 19:55 Aleksandra Fedorova napsal(a):
On Tue, Mar 24, 2020 at 6:01 PM Miro Hrončok
<mhroncok(a)redhat.com> wrote:
> On 24. 03. 20 16:23, Aleksandra Fedorova wrote:
>> I am going to answer generally in this mail, before we dive in into
>> discussing the details.
>>
>> 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.
>> It is an infrastructure change, not a code one. Figuring out all of
>> the questions you are asking is exactly what this change is about. And
>> you are requesting that we put the entire solution into the change
>> proposal. This is not going to work this way. And it shouldn't work
>> this way.
> The way I see it, it, the change proposal currently describes an "idea".
> I would like it to describe how things are planned to work (at least an initial
> plan for that).
>
>> There is a reason why Change Template has Description section and does
>> not have Design or Implementation. Because design and implementation
>> are left for the owners of the change as we will figure out the
>> details on our way to it.
>>
>> The goal of the Change process is to assess the idea, the impact, to
>> check whether there is a disruption this change brings, and to find
>> people who are interested in it. Then we can work on the change
>> together, working through all those questions you have mentioned.
> I wasn't aware that this is the change process goal. Most of the (approved)
> changes in Fedora actually describe what's going to happen. Changes that only
> describe the end goal are often rejected or significantly amended.
>
> "Change proposals should be shared as early as possible, before the change is
> implemented and even in the very early state of the idea, to gather community
> feedback and review."
>
> https://docs.fedoraproject.org/en-US/program_management/changes_policy/
>
> This exactly happened here and I am glad it did. But in my opinion, outright
> rejecting the feedback is not fair either.
>
>> You are asking good questions and I value your feedback. But yes, the
>> current answer to most of them is "we do not know yet".
>> For example, even though the structure of the buildroot is proposed in
>> the releng ticket, and we would like it to inherit rawhide buildroot
>> at this point, we may want to change it later.
>>
>> So I'd ask you to split the conversation into two parts:
>>
>> 1) what are the expectation, requirements, impact and risk for this Change
>> This is what we do need to add into the Change proposal, as it sets
>> the boundaries in which we should operate.
> 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?
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.
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.
> 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.
I think that the level of involvement of the other maintainers is the
same as what we always did for RHEL. Did RHEL maintainers bothered some
Fedora maintainers with some conditionals and what not? Probably. I
don't see that should be different. The only difference probably is that
that won't be one time effort once in every 3 years, but the flow of
requests will be continuous, but hopefully smaller.
Actually, this brings interesting question. It seems to me, that it
would be helpful if RHEL maintainers had blank approval to access the
ELN packages.
Vít
>> 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.
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".
> I think it would be unfair if this Change in fact has a large impact to average
> contributors, but we only realize this once they are impacted (and discontented).
>
> So, forgive me for being unfair, but I'd rather be unfair to a Change proposal,
> than being unfair to our contributors.
>
> I realize some will consider this "stop energy", but I'm not trying to
stop or
> fight ELN (in fact, I am quite exited about it) -- I just ask for more
> information before we can assess it.
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.
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?
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> 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@lists.fedoraproject.org
[1] https://pagure.io/releng/issue/9154
5:23 a.m.
On 25. 03. 20 10:26, Vít Ondruch wrote:
I think that the level of involvement of the other maintainers is
the
same as what we always did for RHEL. Did RHEL maintainers bothered some
Fedora maintainers with some conditionals and what not? Probably. I
don't see that should be different. The only difference probably is that
that won't be one time effort once in every 3 years, but the flow of
requests will be continuous, but hopefully smaller.
Well, not exactly. The RHEL maintainer can try to "bother" the Fedora maintainer
with rhel conditionals and when that Fedora maintainer says no, the RHEL
maintainer adjust the spec in RHEL only. In many cases that can even be the same
person. Assume I want to do something differently in RHEL and Fedora -- I just
push the change in RHEL.
While there is no way to adjust a spec in ELN only (if I understand the plan
correctly). Assume I want to do something differently in ELN and Fedora -- I
need to use the conditionals.
Actually, this brings interesting question. It seems to me, that it
would be helpful if RHEL maintainers had blank approval to access the
ELN packages.
What are ELN packages? From the proposal, it seems it is all Fedora packages. Or
did I get that wrong? Do you propose that RHEL maintainers are automatically
provenpackagers (I don't think you do, but I am not sure)?
In the ideal world, the RHEL maintainer of "foo" should be at least a
comaintainer of "foo" in Fedora, not somebody with "blank approval to
access".
It is sad that in some cases, the RHEL maintainers are not involved in the
corresponding Fedora packages until RHEL N+1 is in progress where they'd just
like to dump changes and leave for another few years.
But even if the RHEL maintainer is an active and/or primary maintainer of the
Fedora package, they don't necessarily want to push %if 0%{?rhel} conditionals
to rawhide just to support ELN. What shall they do?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
10:19 a.m.
Dne 25. 03. 20 v 11:23 Miro Hrončok napsal(a):
On 25. 03. 20 10:26, Vít Ondruch wrote:
> I think that the level of involvement of the other maintainers is the
> same as what we always did for RHEL. Did RHEL maintainers bothered some
> Fedora maintainers with some conditionals and what not? Probably. I
> don't see that should be different. The only difference probably is that
> that won't be one time effort once in every 3 years, but the flow of
> requests will be continuous, but hopefully smaller.
Well, not exactly. The RHEL maintainer can try to "bother" the Fedora
maintainer with rhel conditionals and when that Fedora maintainer says
no, the RHEL maintainer adjust the spec in RHEL only. In many cases
that can even be the same person. Assume I want to do something
differently in RHEL and Fedora -- I just push the change in RHEL.
While there is no way to adjust a spec in ELN only (if I understand
the plan correctly). Assume I want to do something differently in ELN
and Fedora -- I need to use the conditionals.
> Actually, this brings interesting question. It seems to me, that it
> would be helpful if RHEL maintainers had blank approval to access the
> ELN packages.
What are ELN packages? From the proposal, it seems it is all Fedora
packages. Or did I get that wrong? Do you propose that RHEL
maintainers are automatically provenpackagers (I don't think you do,
but I am not sure)?
I assume that there will be "ELN" branch, the same way we have fxx or
epel branches. Is my assumption wrong? Dunno.
In the ideal world, the RHEL maintainer of "foo" should be at least a
comaintainer of "foo" in Fedora, not somebody with "blank approval to
access". It is sad that in some cases, the RHEL maintainers are not
involved in the corresponding Fedora packages until RHEL N+1 is in
progress where they'd just like to dump changes and leave for another
few years.
But even if the RHEL maintainer is an active and/or primary maintainer
of the Fedora package, they don't necessarily want to push %if
0%{?rhel} conditionals to rawhide just to support ELN. What shall they
do?
Yes, right, I am in that boat as I sad on different place :) and again,
since this is not explicitly mentioned in the proposal, I assume that is
is something to consider.
Vít
10:24 a.m.
Dne 25. 03. 20 v 16:19 Vít Ondruch napsal(a):
Dne 25. 03. 20 v 11:23 Miro Hrončok napsal(a):
> On 25. 03. 20 10:26, Vít Ondruch wrote:
>> I think that the level of involvement of the other maintainers is the
>> same as what we always did for RHEL. Did RHEL maintainers bothered some
>> Fedora maintainers with some conditionals and what not? Probably. I
>> don't see that should be different. The only difference probably is that
>> that won't be one time effort once in every 3 years, but the flow of
>> requests will be continuous, but hopefully smaller.
> Well, not exactly. The RHEL maintainer can try to "bother" the Fedora
> maintainer with rhel conditionals and when that Fedora maintainer says
> no, the RHEL maintainer adjust the spec in RHEL only. In many cases
> that can even be the same person. Assume I want to do something
> differently in RHEL and Fedora -- I just push the change in RHEL.
>
> While there is no way to adjust a spec in ELN only (if I understand
> the plan correctly). Assume I want to do something differently in ELN
> and Fedora -- I need to use the conditionals.
>
>> Actually, this brings interesting question. It seems to me, that it
>> would be helpful if RHEL maintainers had blank approval to access the
>> ELN packages.
> What are ELN packages? From the proposal, it seems it is all Fedora
> packages. Or did I get that wrong? Do you propose that RHEL
> maintainers are automatically provenpackagers (I don't think you do,
> but I am not sure)?
I assume that there will be "ELN" branch, the same way we have fxx or
epel branches. Is my assumption wrong? Dunno.
Reading other parts of the thread, it seems I was wrong :( The branching
is not considered ATM, but I still think that is mistake.
Vít
>
> In the ideal world, the RHEL maintainer of "foo" should be at least a
> comaintainer of "foo" in Fedora, not somebody with "blank approval to
> access". It is sad that in some cases, the RHEL maintainers are not
> involved in the corresponding Fedora packages until RHEL N+1 is in
> progress where they'd just like to dump changes and leave for another
> few years.
>
> But even if the RHEL maintainer is an active and/or primary maintainer
> of the Fedora package, they don't necessarily want to push %if
> 0%{?rhel} conditionals to rawhide just to support ELN. What shall they
> do?
>
Yes, right, I am in that boat as I sad on different place :) and again,
since this is not explicitly mentioned in the proposal, I assume that is
is something to consider.
Vít
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
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@lists.fedoraproject.org
5:46 a.m.
On 24. 03. 20 19:55, Aleksandra Fedorova wrote:
On Tue, Mar 24, 2020 at 6:01 PM Miro Hrončok
<mhroncok(a)redhat.com> 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
6:37 a.m.
On Wed, Mar 25, 2020 at 11:47 AM Miro Hrončok <mhroncok(a)redhat.com> wrote:
On 24. 03. 20 19:55, Aleksandra Fedorova wrote:
> On Tue, Mar 24, 2020 at 6:01 PM Miro Hrončok <mhroncok(a)redhat.com> 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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> 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@lists.fedoraproject.org
6:47 a.m.
On 25. 03. 20 12:37, Fabio Valentini wrote:
> 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.
Yes, that makes sense to me. Especially with automation (bacause without it, the
branch would simply get stalled, you cannot rebase all Fedora packages manually
at this scale).
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
7:09 a.m.
On Wed, Mar 25, 2020 at 12:48 PM Miro Hrončok <mhroncok(a)redhat.com> wrote:
On 25. 03. 20 12:37, Fabio Valentini wrote:
>> 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.
Yes, that makes sense to me. Especially with automation (bacause without it, the
branch would simply get stalled, you cannot rebase all Fedora packages manually
at this scale).
As I mentioned in the previous mail, branching goes against the
purpose of the effort.
What we like to achieve is to create a continuous flow from Fedora
Rawhide through branched Fedora all the way to downstream, which is
sometimes CentOS and sometimes EPEL.
Doing this with branches is going to be much harder. When you update
package with conditionals you do need to care about the effect on
various ifs, but you do need to change the package only once at one
place. And then the tree of branches which we create from Fedora
Rawhide will get this change automatically with no effort.
Of course not ifs are equal. It may require some refactoring on the
code side to make the ifs cleaner. I know kernel people did that with
a kernel package to reorganize patches which are applied.
But this is exactly the work we are looking for: the negotiation
between downstream maintainers and Fedora maintainers to make things
work together. We already have branching, it is easier as it allow us
not to talk to each other, but it doesn't solve anything.
And yes, it means that people are going to be _bothered_, and
_pressured_ on figuring out the best way to collaborate. But isn't it
our job?
And again, if you make it easier for downstream to work with Fedora,
you give downstream the reasons to bring their resources. Things like
quality assurance and help with bug triage and bug fixes, things like
cross-project feature development. This is a two-way collaboration
effort.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
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@lists.fedoraproject.org
--
Aleksandra Fedorova
bookwar
8:13 a.m.
Le mercredi 25 mars 2020 à 13:09 +0100, Aleksandra Fedorova a écrit :
On Wed, Mar 25, 2020 at 12:48 PM Miro Hrončok
<mhroncok(a)redhat.com>
wrote:
As I mentioned in the previous mail, branching goes against the
purpose of the effort.
What we like to achieve is to create a continuous flow from Fedora
Rawhide through branched Fedora all the way to downstream, which is
sometimes CentOS and sometimes EPEL.
Then please work with @rh engineering to get an up-to-date packaging
stack in EL (that means, latest stable Fedora rpm and latest stable
Fedora packaging macros, and all the other things that make packager
work less a shore).
A huge amount of EL ifdefs is directly caused by the staleness of the
packaging stack in EL. That’s why so much Fedora stuff never makes it
in EPEL. Most people Fedora side do not want to deal with the utter
clustefuck of trying to push complex up to date software to EL using
inadequate obsolete tooling.
No amount of clever ifdefing is going to mitigate this tooling
staleness. No amount of poking is going to convince people that *do*
*not* *want* *to* *deal* *with* *el* *braindamage* to accept
braindamage side-effects in their own Fedora specs. That’s trying to
put lipstick on a pig.
We’ve been saying that to @rh representatives for years now. rpm and
its ajuncts is the heart of community packaging. Packaging is done by
packagers. Packaging is not done by people that loath packaging (and
are continuously surprised their own packaging tools for people not
interested in packaging do not see mass packager adoption).
rpm state in EL prevents most downstreaming. Please focus efforts
there.
I don’t see how you will get any community adhesion in fixing
downstream problems, if all your solutions are downstream focused,
without caring about the people you want to enroll.
Regards,
--
Nicolas Mailhot
9:19 a.m.
On Wed, Mar 25, 2020 at 6:15 AM Nicolas Mailhot via devel
<devel(a)lists.fedoraproject.org> wrote:
Le mercredi 25 mars 2020 à 13:09 +0100, Aleksandra Fedorova a écrit :
> On Wed, Mar 25, 2020 at 12:48 PM Miro Hrončok <mhroncok(a)redhat.com>
> wrote:
> As I mentioned in the previous mail, branching goes against the
> purpose of the effort.
>
> What we like to achieve is to create a continuous flow from Fedora
> Rawhide through branched Fedora all the way to downstream, which is
> sometimes CentOS and sometimes EPEL.
Then please work with @rh engineering to get an up-to-date packaging
stack in EL (that means, latest stable Fedora rpm and latest stable
Fedora packaging macros, and all the other things that make packager
work less a shore).
A huge amount of EL ifdefs is directly caused by the staleness of the
packaging stack in EL. That’s why so much Fedora stuff never makes it
in EPEL. Most people Fedora side do not want to deal with the utter
clustefuck of trying to push complex up to date software to EL using
inadequate obsolete tooling.
No amount of clever ifdefing is going to mitigate this tooling
staleness. No amount of poking is going to convince people that *do*
*not* *want* *to* *deal* *with* *el* *braindamage* to accept
braindamage side-effects in their own Fedora specs. That’s trying to
put lipstick on a pig.
We’ve been saying that to @rh representatives for years now. rpm and
its ajuncts is the heart of community packaging. Packaging is done by
packagers. Packaging is not done by people that loath packaging (and
are continuously surprised their own packaging tools for people not
interested in packaging do not see mass packager adoption).
rpm state in EL prevents most downstreaming. Please focus efforts
there.
I don’t see how you will get any community adhesion in fixing
downstream problems, if all your solutions are downstream focused,
without caring about the people you want to enroll.
RHELN (currently RHEL9) is supposed to look like rawhide up to
whatever the cutover point is. So, up until that point, you shouldn't
be putting RHEL conditionals in, unless you do so for EPEL packages.
There are exceptions to this, such as the kernel, glibc, firefox, and
a handful of others. But those are the exceptions.
After the cutover date, then again, RHELN (in the next case it will be
RHEL10) should be looking like whatever is in rawhide, so you still
shouldn't need RHEL conditionals in, unless you do so for EPEL package
builds.
This ELN proposal has nothing to do with older RHEL releases or EPEL.
Troy
10:29 a.m.
Le mercredi 25 mars 2020 à 07:19 -0700, Troy Dawson a écrit :
On Wed, Mar 25, 2020 at 6:15 AM Nicolas Mailhot via devel
<devel(a)lists.fedoraproject.org> wrote:
>
> rpm state in EL prevents most downstreaming. Please focus efforts
> there.
>
> I don’t see how you will get any community adhesion in fixing
> downstream problems, if all your solutions are downstream focused,
> without caring about the people you want to enroll.
>
RHELN (currently RHEL9) is supposed to look like rawhide up to
whatever the cutover point is. So, up until that point, you shouldn't
be putting RHEL conditionals in, unless you do so for EPEL packages.
There are exceptions to this, such as the kernel, glibc, firefox, and
a handful of others. But those are the exceptions.
After the cutover date, then again, RHELN (in the next case it will
be RHEL10) should be looking like whatever is in rawhide,
That would basically mean that ELN is a rh-only thing, since the result
does not get exposed to others before cutover. Do I understand things
correctly?
If that is true, why would any non-rh Fedora packager care about the
complexity that comes with ELN?
--
Nicolas Mailhot
10:46 a.m.
Dne 25. 03. 20 v 15:19 Troy Dawson napsal(a):
On Wed, Mar 25, 2020 at 6:15 AM Nicolas Mailhot via devel
<devel(a)lists.fedoraproject.org> wrote:
> Le mercredi 25 mars 2020 à 13:09 +0100, Aleksandra Fedorova a écrit :
>> On Wed, Mar 25, 2020 at 12:48 PM Miro Hrončok <mhroncok(a)redhat.com>
>> wrote:
>> As I mentioned in the previous mail, branching goes against the
>> purpose of the effort.
>>
>> What we like to achieve is to create a continuous flow from Fedora
>> Rawhide through branched Fedora all the way to downstream, which is
>> sometimes CentOS and sometimes EPEL.
> Then please work with @rh engineering to get an up-to-date packaging
> stack in EL (that means, latest stable Fedora rpm and latest stable
> Fedora packaging macros, and all the other things that make packager
> work less a shore).
>
> A huge amount of EL ifdefs is directly caused by the staleness of the
> packaging stack in EL. That’s why so much Fedora stuff never makes it
> in EPEL. Most people Fedora side do not want to deal with the utter
> clustefuck of trying to push complex up to date software to EL using
> inadequate obsolete tooling.
>
> No amount of clever ifdefing is going to mitigate this tooling
> staleness. No amount of poking is going to convince people that *do*
> *not* *want* *to* *deal* *with* *el* *braindamage* to accept
> braindamage side-effects in their own Fedora specs. That’s trying to
> put lipstick on a pig.
>
> We’ve been saying that to @rh representatives for years now. rpm and
> its ajuncts is the heart of community packaging. Packaging is done by
> packagers. Packaging is not done by people that loath packaging (and
> are continuously surprised their own packaging tools for people not
> interested in packaging do not see mass packager adoption).
>
> rpm state in EL prevents most downstreaming. Please focus efforts
> there.
>
> I don’t see how you will get any community adhesion in fixing
> downstream problems, if all your solutions are downstream focused,
> without caring about the people you want to enroll.
>
RHELN (currently RHEL9) is supposed to look like rawhide up to
whatever the cutover point is. So, up until that point, you shouldn't
be putting RHEL conditionals in, unless you do so for EPEL packages.
There are exceptions to this, such as the kernel, glibc, firefox, and
a handful of others. But those are the exceptions.
After the cutover date, then again, RHELN (in the next case it will be
RHEL10) should be looking like whatever is in rawhide, so you still
shouldn't need RHEL conditionals in, unless you do so for EPEL package
builds.
This ELN proposal has nothing to do with older RHEL releases or EPEL.
Troy
I agree with Nicolas and Troy here. IMO the eln branch is essential for
the success of this change. Every conditional prevents innovation in
Fedora, because nobody knows what is the impact. Even if the CI provides
feedback, that the specific change does not work in ELN, it might result
in not updated package, because everybody will be afraid to touch it.
That is much worse situation then if the package fails to build in ELN.
Vít
11:06 a.m.
Nicolas Mailhot via devel <devel(a)lists.fedoraproject.org> writes:
Le mercredi 25 mars 2020 à 13:09 +0100, Aleksandra Fedorova a écrit
:
> Miro Hrončok <mhroncok(a)redhat.com> wrote:
>
> As I mentioned in the previous mail, branching goes against the
> purpose of the effort.
>
> What we like to achieve is to create a continuous flow from Fedora
> Rawhide through branched Fedora all the way to downstream, which is
> sometimes CentOS and sometimes EPEL.
Then please work with @rh engineering to get an up-to-date packaging
stack in EL (that means, latest stable Fedora rpm and latest stable
Fedora packaging macros, and all the other things that make packager
work less a shore).
A huge amount of EL ifdefs is directly caused by the staleness of the
packaging stack in EL. That’s why so much Fedora stuff never makes it
in EPEL. Most people Fedora side do not want to deal with the utter
clustefuck of trying to push complex up to date software to EL using
inadequate obsolete tooling.
No amount of clever ifdefing is going to mitigate this tooling
staleness. No amount of poking is going to convince people that *do*
*not* *want* *to* *deal* *with* *el* *braindamage* to accept
braindamage side-effects in their own Fedora specs. That’s trying to
put lipstick on a pig.
This is not "being excellent to each other". Let's keep in mind that we
are all here for the same reason (Fedora), and that this makes us
colleagues - including the people who make EL.
Thanks,
--Robbie
12:31 p.m.
On Wed, 2020-03-25 at 13:09 +0100, Aleksandra Fedorova wrote:
On Wed, Mar 25, 2020 at 12:48 PM Miro Hrončok
<mhroncok(a)redhat.com>
wrote:
> On 25. 03. 20 12:37, Fabio Valentini wrote:
> > > 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.
>
> Yes, that makes sense to me. Especially with automation (bacause
> without it, the
> branch would simply get stalled, you cannot rebase all Fedora
> packages manually
> at this scale).
As I mentioned in the previous mail, branching goes against the
purpose of the effort.
What we like to achieve is to create a continuous flow from Fedora
Rawhide through branched Fedora all the way to downstream, which is
sometimes CentOS and sometimes EPEL.
Doing this with branches is going to be much harder. When you update
package with conditionals you do need to care about the effect on
various ifs, but you do need to change the package only once at one
place. And then the tree of branches which we create from Fedora
Rawhide will get this change automatically with no effort.
Of course not ifs are equal. It may require some refactoring on the
code side to make the ifs cleaner. I know kernel people did that with
a kernel package to reorganize patches which are applied.
But this is exactly the work we are looking for: the negotiation
between downstream maintainers and Fedora maintainers to make things
work together. We already have branching, it is easier as it allow us
not to talk to each other, but it doesn't solve anything.
And yes, it means that people are going to be _bothered_, and
_pressured_ on figuring out the best way to collaborate. But isn't it
our job?
No, that's not what your proposal implies. Instead, people are going to
be bothered and pressured to accept the _only_ way to collaborate: put
conditionals into their spec.
And again, if you make it easier for downstream to work with Fedora,
you give downstream the reasons to bring their resources. Things like
quality assurance and help with bug triage and bug fixes, things like
cross-project feature development. This is a two-way collaboration
effort.
Do you suggest that RH maintainers, who have mostly their hands full
maintaining _their_ packages, are going to start maintaining _more_
packages? I find that highly unlikely.
D.
12:45 p.m.
On Wed, Mar 25, 2020 at 1:32 PM David Tardon <dtardon(a)redhat.com> wrote:
...
And yes, it means that people are going to be _bothered_, and
> _pressured_ on figuring out the best way to collaborate. But isn't it
> our job?
No, that's not what your proposal implies. Instead, people are going to
be bothered and pressured to accept the _only_ way to collaborate: put
conditionals into their spec.
I think you are making a bit of a straw-man argument here. Aleksandra
didn't say at any time that only conditionals would be accepted.
(Indeed, she recommended that the ideal situation is for us to avoid
conditionals where possible and instead use Recommends: for things
that are not strict requirements. This would benefit Fedora as well,
since people could trim their installs down to their needs.)
> And again, if you make it easier for downstream to work with
Fedora,
> you give downstream the reasons to bring their resources. Things like
> quality assurance and help with bug triage and bug fixes, things like
> cross-project feature development. This is a two-way collaboration
> effort.
Do you suggest that RH maintainers, who have mostly their hands full
maintaining _their_ packages, are going to start maintaining _more_
packages? I find that highly unlikely.
No, she didn't say that at all. She said that maintainers who are
already doing this work internally to Red Hat would have an
opportunity (and encouragement from their employer) to move that work
to Fedora instead, so that the wider community can take advantage.
1:24 p.m.
On 25. 03. 20 18:45, Stephen Gallagher wrote:
Indeed, she recommended that the ideal situation is for us to avoid
conditionals where possible and instead use Recommends: for things
that are not strict requirements. This would benefit Fedora as well,
since people could trim their installs down to their needs.
Technical problem: No BuildRecommends.
Legal problem:
Currently, "broken recommends" (i.e. recommending stuff that isn't in
Fedora) is
forbidden in Fedora for legal reasons:
https://pagure.io/packaging-committee/issue/914#comment-607130
It is also forbidden to recommend something that used to be in Fedora 31 but got
removed in Fedora 32, from a Fedora 32 package:
https://pagure.io/packaging-committee/issue/914#comment-607154
As far as I understand this, it means it is also forbidden to recommend a
"Fedora only" package from ELN. Because ELN is a different version than
rawhide.
Whether it is allowed to recommend a non-RHEL package from a RHEL package, that
I don't know, but I assume the same logic applies.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
6:49 a.m.
Going back to the questions. See comments inline.
On Tue, Mar 24, 2020 at 3:17 PM Miro Hrončok <mhroncok(a)redhat.com> wrote:
On 24. 03. 20 10:32, Aleksandra Fedorova wrote:
> As Ben is on PTO, I'd like to present the System-Wide Change
>
> https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
>
> == Summary ==
>
> The goal of the ELN project is to continuously build Fedora Rawhide
> packages and composes in the way which resembles the CentOS and RHEL
> build process and to provide a feedback loop for Fedora maintainers on
> the status of those builds.
Form a Fedora POV, this doesn't state what's being "changed" at all.
I would appreciate if it actually said something about the ELN Buildroot and
Compose.
It says that we are going to continuously build el-like compose. We
are adding new pieces of infrastructure to make that happen.
This is an infrastructure change, which doesn't change Fedora content.
> ELN is an evolution of the request for an alternate buildroot
for
> newer x86_64 processors. The reasoning behind that new buildroot was
> that we expected that the next major release of RHEL would likely drop
> support for older hardware and therefore could take advantage of
> enhancements and processor extensions available for newer hardware. As
> plans for this proceeded, they expanded into a desire to do more than
> just test out the processor architecture. Instead, we want to have a
> complete alternative compose of Fedora Rawhide that resembles the way
> that Red Hat and CentOS builds their packages. The idea being that
> Fedora developers and third-party vendors who rely on Red Hat
> Enterprise Linux have a place where they can directly contribute to
> what will eventually become the next RHEL.
I don't understand from the rest of the change how do they contribute to ELN.
By contributing to Fedora Rawhide sources and consuming them as ELN
repositories for testing purposes. But also by contributing directly
to ELN compose configuration.
> ELN (Enterprise Linux Next) is going to be that place. What we
want to
> do is establish a set of RPM conditionals that can be used for the set
> of packages that may need to be built differently for a RHEL-like
> target as compared to a Fedora one. (For example, we may want to skip
> regenerating documentation during package-build and instead use
> pre-built docs from the tarball or SRPM.)
What set of RPM conditionals? This is more clear from the FPC ticket:
https://pagure.io/packaging-committee/issue/955
But even there, it seem that any new conditionals will be discouraged, so what
are the new conditionals this change is talking about?
As a nitpick, it doesn't say _new_ conditionals there. As we don't
want to branch Fedora Rawhide we need a possibility for certain
package to be built differently in the ELN environment. For that we
need rpm conditionals based on disttag.
This is a chicken and egg problem, to be honest. To figure out the
details we need FPC and others contribution, but then to start talking
to FPC we need a Change Proposal so that you get the idea what are we
trying to achieve and why.
> This includes:
>
> * buildroot configuration, rpm macro and compile flags,
> * comps files and the compose content,
> * compose itself and the pipeline which builds it.
Where are those rpm macros and compile flags be defined if this builds from
master? Will there be an alternative branch for (and only for)
redhat-rpm-config, or will redhat-rpm-config be full of such new conditionals?
Are the maintainers of redhat-rpm-config on board?
> ... Some unknown number of packages that rely on `if !
> 0%{?fedora}` will require manual intervention.
And many other cases, see the FPC ticket.
Let's discuss it in the ticket then?
> * CentOS Stream, EPEL and RHEL
> ** We are going to build Fedora packages into a compose similar to the
> multi-repo structure of CentOS and RHEL.
This lacks any details in the description.
I am not sure what kind of details you expect.
Will it help if I add a link to CentOS compose? Like this one
http://mirror.centos.org/centos/8.1.1911/
> ** The feedback pipelines built for the project will allow downstream
> developers to open up their work and bring it closer to Fedora. In
> particular, it will enable projects like OpenShift to do their work in
> Fedora.
I don't understand how. Do you have more details?
For third-parties who develop services and tools for CentOS and RHEL
it is important to have development environment which is close to what
they will achieve in the released version.
Fedora Rawhide is the future RHEL, but as it is packed differently it
is harder to rely on it, when you plan the future of your third-party
service.
ELN compose is a preview of what may happen if we take current Fedora
Rawhide and try to make CentOS/RHEL out of it, like right now. It is a
preview of issues we are going to have as well.
> == Scope ==
> * Proposal owners:
> ** Setup build environment for a new disttag (`eln`).
> ** Setup automation to trigger new ELN build every time there is a new
> update submitted to Fedora Rawhide.
> ** Post build result to Fedora Messaging, so that it appears in Bodhi
> and can be used as a
> [https://docs.fedoraproject.org/en-US/rawhide-gating/ gating test].
> ** Setup automation to run periodic partial composes (via ODCS)
> without installation media to generate repositories with these
> packages.
> ** Update packaging documentation to mention new disttag and how it can be used.
>
> * Other developers:
> *: Anyone who wants to produce different content for the ELN compose
> will need to implement the new macros in their specfile. The
> overwhelming majority of packages will require no modification.
I don't understand the meaning of "implement the new macros".
This is tracked in the FPC ticket.
Do I read it that
if I want to produce different content for the ELN compose, I need to use %if
conditionals for %{rhel}? What if I don't want such conditionals, because I
prefer to have separate branches?
Do you have specific example or asking generally?
I think that not having eln-branch is very important part of the
concept as we don't want to fork Fedora. By using conditionals in spec
files we do create variants of the rpm, but at list we get them
automatically synced with the upstream sources. So whenever you update
the package in Rawhide, ELN binary package is updated too.
Conditionals create problems indeed, we should use them carefully. I
would prefer if instead of conditionals we find ways how to make
Fedora packages more flexible, change from Requires to Suggests for
example, or split into subpackages.
But in this case I think conditionals are a much better choice than
branching, as when done once, they require less maintenance on their
way to downstream.
We add conditional in Rawhide, we inherit it in branched Fedora, we
consume it in CentOS Stream, we get it in EPEL. All of it happens
automatically once we have the ELN compatibility in Rawhide.
I also don't understand how this will work if only the packager
who want this
will participate. Assume you need to build your package "like in the next
RHEL",
so you adapt it (let's say you disable the "shakehands" feature, because
you
don't plan to include "libshakehands" in future RHEL). As a consequence,
packages depending on your package and might also need adapting (becasue they
assume the shakehands feature is available by default). What if the maintainer
of a dependnign package doesn't like %{rhel} conditionals in their specs? Will
the changes be forced? Or will parts of the ELN compose fail to build or install
forever because of this?
We don't have power to enforce anything, and we don't want it.
We'd like to find such problematic places and start a conversation for
them. See if we can negotiate a better solution: split into
subpackages, maybe use modules even. There is no one good answer which
fits for all, it needs to be resolved on a case by case basis.
Yes, there is a risk that it won't work. And we have a very clean
contingency plan for it: we shutdown the whole thing.
It will be unfortunate, but it is an option.
> == User Experience ==
>
> There is no user-facing part in this change. No ELN artifacts are
> going to be shipped to the end-user.
As a packager debugging a problem in ELN, how do I consume it?
It is described in "How to Test" section.
-----------
General questions/feedback follows:
The description of this change is very vague. I don't know if it is intended or
not, but it is very unclear to me, how will this new buildroot work. For example:
Will there be any inheritance from rawhide? After the FESCo meeting I assume
yes, but would like a record of this on the mailing list.
How do we bootstrap things in ELN without disturbing regular rawhide? For
example, assume the following situation:
There is libchicken-1 and libegg-1 in rawhide as well as ELN. They require and
buildrequire each other. The maintainer needs to do an update. He does the
following in Fedora:
- request a side tag
- builds libchicken-2 with bundled egg-2
- builds egg-2
- rebuilds libchicken-2 against the egg-2 package
- request a side tag merge
What happens in ELN? Will all side tags automatically create a bound ELN side
tag? Or after the side tag is merged, libchicken and libegg will be untagged
form ELN and rebuild against the rawhide versions?
There are options here, as it depends on the rate of sidetag builds
and the size of them.
1) we can do only a post-merge rebuild
Rebuild packages in the same order directly into the ELN buildroot
2) we can do a proper sidetag gating event, which means as soon as
sidetag is announced as ready to be tested, we take the list of
packages from it and rebuild it in the same order with ELN buildroot
enabled (via mock probably).
I think we will start with 1) even though it will most likely fail in
the process, and require manual work, and then add 2) to make it
cleaner.
What happens upon ELN build failures? Assume the omelette package
fails to build
in ELN because the chicken and egg problem. Who will chase this and how? Will
the omelette maintainer receive an automatic bug report to fix their package or
will an ELN developer fix this for them? Where do they commit their fixes, if
everything builds from master?
This is mentioned in the Change: we are going to use Rawhide Gating to
provide feedback on such failures. Maintainer of the package will
decide if the update will be blocked on that or not. ELN SIG and
downstream developers will be alerted of such failures and try to come
up with solution for them as well.
Will there be a way to opt-out packages (or stacks of them) from ELN
if they are
not interesting for RHEL?
We want to start with a subset of packages at the beginning (basic
buildroot packages, system-level packages and so on) and see if it can
grow beyond EL-subset later.
I think we should cover EPEL packages too, so it already goes further
than just RHEL.
I could go on with further scenarios and what-ifs. I undrstand if the
answer is
"we don't know yet". But the Change proposal should at least try to explain
how
this buildroot works.
An extra question: How does this play with modularity, if at all. Do we also
rebuild all modules?
Going to come back to this in another mail.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
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@lists.fedoraproject.org
--
Aleksandra Fedorova
bookwar
7:27 a.m.
On 25. 03. 20 12:49, Aleksandra Fedorova wrote:
Going back to the questions. See comments inline.
Thanks.
>> The goal of the ELN project is to continuously build Fedora
Rawhide
>> packages and composes in the way which resembles the CentOS and RHEL
>> build process and to provide a feedback loop for Fedora maintainers on
>> the status of those builds.
>
> Form a Fedora POV, this doesn't state what's being "changed" at
all.
> I would appreciate if it actually said something about the ELN Buildroot and
> Compose.
It says that we are going to continuously build el-like compose. We
are adding new pieces of infrastructure to make that happen.
This is an infrastructure change, which doesn't change Fedora content.
It will eventually change Fedora sources. But even with "this doesn't change
anything" argument, I find the current summary confusing a bit without reading
the rest of the proposal. Can a second sentence like "A new buildroot will be
added Koji that will automatically build packages from master but it have a
different set of macros and config." be added?
>> ELN is an evolution of the request for an alternate buildroot
for
>> newer x86_64 processors. The reasoning behind that new buildroot was
>> that we expected that the next major release of RHEL would likely drop
>> support for older hardware and therefore could take advantage of
>> enhancements and processor extensions available for newer hardware. As
>> plans for this proceeded, they expanded into a desire to do more than
>> just test out the processor architecture. Instead, we want to have a
>> complete alternative compose of Fedora Rawhide that resembles the way
>> that Red Hat and CentOS builds their packages. The idea being that
>> Fedora developers and third-party vendors who rely on Red Hat
>> Enterprise Linux have a place where they can directly contribute to
>> what will eventually become the next RHEL.
>
> I don't understand from the rest of the change how do they contribute to ELN.
By contributing to Fedora Rawhide sources and consuming them as ELN
repositories for testing purposes.
The change proposal literally says "There is no user-facing part in this change.
No ELN artifacts are going to be shipped to the end-user."
As a contributor, how do I consume the content if I cannot consume the content?
As I understand it, the "end-user" and "user-facing" terms must have
different
meanings in this context, right? What is this meaning?
>> ELN (Enterprise Linux Next) is going to be that place. What
we want to
>> do is establish a set of RPM conditionals that can be used for the set
>> of packages that may need to be built differently for a RHEL-like
>> target as compared to a Fedora one. (For example, we may want to skip
>> regenerating documentation during package-build and instead use
>> pre-built docs from the tarball or SRPM.)
>
> What set of RPM conditionals? This is more clear from the FPC ticket:
>
> https://pagure.io/packaging-committee/issue/955
>
> But even there, it seem that any new conditionals will be discouraged, so what
> are the new conditionals this change is talking about?
As a nitpick, it doesn't say _new_ conditionals there. As we don't
want to branch Fedora Rawhide we need a possibility for certain
package to be built differently in the ELN environment.
The ticket says the "new" conditionals (with %{eln}) will be discouraged.
Hence the means to achieve the goal will be the "old" conditionals (with
%{rhel}/%{fedora}). Correct?
For that we need rpm conditionals based on disttag.
This might be a terminology dispute and bike shedding, but I still don't
understand what does "conditionals based on disttag" means. I've asked for
an
example in the FPC ticket and apparently the conditionals are not to be based on
disttag. I think a very thorough decision should be maade regarding the
conditionals and dist tag:
- should %{fedora} be defined at all?
- should %{eln} be versioned?
- should the dist tag be versioned? (see Neal's point with the Koji nevr check)
We can surely do it in the FPC ticket, but people are not gonna find that
discussion there.
This is a chicken and egg problem, to be honest. To figure out the
details we need FPC and others contribution, but then to start talking
to FPC we need a Change Proposal so that you get the idea what are we
trying to achieve and why.
As a member of the FPC I don't think you need to involve FPC at all at this
point other than getting feedback. And I don't see a chicken and egg problem in
here - you have the proposal and we are discussing it.
>> ... Some unknown number of packages that rely on `if !
>> 0%{?fedora}` will require manual intervention.
>
> And many other cases, see the FPC ticket.
Let's discuss it in the ticket then?
I'd rather discuss this here and only come to FPC for approval of new guidelines
when ready. The FPC members who are likely to discuss this are already
discussing this here. Why spitting the discussion into two places?
However, if you prefer to discuss this in the FPC ticket, sure. There is plenty
of feedback now (from people who I assume have come because they have read my
e-mail with the link, but maybe they were just subscribed to the FPC
tickets...). FESCo and FPC tickets are IMHO not a good place to discuss ideas
like this:
- there are no threads
- people there are not "equal" (one group is in the position of power)
- people usually don't follow new tickets
>> * CentOS Stream, EPEL and RHEL
>> ** We are going to build Fedora packages into a compose similar to the
>> multi-repo structure of CentOS and RHEL.
>
> This lacks any details in the description.
I am not sure what kind of details you expect.
Will it help if I add a link to CentOS compose? Like this one
http://mirror.centos.org/centos/8.1.1911/
Partially, yes. Bot mostly: Who decides how is this new repo split into multiple
repos - is it a Fedora (aka FESCo) level decision, or does releng maintain this,
or is it part of the ELN configuration maintained by the change owners? Can
Fedora contributors contribute to this, or is it an internal RH decision?
>> ** The feedback pipelines built for the project will allow
downstream
>> developers to open up their work and bring it closer to Fedora. In
>> particular, it will enable projects like OpenShift to do their work in
>> Fedora.
>
> I don't understand how. Do you have more details?
For third-parties who develop services and tools for CentOS and RHEL
it is important to have development environment which is close to what
they will achieve in the released version.
Fedora Rawhide is the future RHEL, but as it is packed differently it
is harder to rely on it, when you plan the future of your third-party
service.
ELN compose is a preview of what may happen if we take current Fedora
Rawhide and try to make CentOS/RHEL out of it, like right now. It is a
preview of issues we are going to have as well.
Let's not repeat Neal here:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
"Nothing has ever stopped any project from using Fedora..."
> Do I read it that
> if I want to produce different content for the ELN compose, I need to use %if
> conditionals for %{rhel}? What if I don't want such conditionals, because I
> prefer to have separate branches?
Do you have specific example or asking generally?
There are some examples elsewhere in this thread. But I am asking generally.
I think that not having eln-branch is very important part of the
concept as we don't want to fork Fedora. By using conditionals in spec
files we do create variants of the rpm, but at list we get them
automatically synced with the upstream sources. So whenever you update
the package in Rawhide, ELN binary package is updated too.
Conditionals create problems indeed, we should use them carefully. I
would prefer if instead of conditionals we find ways how to make
Fedora packages more flexible, change from Requires to Suggests for
example, or split into subpackages.
But in this case I think conditionals are a much better choice than
branching, as when done once, they require less maintenance on their
way to downstream.
Sure They are good for downstream. RHEL clearly benefits from this.
But they impose additional cognitive overhead on the community maintainers in
Fedora.
We add conditional in Rawhide, we inherit it in branched Fedora, we
consume it in CentOS Stream, we get it in EPEL. All of it happens
automatically once we have the ELN compatibility in Rawhide.
This is all nice only as long as you prefer conditionals over branching. For a
Fedora maintainer who doesn't, this is just "unnecessary cruft" in the spec
file.
> I also don't understand how this will work if only the
packager who want this
> will participate. Assume you need to build your package "like in the next
RHEL",
> so you adapt it (let's say you disable the "shakehands" feature,
because you
> don't plan to include "libshakehands" in future RHEL). As a
consequence,
> packages depending on your package and might also need adapting (becasue they
> assume the shakehands feature is available by default). What if the maintainer
> of a dependnign package doesn't like %{rhel} conditionals in their specs? Will
> the changes be forced? Or will parts of the ELN compose fail to build or install
> forever because of this?
We don't have power to enforce anything, and we don't want it.
We'd like to find such problematic places and start a conversation for
them. See if we can negotiate a better solution: split into
subpackages, maybe use modules even. There is no one good answer which
fits for all, it needs to be resolved on a case by case basis.
Yes, there is a risk that it won't work. And we have a very clean
contingency plan for it: we shutdown the whole thing.
It will be unfortunate, but it is an option.
What is to stop us saying "stop acting like we can stop doing this now and start
over at this point" when we realize this is hurting the Fedora community, but we
need to ship next RHEL? (Sspeaking from experience. Things like this were said.)
>> == User Experience ==
>>
>> There is no user-facing part in this change. No ELN artifacts are
>> going to be shipped to the end-user.
>
> As a packager debugging a problem in ELN, how do I consume it?
It is described in "How to Test" section.
Those sections contradict each other in that case.
> Will there be a way to opt-out packages (or stacks of them) from
ELN if they are
> not interesting for RHEL?
We want to start with a subset of packages at the beginning (basic
buildroot packages, system-level packages and so on) and see if it can
grow beyond EL-subset later.
I think we should cover EPEL packages too, so it already goes further
than just RHEL.
So this is already the plan (only have some packages)? I have not understood
that from the proposal at all.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
8:04 a.m.
On Wed, Mar 25, 2020 at 8:29 AM Miro Hrončok <mhroncok(a)redhat.com> wrote:
>> Will there be a way to opt-out packages (or stacks of them)
from ELN if they are
>> not interesting for RHEL?
>
> We want to start with a subset of packages at the beginning (basic
> buildroot packages, system-level packages and so on) and see if it can
> grow beyond EL-subset later.
> I think we should cover EPEL packages too, so it already goes further
> than just RHEL.
So this is already the plan (only have some packages)? I have not understood
that from the proposal at all.
This was left out of the proposal because we hadn't come to a firm
decision on it yet (it's still somewhat fluid). ELN SIG members are
agreed that this will *not* be "every package in Fedora", but there's
still some disagreement about which specific subset it will be. As
Aleksandra says, it will likely be more than just RHEL BaseOS, but by
how much is an open question.
8:06 a.m.
Hi, Miro,
On Wed, Mar 25, 2020 at 1:28 PM Miro Hrončok <mhroncok(a)redhat.com> wrote:
On 25. 03. 20 12:49, Aleksandra Fedorova wrote:
> Going back to the questions. See comments inline.
Thanks.
>>> The goal of the ELN project is to continuously build Fedora Rawhide
>>> packages and composes in the way which resembles the CentOS and RHEL
>>> build process and to provide a feedback loop for Fedora maintainers on
>>> the status of those builds.
>>
>> Form a Fedora POV, this doesn't state what's being "changed"
at all.
>> I would appreciate if it actually said something about the ELN Buildroot and
>> Compose.
>
> It says that we are going to continuously build el-like compose. We
> are adding new pieces of infrastructure to make that happen.
> This is an infrastructure change, which doesn't change Fedora content.
It will eventually change Fedora sources. But even with "this doesn't change
anything" argument, I find the current summary confusing a bit without reading
the rest of the proposal. Can a second sentence like "A new buildroot will be
added Koji that will automatically build packages from master but it have a
different set of macros and config." be added?
>>> ELN is an evolution of the request for an alternate buildroot for
>>> newer x86_64 processors. The reasoning behind that new buildroot was
>>> that we expected that the next major release of RHEL would likely drop
>>> support for older hardware and therefore could take advantage of
>>> enhancements and processor extensions available for newer hardware. As
>>> plans for this proceeded, they expanded into a desire to do more than
>>> just test out the processor architecture. Instead, we want to have a
>>> complete alternative compose of Fedora Rawhide that resembles the way
>>> that Red Hat and CentOS builds their packages. The idea being that
>>> Fedora developers and third-party vendors who rely on Red Hat
>>> Enterprise Linux have a place where they can directly contribute to
>>> what will eventually become the next RHEL.
>>
>> I don't understand from the rest of the change how do they contribute to
ELN.
>
> By contributing to Fedora Rawhide sources and consuming them as ELN
> repositories for testing purposes.
The change proposal literally says "There is no user-facing part in this change.
No ELN artifacts are going to be shipped to the end-user."
As a contributor, how do I consume the content if I cannot consume the content?
As I understand it, the "end-user" and "user-facing" terms must have
different
meanings in this context, right? What is this meaning?
Looks like terminology issue. For me user is a person who uses
released Fedora, like Fedora 31 Workstation, on their laptop, or
Fedora 32 IoT edition on their Raspberry Pi, or a minimalistic Fedora
for Fedora server.
Basically anyone who needs Fedora to solve their own problems, which
are not related to development of the distribution.
Fedora Rawhide is not a user-facing branch in Fedora, because it's
purpose is to develop Fedora, not something else.
Same with ELN. It is not a Fedora Server edition, there is no reason
to ever use it on a server. It is a rebuild of Fedora Rawhide, and
it's purpose is the development of Fedora, and help others to
contribute to that development.
So it is facing contributors, not users.
Different types of contributors though.
>>> ELN (Enterprise Linux Next) is going to be that place.
What we want to
>>> do is establish a set of RPM conditionals that can be used for the set
>>> of packages that may need to be built differently for a RHEL-like
>>> target as compared to a Fedora one. (For example, we may want to skip
>>> regenerating documentation during package-build and instead use
>>> pre-built docs from the tarball or SRPM.)
>>
>> What set of RPM conditionals? This is more clear from the FPC ticket:
>>
>> https://pagure.io/packaging-committee/issue/955
>>
>> But even there, it seem that any new conditionals will be discouraged, so what
>> are the new conditionals this change is talking about?
>
> As a nitpick, it doesn't say _new_ conditionals there. As we don't
> want to branch Fedora Rawhide we need a possibility for certain
> package to be built differently in the ELN environment.
The ticket says the "new" conditionals (with %{eln}) will be discouraged.
Hence the means to achieve the goal will be the "old" conditionals (with
%{rhel}/%{fedora}). Correct?
> For that we need rpm conditionals based on disttag.
This might be a terminology dispute and bike shedding, but I still don't
understand what does "conditionals based on disttag" means. I've asked for
an
example in the FPC ticket and apparently the conditionals are not to be based on
disttag. I think a very thorough decision should be maade regarding the
conditionals and dist tag:
- should %{fedora} be defined at all?
- should %{eln} be versioned?
- should the dist tag be versioned? (see Neal's point with the Koji nevr check)
We can surely do it in the FPC ticket, but people are not gonna find that
discussion there.
> This is a chicken and egg problem, to be honest. To figure out the
> details we need FPC and others contribution, but then to start talking
> to FPC we need a Change Proposal so that you get the idea what are we
> trying to achieve and why.
As a member of the FPC I don't think you need to involve FPC at all at this
point other than getting feedback. And I don't see a chicken and egg problem in
here - you have the proposal and we are discussing it.
>>> ... Some unknown number of packages that rely on `if !
>>> 0%{?fedora}` will require manual intervention.
>>
>> And many other cases, see the FPC ticket.
>
> Let's discuss it in the ticket then?
I'd rather discuss this here and only come to FPC for approval of new guidelines
when ready. The FPC members who are likely to discuss this are already
discussing this here. Why spitting the discussion into two places?
Sorry, my understanding of why we need RelEng and FPC tickets was
completely the opposite. Mailing list discussion about the Change is
generic, and gets side-tracked to one side or the other and digging
through it to get the pieces which are relevant to FPC topic is
harder. While ticket has a fixed topic, discussion associated to it
and the outcome of that discussion. I don't see how you can prevent
people from discussing the topic in the ticket and move it to the
mailing list.
If you see FPC ticket as a "request to vote" only, why do we need it
then? Can't we just invite FPC representative to vote on a FESCo
ticket?
However, if you prefer to discuss this in the FPC ticket, sure. There
is plenty
of feedback now (from people who I assume have come because they have read my
e-mail with the link, but maybe they were just subscribed to the FPC
tickets...). FESCo and FPC tickets are IMHO not a good place to discuss ideas
like this:
- there are no threads
- people there are not "equal" (one group is in the position of power)
- people usually don't follow new tickets
>>> * CentOS Stream, EPEL and RHEL
>>> ** We are going to build Fedora packages into a compose similar to the
>>> multi-repo structure of CentOS and RHEL.
>>
>> This lacks any details in the description.
>
> I am not sure what kind of details you expect.
>
> Will it help if I add a link to CentOS compose? Like this one
> http://mirror.centos.org/centos/8.1.1911/
Partially, yes. Bot mostly: Who decides how is this new repo split into multiple
repos - is it a Fedora (aka FESCo) level decision, or does releng maintain this,
or is it part of the ELN configuration maintained by the change owners? Can
Fedora contributors contribute to this, or is it an internal RH decision?
Ok, going to update that.
>>> ** The feedback pipelines built for the project will
allow downstream
>>> developers to open up their work and bring it closer to Fedora. In
>>> particular, it will enable projects like OpenShift to do their work in
>>> Fedora.
>>
>> I don't understand how. Do you have more details?
>
> For third-parties who develop services and tools for CentOS and RHEL
> it is important to have development environment which is close to what
> they will achieve in the released version.
> Fedora Rawhide is the future RHEL, but as it is packed differently it
> is harder to rely on it, when you plan the future of your third-party
> service.
>
> ELN compose is a preview of what may happen if we take current Fedora
> Rawhide and try to make CentOS/RHEL out of it, like right now. It is a
> preview of issues we are going to have as well.
Let's not repeat Neal here:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
"Nothing has ever stopped any project from using Fedora..."
>> Do I read it that
>> if I want to produce different content for the ELN compose, I need to use %if
>> conditionals for %{rhel}? What if I don't want such conditionals, because I
>> prefer to have separate branches?
>
> Do you have specific example or asking generally?
There are some examples elsewhere in this thread. But I am asking generally.
> I think that not having eln-branch is very important part of the
> concept as we don't want to fork Fedora. By using conditionals in spec
> files we do create variants of the rpm, but at list we get them
> automatically synced with the upstream sources. So whenever you update
> the package in Rawhide, ELN binary package is updated too.
>
> Conditionals create problems indeed, we should use them carefully. I
> would prefer if instead of conditionals we find ways how to make
> Fedora packages more flexible, change from Requires to Suggests for
> example, or split into subpackages.
> But in this case I think conditionals are a much better choice than
> branching, as when done once, they require less maintenance on their
> way to downstream.
Sure They are good for downstream. RHEL clearly benefits from this.
But they impose additional cognitive overhead on the community maintainers in
Fedora.
> We add conditional in Rawhide, we inherit it in branched Fedora, we
> consume it in CentOS Stream, we get it in EPEL. All of it happens
> automatically once we have the ELN compatibility in Rawhide.
This is all nice only as long as you prefer conditionals over branching. For a
Fedora maintainer who doesn't, this is just "unnecessary cruft" in the spec
file.
It is not really about personal preferences. These are two different
approaches with different purposes, different results and different
requirements.
There are consequences on choosing one other the other.
Branching means forking Fedora Rawhide into something else. Which
eventually will lead to new downstream tree which will ignore the rest
of Fedora and just use the fork instead. It can be done, but I think
it will damage Fedora as a project.
>> I also don't understand how this will work if only the
packager who want this
>> will participate. Assume you need to build your package "like in the next
RHEL",
>> so you adapt it (let's say you disable the "shakehands" feature,
because you
>> don't plan to include "libshakehands" in future RHEL). As a
consequence,
>> packages depending on your package and might also need adapting (becasue they
>> assume the shakehands feature is available by default). What if the maintainer
>> of a dependnign package doesn't like %{rhel} conditionals in their specs?
Will
>> the changes be forced? Or will parts of the ELN compose fail to build or
install
>> forever because of this?
>
> We don't have power to enforce anything, and we don't want it.
>
> We'd like to find such problematic places and start a conversation for
> them. See if we can negotiate a better solution: split into
> subpackages, maybe use modules even. There is no one good answer which
> fits for all, it needs to be resolved on a case by case basis.
>
> Yes, there is a risk that it won't work. And we have a very clean
> contingency plan for it: we shutdown the whole thing.
> It will be unfortunate, but it is an option.
What is to stop us saying "stop acting like we can stop doing this now and start
over at this point" when we realize this is hurting the Fedora community, but we
need to ship next RHEL? (Sspeaking from experience. Things like this were said.)
I don't understand your question. Nothing ever stops anyone from
saying anything. But it is FESCo and Fedora Council who have the
decision power.
But if you look at the change you'll see that it has no blocking
features whatsoever. We are not changing how Fedora is built and how
it is released.
So if you have a worry that this change is hard to cancel, please
explain why you think so.
>>> == User Experience ==
>>>
>>> There is no user-facing part in this change. No ELN artifacts are
>>> going to be shipped to the end-user.
>>
>> As a packager debugging a problem in ELN, how do I consume it?
>
> It is described in "How to Test" section.
Those sections contradict each other in that case.
As I explained before users and contributors are different. ELN
packages are not to be used at home. These are developer tools.
>> Will there be a way to opt-out packages (or stacks of them)
from ELN if they are
>> not interesting for RHEL?
>
> We want to start with a subset of packages at the beginning (basic
> buildroot packages, system-level packages and so on) and see if it can
> grow beyond EL-subset later.
> I think we should cover EPEL packages too, so it already goes further
> than just RHEL.
So this is already the plan (only have some packages)? I have not understood
that from the proposal at all.
I will add note about it.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
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@lists.fedoraproject.org
--
Aleksandra Fedorova
bookwar
9:02 a.m.
On Wed, Mar 25, 2020 at 02:06:59PM +0100, Aleksandra Fedorova wrote:
Hi, Miro,
On Wed, Mar 25, 2020 at 1:28 PM Miro Hrončok <mhroncok(a)redhat.com> wrote:
>
> On 25. 03. 20 12:49, Aleksandra Fedorova wrote:
> > Going back to the questions. See comments inline.
>
> Thanks.
>
> >>> The goal of the ELN project is to continuously build Fedora Rawhide
> >>> packages and composes in the way which resembles the CentOS and RHEL
> >>> build process and to provide a feedback loop for Fedora maintainers on
> >>> the status of those builds.
> >>
> >> Form a Fedora POV, this doesn't state what's being
"changed" at all.
> >> I would appreciate if it actually said something about the ELN Buildroot
and
> >> Compose.
> >
> > It says that we are going to continuously build el-like compose. We
> > are adding new pieces of infrastructure to make that happen.
> > This is an infrastructure change, which doesn't change Fedora content.
>
> It will eventually change Fedora sources. But even with "this doesn't
change
> anything" argument, I find the current summary confusing a bit without reading
> the rest of the proposal. Can a second sentence like "A new buildroot will be
> added Koji that will automatically build packages from master but it have a
> different set of macros and config." be added?
>
> >>> ELN is an evolution of the request for an alternate buildroot for
> >>> newer x86_64 processors. The reasoning behind that new buildroot was
> >>> that we expected that the next major release of RHEL would likely drop
> >>> support for older hardware and therefore could take advantage of
> >>> enhancements and processor extensions available for newer hardware. As
> >>> plans for this proceeded, they expanded into a desire to do more than
> >>> just test out the processor architecture. Instead, we want to have a
> >>> complete alternative compose of Fedora Rawhide that resembles the way
> >>> that Red Hat and CentOS builds their packages. The idea being that
> >>> Fedora developers and third-party vendors who rely on Red Hat
> >>> Enterprise Linux have a place where they can directly contribute to
> >>> what will eventually become the next RHEL.
> >>
> >> I don't understand from the rest of the change how do they contribute
to ELN.
> >
> > By contributing to Fedora Rawhide sources and consuming them as ELN
> > repositories for testing purposes.
>
> The change proposal literally says "There is no user-facing part in this
change.
> No ELN artifacts are going to be shipped to the end-user."
>
> As a contributor, how do I consume the content if I cannot consume the content?
> As I understand it, the "end-user" and "user-facing" terms must
have different
> meanings in this context, right? What is this meaning?
Looks like terminology issue. For me user is a person who uses
released Fedora, like Fedora 31 Workstation, on their laptop, or
Fedora 32 IoT edition on their Raspberry Pi, or a minimalistic Fedora
for Fedora server.
Basically anyone who needs Fedora to solve their own problems, which
are not related to development of the distribution.
Fedora Rawhide is not a user-facing branch in Fedora, because it's
purpose is to develop Fedora, not something else.
Same with ELN. It is not a Fedora Server edition, there is no reason
to ever use it on a server. It is a rebuild of Fedora Rawhide, and
it's purpose is the development of Fedora, and help others to
contribute to that development.
So it is facing contributors, not users.
Different types of contributors though.
OK, we should be on the same page wrt. to the meaning of "end-user".
But what about developers: if one wanted to use eln for the purposes
for which they currently use rawhide, how would they go about it?
(In particular: running rawhide on their personal computer to find
bugs early, compiling upstream projects on rawhide for compatibility
testing, using rawhide when doing new packages, running rawhide just
to have everything newest).
> >>> ELN (Enterprise Linux Next) is going to be that
place. What we want to
> >>> do is establish a set of RPM conditionals that can be used for the set
> >>> of packages that may need to be built differently for a RHEL-like
> >>> target as compared to a Fedora one. (For example, we may want to skip
> >>> regenerating documentation during package-build and instead use
> >>> pre-built docs from the tarball or SRPM.)
> >>
> >> What set of RPM conditionals? This is more clear from the FPC ticket:
> >>
> >> https://pagure.io/packaging-committee/issue/955
> >>
> >> But even there, it seem that any new conditionals will be discouraged, so
what
> >> are the new conditionals this change is talking about?
> >
> > As a nitpick, it doesn't say _new_ conditionals there. As we don't
> > want to branch Fedora Rawhide we need a possibility for certain
> > package to be built differently in the ELN environment.
>
> The ticket says the "new" conditionals (with %{eln}) will be discouraged.
> Hence the means to achieve the goal will be the "old" conditionals (with
> %{rhel}/%{fedora}). Correct?
>
> > For that we need rpm conditionals based on disttag.
>
> This might be a terminology dispute and bike shedding, but I still don't
> understand what does "conditionals based on disttag" means. I've asked
for an
> example in the FPC ticket and apparently the conditionals are not to be based on
> disttag. I think a very thorough decision should be maade regarding the
> conditionals and dist tag:
>
> - should %{fedora} be defined at all?
> - should %{eln} be versioned?
> - should the dist tag be versioned? (see Neal's point with the Koji nevr
check)
>
> We can surely do it in the FPC ticket, but people are not gonna find that
> discussion there.
>
> > This is a chicken and egg problem, to be honest. To figure out the
> > details we need FPC and others contribution, but then to start talking
> > to FPC we need a Change Proposal so that you get the idea what are we
> > trying to achieve and why.
>
> As a member of the FPC I don't think you need to involve FPC at all at this
> point other than getting feedback. And I don't see a chicken and egg problem in
> here - you have the proposal and we are discussing it.
>
> >>> ... Some unknown number of packages that rely on `if !
> >>> 0%{?fedora}` will require manual intervention.
> >>
> >> And many other cases, see the FPC ticket.
> >
> > Let's discuss it in the ticket then?
>
> I'd rather discuss this here and only come to FPC for approval of new
guidelines
> when ready. The FPC members who are likely to discuss this are already
> discussing this here. Why spitting the discussion into two places?
Sorry, my understanding of why we need RelEng and FPC tickets was
completely the opposite. Mailing list discussion about the Change is
generic, and gets side-tracked to one side or the other and digging
through it to get the pieces which are relevant to FPC topic is
harder. While ticket has a fixed topic, discussion associated to it
and the outcome of that discussion. I don't see how you can prevent
people from discussing the topic in the ticket and move it to the
mailing list.
If you see FPC ticket as a "request to vote" only, why do we need it
then? Can't we just invite FPC representative to vote on a FESCo
ticket?
IMO, it is too early to involve FPC, because it is very unclear what
the goals are, and what kind of differences from existing Fedora packaing
are indended. Once that part has been clarified, then FPC can decide
the specific form of macros and other packaging changes that best
implements those goals and adjust the packaging guidelines.
So yes, let's please discuss this here.
> However, if you prefer to discuss this in the FPC ticket, sure.
There is plenty
> of feedback now (from people who I assume have come because they have read my
> e-mail with the link, but maybe they were just subscribed to the FPC
> tickets...). FESCo and FPC tickets are IMHO not a good place to discuss ideas
> like this:
>
> - there are no threads
> - people there are not "equal" (one group is in the position of power)
> - people usually don't follow new tickets
>
> >>> * CentOS Stream, EPEL and RHEL
> >>> ** We are going to build Fedora packages into a compose similar to the
> >>> multi-repo structure of CentOS and RHEL.
> >>
> >> This lacks any details in the description.
> >
> > I am not sure what kind of details you expect.
> >
> > Will it help if I add a link to CentOS compose? Like this one
> > http://mirror.centos.org/centos/8.1.1911/
>
> Partially, yes. Bot mostly: Who decides how is this new repo split into multiple
> repos - is it a Fedora (aka FESCo) level decision, or does releng maintain this,
> or is it part of the ELN configuration maintained by the change owners? Can
> Fedora contributors contribute to this, or is it an internal RH decision?
Ok, going to update that.
> >>> ** The feedback pipelines built for the project will allow downstream
> >>> developers to open up their work and bring it closer to Fedora. In
> >>> particular, it will enable projects like OpenShift to do their work in
> >>> Fedora.
> >>
> >> I don't understand how. Do you have more details?
> >
> > For third-parties who develop services and tools for CentOS and RHEL
> > it is important to have development environment which is close to what
> > they will achieve in the released version.
> > Fedora Rawhide is the future RHEL, but as it is packed differently it
> > is harder to rely on it, when you plan the future of your third-party
> > service.
> >
> > ELN compose is a preview of what may happen if we take current Fedora
> > Rawhide and try to make CentOS/RHEL out of it, like right now. It is a
> > preview of issues we are going to have as well.
>
> Let's not repeat Neal here:
>
>
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
>
> "Nothing has ever stopped any project from using Fedora..."
>
> >> Do I read it that
> >> if I want to produce different content for the ELN compose, I need to use
%if
> >> conditionals for %{rhel}? What if I don't want such conditionals,
because I
> >> prefer to have separate branches?
> >
> > Do you have specific example or asking generally?
>
> There are some examples elsewhere in this thread. But I am asking generally.
>
> > I think that not having eln-branch is very important part of the
> > concept as we don't want to fork Fedora. By using conditionals in spec
> > files we do create variants of the rpm, but at list we get them
> > automatically synced with the upstream sources. So whenever you update
> > the package in Rawhide, ELN binary package is updated too.
> >
> > Conditionals create problems indeed, we should use them carefully. I
> > would prefer if instead of conditionals we find ways how to make
> > Fedora packages more flexible, change from Requires to Suggests for
> > example, or split into subpackages.
> > But in this case I think conditionals are a much better choice than
> > branching, as when done once, they require less maintenance on their
> > way to downstream.
>
> Sure They are good for downstream. RHEL clearly benefits from this.
> But they impose additional cognitive overhead on the community maintainers in
> Fedora.
>
>
> > We add conditional in Rawhide, we inherit it in branched Fedora, we
> > consume it in CentOS Stream, we get it in EPEL. All of it happens
> > automatically once we have the ELN compatibility in Rawhide.
>
> This is all nice only as long as you prefer conditionals over branching. For a
> Fedora maintainer who doesn't, this is just "unnecessary cruft" in the
spec file.
It is not really about personal preferences. These are two different
approaches with different purposes, different results and different
requirements.
There are consequences on choosing one other the other.
Branching means forking Fedora Rawhide into something else. Which
eventually will lead to new downstream tree which will ignore the rest
of Fedora and just use the fork instead. It can be done, but I think
it will damage Fedora as a project.
IMO, that significantly overstates the difference between the two.
In particular, branching is exactly what happens every six months when
we start a new release, and yes, it is possible for the branches to
diverge, but no, it is also possible to keep the branches synchronized
and actually for many packages this is what happens.
For any specific package, whether the branches are similar or divergent
depends on the situation of the package and maintainer choices.
Also, a side note: with the planned changes to do away with changelogs
and release tags in .spec, branches have the potential to become identical
(i.e. we would still have branches, to know what to build where, but they
would point to the same commit).
Heavy ifdeffery in spec files is something of a past. Different
maintainers have different preferences, but I think it is fair to
say that we have moved significantly in the direction of simplified
spec files and less conditionals.
I think you shouldn't discount the separate branch approach just yet.
> >> I also don't understand how this will work if only
the packager who want this
> >> will participate. Assume you need to build your package "like in the
next RHEL",
> >> so you adapt it (let's say you disable the "shakehands"
feature, because you
> >> don't plan to include "libshakehands" in future RHEL). As a
consequence,
> >> packages depending on your package and might also need adapting (becasue
they
> >> assume the shakehands feature is available by default). What if the
maintainer
> >> of a dependnign package doesn't like %{rhel} conditionals in their
specs? Will
> >> the changes be forced? Or will parts of the ELN compose fail to build or
install
> >> forever because of this?
> >
> > We don't have power to enforce anything, and we don't want it.
> >
> > We'd like to find such problematic places and start a conversation for
> > them. See if we can negotiate a better solution: split into
> > subpackages, maybe use modules even. There is no one good answer which
> > fits for all, it needs to be resolved on a case by case basis.
> >
> > Yes, there is a risk that it won't work. And we have a very clean
> > contingency plan for it: we shutdown the whole thing.
> > It will be unfortunate, but it is an option.
>
> What is to stop us saying "stop acting like we can stop doing this now and
start
> over at this point" when we realize this is hurting the Fedora community, but
we
> need to ship next RHEL? (Sspeaking from experience. Things like this were said.)
I don't understand your question. Nothing ever stops anyone from
saying anything. But it is FESCo and Fedora Council who have the
decision power.
But if you look at the change you'll see that it has no blocking
features whatsoever. We are not changing how Fedora is built and how
it is released.
So if you have a worry that this change is hard to cancel, please
explain why you think so.
Whenever we do something, we have some obligation towards our users
and fellow contributors. I do packages, and if create a package, I have
to take into account that the package be used and I cannot yank
it next week. Or maybe I can, but it'll make people unhappy. The same
principle applies in case of eln, but on a much larger scale. Miro mentioned
the potential need to keep eln around to ship next RHEL. But there are
other cases: openshift upstream was mentioned. If they hypothetically
decide to rework their development process to base it on eln, just
dropping it one day would not be inconsequential.
If eln is to be advertised for serious use, then I would at least
expect the contingency mechanism to include a transition mechanism.
Maybe move people over to rawhide, or maybe promise 6 months of heads-up
before removal. Neither seems easy or satisfactory.
Zbyszek
10:55 a.m.
Dne 25. 03. 20 v 15:02 Zbigniew Jędrzejewski-Szmek napsal(a):
On Wed, Mar 25, 2020 at 02:06:59PM +0100, Aleksandra Fedorova wrote:
> Hi, Miro,
>
> On Wed, Mar 25, 2020 at 1:28 PM Miro Hrončok <mhroncok(a)redhat.com> wrote:
>> On 25. 03. 20 12:49, Aleksandra Fedorova wrote:
>>> I think that not having eln-branch is very important part of the
>>> concept as we don't want to fork Fedora. By using conditionals in spec
>>> files we do create variants of the rpm, but at list we get them
>>> automatically synced with the upstream sources. So whenever you update
>>> the package in Rawhide, ELN binary package is updated too.
>>>
>>> Conditionals create problems indeed, we should use them carefully. I
>>> would prefer if instead of conditionals we find ways how to make
>>> Fedora packages more flexible, change from Requires to Suggests for
>>> example, or split into subpackages.
>>> But in this case I think conditionals are a much better choice than
>>> branching, as when done once, they require less maintenance on their
>>> way to downstream.
>> Sure They are good for downstream. RHEL clearly benefits from this.
>> But they impose additional cognitive overhead on the community maintainers in
>> Fedora.
>>
>>
>>> We add conditional in Rawhide, we inherit it in branched Fedora, we
>>> consume it in CentOS Stream, we get it in EPEL. All of it happens
>>> automatically once we have the ELN compatibility in Rawhide.
>> This is all nice only as long as you prefer conditionals over branching. For a
>> Fedora maintainer who doesn't, this is just "unnecessary cruft" in
the spec file.
> It is not really about personal preferences. These are two different
> approaches with different purposes, different results and different
> requirements.
> There are consequences on choosing one other the other.
>
> Branching means forking Fedora Rawhide into something else. Which
> eventually will lead to new downstream tree which will ignore the rest
> of Fedora and just use the fork instead. It can be done, but I think
> it will damage Fedora as a project.
Just FTR, there is `git symbolic-ref` [1], which means that the "branch"
won't need to be necessarily branch, if the content of master and
rawhide is the same. In that case, you don't even need any
synchronization. Given this, it would be easy to track how many packages
are vanilla Rawhide packages and which are modified and need special
attention.
But this is of course just implementation detail.
Vít
[1] https://git-scm.com/docs/git-symbolic-ref
IMO, that significantly overstates the difference between the two.
In particular, branching is exactly what happens every six months when
we start a new release, and yes, it is possible for the branches to
diverge, but no, it is also possible to keep the branches synchronized
and actually for many packages this is what happens.
For any specific package, whether the branches are similar or divergent
depends on the situation of the package and maintainer choices.
Also, a side note: with the planned changes to do away with changelogs
and release tags in .spec, branches have the potential to become identical
(i.e. we would still have branches, to know what to build where, but they
would point to the same commit).
Heavy ifdeffery in spec files is something of a past. Different
maintainers have different preferences, but I think it is fair to
say that we have moved significantly in the direction of simplified
spec files and less conditionals.
I think you shouldn't discount the separate branch approach just yet.
9:10 a.m.
On 25. 03. 20 14:06, Aleksandra Fedorova wrote:
>> By contributing to Fedora Rawhide sources and consuming them
as ELN
>> repositories for testing purposes.
>
> The change proposal literally says "There is no user-facing part in this
change.
> No ELN artifacts are going to be shipped to the end-user."
>
> As a contributor, how do I consume the content if I cannot consume the content?
> As I understand it, the "end-user" and "user-facing" terms must
have different
> meanings in this context, right? What is this meaning?
Looks like terminology issue. For me user is a person who uses
released Fedora, like Fedora 31 Workstation, on their laptop, or
Fedora 32 IoT edition on their Raspberry Pi, or a minimalistic Fedora
for Fedora server.
Basically anyone who needs Fedora to solve their own problems, which
are not related to development of the distribution.
Fedora Rawhide is not a user-facing branch in Fedora, because it's
purpose is to develop Fedora, not something else.
Same with ELN. It is not a Fedora Server edition, there is no reason
to ever use it on a server. It is a rebuild of Fedora Rawhide, and
it's purpose is the development of Fedora, and help others to
contribute to that development.
So it is facing contributors, not users.
Different types of contributors though.
I consider rawhide users our users and I assume many other do consider them our
users as well. I consider upstream projects who run their CI on Fedora our
users. You are not incorrect that this is a terminology issue, however I think
this is a different mindset issue. Please do consider rawhide users and upstream
projects our users when designing things.
For example, there is a point to run an ELN on a server - e.g. to run a buildbot
worker on it for some CI tests.
> I'd rather discuss this here and only come to FPC for
approval of new guidelines
> when ready. The FPC members who are likely to discuss this are already
> discussing this here. Why spitting the discussion into two places?
Sorry, my understanding of why we need RelEng and FPC tickets was
completely the opposite. Mailing list discussion about the Change is
generic, and gets side-tracked to one side or the other and digging
through it to get the pieces which are relevant to FPC topic is
harder. While ticket has a fixed topic, discussion associated to it
and the outcome of that discussion. I don't see how you can prevent
people from discussing the topic in the ticket and move it to the
mailing list.
If you see FPC ticket as a "request to vote" only, why do we need it
then? Can't we just invite FPC representative to vote on a FESCo
ticket?
We could, but there are existing workflows based on the committees using their
own ticketing tracker to do the voting.
> This is all nice only as long as you prefer conditionals over
branching. For a
> Fedora maintainer who doesn't, this is just "unnecessary cruft" in the
spec file.
It is not really about personal preferences. These are two different
approaches with different purposes, different results and different
requirements.
There are consequences on choosing one other the other.
Yes. That's what I've been saying since the beginning. Choosing %ifs over
branches has consequences. Choosing branches over %ifs has consequences. Not
being able to choose has consequences.
Branching means forking Fedora Rawhide into something else. Which
eventually will lead to new downstream tree which will ignore the rest
of Fedora and just use the fork instead. It can be done, but I think
it will damage Fedora as a project.
Not if we do automation that constantly keeps them in sync. Is that hard? Most
likely. But it doesn't put additional burden to the community maintainers.
>> Yes, there is a risk that it won't work. And we have a
very clean
>> contingency plan for it: we shutdown the whole thing.
>> It will be unfortunate, but it is an option.
>
> What is to stop us saying "stop acting like we can stop doing this now and
start
> over at this point" when we realize this is hurting the Fedora community, but
we
> need to ship next RHEL? (Sspeaking from experience. Things like this were said.)
I don't understand your question. Nothing ever stops anyone from
saying anything. But it is FESCo and Fedora Council who have the
decision power.
Correct. I just want to avoid us repeating the same mistakes over and over
again. I am afraid this change has a potential to alienate community
contributors and I would like us to consider the problem before we start doing
it and before RHEL is depending on it and before everybody will just repeat "we
cannot change this, because we have this in RHEL already".
So can we please not rush this and try to figure things ad hoc, but dedicate
some more time to planning things? Especially I'd appreciate if the "how do we
make this work without %if spaghetti everywhere" aspect is considered.
But if you look at the change you'll see that it has no blocking
features whatsoever. We are not changing how Fedora is built and how
it is released.
1) This changes how Fedora is maintained.
2) This has a potential of changing how RHEL is bootstrapped, making it
essential and hard to cancel.
So if you have a worry that this change is hard to cancel, please
explain why you think so.
See the two sections above this one.
>>>> == User Experience ==
>>>>
>>>> There is no user-facing part in this change. No ELN artifacts are
>>>> going to be shipped to the end-user.
>>>
>>> As a packager debugging a problem in ELN, how do I consume it?
>>
>> It is described in "How to Test" section.
>
> Those sections contradict each other in that case.
As I explained before users and contributors are different. ELN
packages are not to be used at home. These are developer tools.
I use developer tools at home. Plenty of Fedora users are developers. Plenty of
Fedora developers are Fedora users. I don't understand your terminology at all.
Saying "we are not going to ship this to users" sounds alienating
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
9:42 a.m.
On 25. 03. 20 15:10, Miro Hrončok wrote:
>>>>> == User Experience ==
>>>>>
>>>>> There is no user-facing part in this change. No ELN artifacts are
>>>>> going to be shipped to the end-user.
>>>>
>>>> As a packager debugging a problem in ELN, how do I consume it?
>>>
>>> It is described in "How to Test" section.
>>
>> Those sections contradict each other in that case.
>
> As I explained before users and contributors are different. ELN
> packages are not to be used at home. These are developer tools.
I use developer tools at home. Plenty of Fedora users are developers. Plenty of
Fedora developers are Fedora users. I don't understand your terminology at all.
Saying "we are not going to ship this to users" sounds alienating
I seem to have lost the rest of the paragraph. Sorry about that.
Saying "we are not going to ship this to users" sounds alienating even if our
intentions are not even close to that. Can we maybe not say that this way? Can
we instead describe how to consume ELN in the user experience section?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
9:50 a.m.
On Wed, Mar 25, 2020 at 3:23 PM Miro Hrončok <mhroncok(a)redhat.com> wrote:
On 25. 03. 20 14:06, Aleksandra Fedorova wrote:
>>> By contributing to Fedora Rawhide sources and consuming them as ELN
>>> repositories for testing purposes.
>>
>> The change proposal literally says "There is no user-facing part in this
change.
>> No ELN artifacts are going to be shipped to the end-user."
>>
>> As a contributor, how do I consume the content if I cannot consume the content?
>> As I understand it, the "end-user" and "user-facing" terms
must have different
>> meanings in this context, right? What is this meaning?
>
> Looks like terminology issue. For me user is a person who uses
> released Fedora, like Fedora 31 Workstation, on their laptop, or
> Fedora 32 IoT edition on their Raspberry Pi, or a minimalistic Fedora
> for Fedora server.
> Basically anyone who needs Fedora to solve their own problems, which
> are not related to development of the distribution.
>
> Fedora Rawhide is not a user-facing branch in Fedora, because it's
> purpose is to develop Fedora, not something else.
> Same with ELN. It is not a Fedora Server edition, there is no reason
> to ever use it on a server. It is a rebuild of Fedora Rawhide, and
> it's purpose is the development of Fedora, and help others to
> contribute to that development.
>
> So it is facing contributors, not users.
>
> Different types of contributors though.
I consider rawhide users our users and I assume many other do consider them our
users as well. I consider upstream projects who run their CI on Fedora our
users. You are not incorrect that this is a terminology issue, however I think
this is a different mindset issue. Please do consider rawhide users and upstream
projects our users when designing things.
For example, there is a point to run an ELN on a server - e.g. to run a buildbot
worker on it for some CI tests.
>> I'd rather discuss this here and only come to FPC for approval of new
guidelines
>> when ready. The FPC members who are likely to discuss this are already
>> discussing this here. Why spitting the discussion into two places?
>
> Sorry, my understanding of why we need RelEng and FPC tickets was
> completely the opposite. Mailing list discussion about the Change is
> generic, and gets side-tracked to one side or the other and digging
> through it to get the pieces which are relevant to FPC topic is
> harder. While ticket has a fixed topic, discussion associated to it
> and the outcome of that discussion. I don't see how you can prevent
> people from discussing the topic in the ticket and move it to the
> mailing list.
>
> If you see FPC ticket as a "request to vote" only, why do we need it
> then? Can't we just invite FPC representative to vote on a FESCo
> ticket?
We could, but there are existing workflows based on the committees using their
own ticketing tracker to do the voting.
>> This is all nice only as long as you prefer conditionals over branching. For a
>> Fedora maintainer who doesn't, this is just "unnecessary cruft" in
the spec file.
>
> It is not really about personal preferences. These are two different
> approaches with different purposes, different results and different
> requirements.
> There are consequences on choosing one other the other.
Yes. That's what I've been saying since the beginning. Choosing %ifs over
branches has consequences. Choosing branches over %ifs has consequences. Not
being able to choose has consequences.
> Branching means forking Fedora Rawhide into something else. Which
> eventually will lead to new downstream tree which will ignore the rest
> of Fedora and just use the fork instead. It can be done, but I think
> it will damage Fedora as a project.
(snip)
Not if we do automation that constantly keeps them in sync. Is that
hard? Most
likely. But it doesn't put additional burden to the community maintainers.
I don't even think this needs to be hard.
1. For packages where no modifications are necessary, just merge
master into eln whenever master changes
2. For packages where modifications are necessary, either
- push changes into master, when those changes are acceptable
(particularly small changes), and proceed with case 1.
- keep "bigger" changes unacceptable for master/rawhide in eln and
rebase those on rawhide whenever master changes
Given that the number of packages that need such "big" modifications
are expected to be small, this approach should scale very well.
> >>> Yes, there is a risk that it won't work. And we have a very clean
> >>> contingency plan for it: we shutdown the whole thing.
> >>> It will be unfortunate, but it is an option.
> >>
> >> What is to stop us saying "stop acting like we can stop doing this now
and start
> >> over at this point" when we realize this is hurting the Fedora
community, but we
> >> need to ship next RHEL? (Sspeaking from experience. Things like this were
said.)
> >
> > I don't understand your question. Nothing ever stops anyone from
> > saying anything. But it is FESCo and Fedora Council who have the
> > decision power.
>
> Correct. I just want to avoid us repeating the same mistakes over and over
> again. I am afraid this change has a potential to alienate community
> contributors and I would like us to consider the problem before we start doing
> it and before RHEL is depending on it and before everybody will just repeat "we
> cannot change this, because we have this in RHEL already".
>
> So can we please not rush this and try to figure things ad hoc, but dedicate
> some more time to planning things? Especially I'd appreciate if the "how do
we
> make this work without %if spaghetti everywhere" aspect is considered.
>
> > But if you look at the change you'll see that it has no blocking
> > features whatsoever. We are not changing how Fedora is built and how
> > it is released.
>
> 1) This changes how Fedora is maintained.
> 2) This has a potential of changing how RHEL is bootstrapped, making it
> essential and hard to cancel.
>
> > So if you have a worry that this change is hard to cancel, please
> > explain why you think so.
>
> See the two sections above this one.
>
>
>
> >>>>> == User Experience ==
> >>>>>
> >>>>> There is no user-facing part in this change. No ELN artifacts
are
> >>>>> going to be shipped to the end-user.
> >>>>
> >>>> As a packager debugging a problem in ELN, how do I consume it?
> >>>
> >>> It is described in "How to Test" section.
> >>
> >> Those sections contradict each other in that case.
> >
> > As I explained before users and contributors are different. ELN
> > packages are not to be used at home. These are developer tools.
>
> I use developer tools at home. Plenty of Fedora users are developers. Plenty of
> Fedora developers are Fedora users. I don't understand your terminology at all.
> Saying "we are not going to ship this to users" sounds alienating
>
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> 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@lists.fedoraproject.org
9:59 a.m.
On 25. 03. 20 15:50, Fabio Valentini wrote:
>> Branching means forking Fedora Rawhide into something else.
Which
>> eventually will lead to new downstream tree which will ignore the rest
>> of Fedora and just use the fork instead. It can be done, but I think
>> it will damage Fedora as a project.
(snip)
> Not if we do automation that constantly keeps them in sync. Is that hard? Most
> likely. But it doesn't put additional burden to the community maintainers.
I don't even think this needs to be hard.
1. For packages where no modifications are necessary, just merge
master into eln whenever master changes
2. For packages where modifications are necessary, either
- push changes into master, when those changes are acceptable
(particularly small changes), and proceed with case 1.
- keep "bigger" changes unacceptable for master/rawhide in eln and
rebase those on rawhide whenever master changes
Given that the number of packages that need such "big" modifications
are expected to be small, this approach should scale very well.
The branch can even be optional. For packages that don't need modifications (or
prefer %if conditionals), ELN could build directly from master.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
10:07 a.m.
New subject: Fedora 33 System-Wide Change proposal: ELN Buildroot and
Compose
On Wed, 25 Mar 2020 15:59:55 +0100
Miro Hrončok <mhroncok(a)redhat.com> wrote:
On 25. 03. 20 15:50, Fabio Valentini wrote:
>>> Branching means forking Fedora Rawhide into something else. Which
>>> eventually will lead to new downstream tree which will ignore the
>>> rest of Fedora and just use the fork instead. It can be done, but
>>> I think it will damage Fedora as a project.
> (snip)
>
>> Not if we do automation that constantly keeps them in sync. Is
>> that hard? Most likely. But it doesn't put additional burden to
>> the community maintainers.
> I don't even think this needs to be hard.
>
> 1. For packages where no modifications are necessary, just merge
> master into eln whenever master changes
> 2. For packages where modifications are necessary, either
> - push changes into master, when those changes are acceptable
> (particularly small changes), and proceed with case 1.
> - keep "bigger" changes unacceptable for master/rawhide in eln
> and rebase those on rawhide whenever master changes
>
> Given that the number of packages that need such "big" modifications
> are expected to be small, this approach should scale very well.
The branch can even be optional. For packages that don't need
modifications (or prefer %if conditionals), ELN could build directly
from master.
and when a branch will be required, it will come with an assigned
maintainer, so the community maintainer can still focus on regular
Fedora branches only.
Dan
11:33 a.m.
On Wed, Mar 25, 2020 at 3:10 PM Miro Hrončok <mhroncok(a)redhat.com> wrote:
On 25. 03. 20 14:06, Aleksandra Fedorova wrote:
>>> By contributing to Fedora Rawhide sources and consuming them as ELN
>>> repositories for testing purposes.
>>
>> The change proposal literally says "There is no user-facing part in this
change.
>> No ELN artifacts are going to be shipped to the end-user."
>>
>> As a contributor, how do I consume the content if I cannot consume the content?
>> As I understand it, the "end-user" and "user-facing" terms
must have different
>> meanings in this context, right? What is this meaning?
>
> Looks like terminology issue. For me user is a person who uses
> released Fedora, like Fedora 31 Workstation, on their laptop, or
> Fedora 32 IoT edition on their Raspberry Pi, or a minimalistic Fedora
> for Fedora server.
> Basically anyone who needs Fedora to solve their own problems, which
> are not related to development of the distribution.
>
> Fedora Rawhide is not a user-facing branch in Fedora, because it's
> purpose is to develop Fedora, not something else.
> Same with ELN. It is not a Fedora Server edition, there is no reason
> to ever use it on a server. It is a rebuild of Fedora Rawhide, and
> it's purpose is the development of Fedora, and help others to
> contribute to that development.
>
> So it is facing contributors, not users.
>
> Different types of contributors though.
I consider rawhide users our users and I assume many other do consider them our
users as well. I consider upstream projects who run their CI on Fedora our
users. You are not incorrect that this is a terminology issue, however I think
this is a different mindset issue. Please do consider rawhide users and upstream
projects our users when designing things.
You are misinterpreting what I said. And it is a terminology issue.
You somehow assume that if we call people users - we care about them,
and if we call them contributors, they are _just_ contributors, so we
don't.
This is not what I have said, and please don't put such a mindset on me.
The difference between users and contributors is not how you treat
them, but a level of knowledge about Fedora internals which is
expected from them.
Using rawhide on your workstation is possible, but you need to learn
first what rawhide is and you need to make an educated choice to use
it.
Same with ELN.
It does not have impact on Fedora Workstation user experience. My
grandma, who is Fedora user since Fedora 8, will not see this change
on her laptop and she doesn't need to be informed about it.
For example, there is a point to run an ELN on a server - e.g. to run
a buildbot
worker on it for some CI tests.
I think this is not the server Neil meant.
My point was to highlight that ELN is not a "stable edition" like
Fedora Server. ELN is Rawhide, its quality is no better than Rawhide
quality, its stability is Rawhide stability, its target audience is
Rawhide audience.
>> I'd rather discuss this here and only come to FPC for approval of new
guidelines
>> when ready. The FPC members who are likely to discuss this are already
>> discussing this here. Why spitting the discussion into two places?
>
> Sorry, my understanding of why we need RelEng and FPC tickets was
> completely the opposite. Mailing list discussion about the Change is
> generic, and gets side-tracked to one side or the other and digging
> through it to get the pieces which are relevant to FPC topic is
> harder. While ticket has a fixed topic, discussion associated to it
> and the outcome of that discussion. I don't see how you can prevent
> people from discussing the topic in the ticket and move it to the
> mailing list.
>
> If you see FPC ticket as a "request to vote" only, why do we need it
> then? Can't we just invite FPC representative to vote on a FESCo
> ticket?
We could, but there are existing workflows based on the committees using their
own ticketing tracker to do the voting.
Ok.
>> This is all nice only as long as you prefer conditionals over branching. For a
>> Fedora maintainer who doesn't, this is just "unnecessary cruft" in
the spec file.
>
> It is not really about personal preferences. These are two different
> approaches with different purposes, different results and different
> requirements.
> There are consequences on choosing one other the other.
Yes. That's what I've been saying since the beginning. Choosing %ifs over
branches has consequences. Choosing branches over %ifs has consequences. Not
being able to choose has consequences.
> Branching means forking Fedora Rawhide into something else. Which
> eventually will lead to new downstream tree which will ignore the rest
> of Fedora and just use the fork instead. It can be done, but I think
> it will damage Fedora as a project.
Not if we do automation that constantly keeps them in sync. Is that hard? Most
likely. But it doesn't put additional burden to the community maintainers.
It removes community maintainer from the conversation about what
downstream is doing. While we want to give community member a voice in
that conversation.
It also cuts community maintainer from the help of downstream, as
downstream will be developing a fork.
>>> Yes, there is a risk that it won't work. And we have
a very clean
>>> contingency plan for it: we shutdown the whole thing.
>>> It will be unfortunate, but it is an option.
>>
>> What is to stop us saying "stop acting like we can stop doing this now and
start
>> over at this point" when we realize this is hurting the Fedora community,
but we
>> need to ship next RHEL? (Sspeaking from experience. Things like this were
said.)
>
> I don't understand your question. Nothing ever stops anyone from
> saying anything. But it is FESCo and Fedora Council who have the
> decision power.
Correct. I just want to avoid us repeating the same mistakes over and over
again. I am afraid this change has a potential to alienate community
contributors and I would like us to consider the problem before we start doing
it and before RHEL is depending on it and before everybody will just repeat "we
cannot change this, because we have this in RHEL already".
So can we please not rush this and try to figure things ad hoc, but dedicate
some more time to planning things? Especially I'd appreciate if the "how do we
make this work without %if spaghetti everywhere" aspect is considered.
We can not fully implement it in the planning phase. It is not a
generic question with generic answer. It needs to be decided on a
package level. And decision maybe different for each package and for
each case.
We can come up with guidelines, for example:
1) Try to find a way to resolve the issue without any conditionals first.
There should be a reason why package X needs a dependency Y in Fedora
and there should be a reason why it is a required dependency and not a
recommended one. So why in that case downstream wants it differently?
The first approach is just to talk through it. I can assume cases
where downstream adds a dependency, as well as Fedora package removing
them.
Note that bloated dependency trees is a common problem for all binary
distributions, it is not an "EL-thing" and we can work on that
together.
Nicolas has pointed out to another reason why we would get
EL-conditionals: the outdated rpm stack in RHEL. But we don't have
this problem with ELN, as we are building Rawhide, and rpm stack is
going to be the Rawhide rpm stack as well.
2) Minimize and isolate the conditional, and track the reason.
As ELN SIG we need to have a place where we collect known reasons for
such conditionals. The overall goal is to reduce this set, not to grow
indefinitely. As Stephen said we expect it to be about couple of
hundred packages. We will be able to track each one of them. (We have
rpminspect to run package diffs for us).
3) In complex cases - bring it to community and FESCo.
We don't know what those complex cases might be, one of the goals is
to find them. So we keep it as an option to bring individual case to a
wider audience. To ask for help and to decide on it.
> But if you look at the change you'll see that it has no
blocking
> features whatsoever. We are not changing how Fedora is built and how
> it is released.
1) This changes how Fedora is maintained.
This is not disruptive. If we stop building ELN compose at certain
point we don't lose anything for Fedora Rawhide.
2) This has a potential of changing how RHEL is bootstrapped, making
it
essential and hard to cancel.
If the whole concept doesn't work, it won't become essential to RHEL.
Although this worries me, it is not the problem with canceling the
change, it is a problem with us (as Fedora) not having it.
> So if you have a worry that this change is hard to cancel,
please
> explain why you think so.
See the two sections above this one.
>>>>> == User Experience ==
>>>>>
>>>>> There is no user-facing part in this change. No ELN artifacts are
>>>>> going to be shipped to the end-user.
>>>>
>>>> As a packager debugging a problem in ELN, how do I consume it?
>>>
>>> It is described in "How to Test" section.
>>
>> Those sections contradict each other in that case.
>
> As I explained before users and contributors are different. ELN
> packages are not to be used at home. These are developer tools.
I use developer tools at home. Plenty of Fedora users are developers. Plenty of
Fedora developers are Fedora users. I don't understand your terminology at all.
Saying "we are not going to ship this to users" sounds alienating
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
--
Aleksandra Fedorova
bookwar
12:06 p.m.
Dne 25. 03. 20 v 17:33 Aleksandra Fedorova napsal(a):
On Wed, Mar 25, 2020 at 3:10 PM Miro Hrončok
<mhroncok(a)redhat.com> wrote:
> On 25. 03. 20 14:06, Aleksandra Fedorova wrote:
>>>> By contributing to Fedora Rawhide sources and consuming them as ELN
>>>> repositories for testing purposes.
>>> The change proposal literally says "There is no user-facing part in this
change.
>>> No ELN artifacts are going to be shipped to the end-user."
>>>
>>> As a contributor, how do I consume the content if I cannot consume the
content?
>>> As I understand it, the "end-user" and "user-facing"
terms must have different
>>> meanings in this context, right? What is this meaning?
>> Looks like terminology issue. For me user is a person who uses
>> released Fedora, like Fedora 31 Workstation, on their laptop, or
>> Fedora 32 IoT edition on their Raspberry Pi, or a minimalistic Fedora
>> for Fedora server.
>> Basically anyone who needs Fedora to solve their own problems, which
>> are not related to development of the distribution.
>>
>> Fedora Rawhide is not a user-facing branch in Fedora, because it's
>> purpose is to develop Fedora, not something else.
>> Same with ELN. It is not a Fedora Server edition, there is no reason
>> to ever use it on a server. It is a rebuild of Fedora Rawhide, and
>> it's purpose is the development of Fedora, and help others to
>> contribute to that development.
>>
>> So it is facing contributors, not users.
>>
>> Different types of contributors though.
> I consider rawhide users our users and I assume many other do consider them our
> users as well. I consider upstream projects who run their CI on Fedora our
> users. You are not incorrect that this is a terminology issue, however I think
> this is a different mindset issue. Please do consider rawhide users and upstream
> projects our users when designing things.
You are misinterpreting what I said. And it is a terminology issue.
You somehow assume that if we call people users - we care about them,
and if we call them contributors, they are _just_ contributors, so we
don't.
This is not what I have said, and please don't put such a mindset on me.
The difference between users and contributors is not how you treat
them, but a level of knowledge about Fedora internals which is
expected from them.
Using rawhide on your workstation is possible, but you need to learn
first what rawhide is and you need to make an educated choice to use
it.
Same with ELN.
It does not have impact on Fedora Workstation user experience. My
grandma, who is Fedora user since Fedora 8, will not see this change
on her laptop and she doesn't need to be informed about it.
> For example, there is a point to run an ELN on a server - e.g. to run a buildbot
> worker on it for some CI tests.
I think this is not the server Neil meant.
My point was to highlight that ELN is not a "stable edition" like
Fedora Server. ELN is Rawhide, its quality is no better than Rawhide
quality, its stability is Rawhide stability, its target audience is
Rawhide audience.
>>> I'd rather discuss this here and only come to FPC for approval of new
guidelines
>>> when ready. The FPC members who are likely to discuss this are already
>>> discussing this here. Why spitting the discussion into two places?
>> Sorry, my understanding of why we need RelEng and FPC tickets was
>> completely the opposite. Mailing list discussion about the Change is
>> generic, and gets side-tracked to one side or the other and digging
>> through it to get the pieces which are relevant to FPC topic is
>> harder. While ticket has a fixed topic, discussion associated to it
>> and the outcome of that discussion. I don't see how you can prevent
>> people from discussing the topic in the ticket and move it to the
>> mailing list.
>>
>> If you see FPC ticket as a "request to vote" only, why do we need it
>> then? Can't we just invite FPC representative to vote on a FESCo
>> ticket?
> We could, but there are existing workflows based on the committees using their
> own ticketing tracker to do the voting.
Ok.
>>> This is all nice only as long as you prefer conditionals over branching. For
a
>>> Fedora maintainer who doesn't, this is just "unnecessary cruft"
in the spec file.
>> It is not really about personal preferences. These are two different
>> approaches with different purposes, different results and different
>> requirements.
>> There are consequences on choosing one other the other.
> Yes. That's what I've been saying since the beginning. Choosing %ifs over
> branches has consequences. Choosing branches over %ifs has consequences. Not
> being able to choose has consequences.
>
>> Branching means forking Fedora Rawhide into something else. Which
>> eventually will lead to new downstream tree which will ignore the rest
>> of Fedora and just use the fork instead. It can be done, but I think
>> it will damage Fedora as a project.
> Not if we do automation that constantly keeps them in sync. Is that hard? Most
> likely. But it doesn't put additional burden to the community maintainers.
It removes community maintainer from the conversation about what
downstream is doing. While we want to give community member a voice in
that conversation.
It also cuts community maintainer from the help of downstream, as
downstream will be developing a fork.
I don't understand why the focus on the worst case scenario.
>>>> Yes, there is a risk that it won't work. And we have a very clean
>>>> contingency plan for it: we shutdown the whole thing.
>>>> It will be unfortunate, but it is an option.
>>> What is to stop us saying "stop acting like we can stop doing this now
and start
>>> over at this point" when we realize this is hurting the Fedora
community, but we
>>> need to ship next RHEL? (Sspeaking from experience. Things like this were
said.)
>> I don't understand your question. Nothing ever stops anyone from
>> saying anything. But it is FESCo and Fedora Council who have the
>> decision power.
> Correct. I just want to avoid us repeating the same mistakes over and over
> again. I am afraid this change has a potential to alienate community
> contributors and I would like us to consider the problem before we start doing
> it and before RHEL is depending on it and before everybody will just repeat "we
> cannot change this, because we have this in RHEL already".
>
> So can we please not rush this and try to figure things ad hoc, but dedicate
> some more time to planning things? Especially I'd appreciate if the "how do
we
> make this work without %if spaghetti everywhere" aspect is considered.
We can not fully implement it in the planning phase. It is not a
generic question with generic answer. It needs to be decided on a
package level. And decision maybe different for each package and for
each case.
We can come up with guidelines, for example:
1) Try to find a way to resolve the issue without any conditionals first.
There should be a reason why package X needs a dependency Y in Fedora
and there should be a reason why it is a required dependency and not a
recommended one. So why in that case downstream wants it differently?
The first approach is just to talk through it. I can assume cases
where downstream adds a dependency, as well as Fedora package removing
them.
Note that bloated dependency trees is a common problem for all binary
distributions, it is not an "EL-thing" and we can work on that
together.
Nicolas has pointed out to another reason why we would get
EL-conditionals: the outdated rpm stack in RHEL. But we don't have
this problem with ELN, as we are building Rawhide, and rpm stack is
going to be the Rawhide rpm stack as well.
2) Minimize and isolate the conditional, and track the reason.
As ELN SIG we need to have a place where we collect known reasons for
such conditionals. The overall goal is to reduce this set, not to grow
indefinitely. As Stephen said we expect it to be about couple of
hundred packages. We will be able to track each one of them. (We have
rpminspect to run package diffs for us).
3) In complex cases - bring it to community and FESCo.
We don't know what those complex cases might be, one of the goals is
to find them. So we keep it as an option to bring individual case to a
wider audience. To ask for help and to decide on it.
It seems there are missing real life examples of what we sometimes do in
RHEL, so please see attached patch. This patch is coming from RHEL
version of the espeak-ng. Now somebody tell me what it does for what
purpose and which scenario from the above three should be applied here.
Vít
12:18 p.m.
Dne 25. 03. 20 v 18:06 Vít Ondruch napsal(a):
Dne 25. 03. 20 v 17:33 Aleksandra Fedorova napsal(a):
> On Wed, Mar 25, 2020 at 3:10 PM Miro Hrončok <mhroncok(a)redhat.com> wrote:
>> On 25. 03. 20 14:06, Aleksandra Fedorova wrote:
>>>>> By contributing to Fedora Rawhide sources and consuming them as ELN
>>>>> repositories for testing purposes.
>>>> The change proposal literally says "There is no user-facing part in
this change.
>>>> No ELN artifacts are going to be shipped to the end-user."
>>>>
>>>> As a contributor, how do I consume the content if I cannot consume the
content?
>>>> As I understand it, the "end-user" and "user-facing"
terms must have different
>>>> meanings in this context, right? What is this meaning?
>>> Looks like terminology issue. For me user is a person who uses
>>> released Fedora, like Fedora 31 Workstation, on their laptop, or
>>> Fedora 32 IoT edition on their Raspberry Pi, or a minimalistic Fedora
>>> for Fedora server.
>>> Basically anyone who needs Fedora to solve their own problems, which
>>> are not related to development of the distribution.
>>>
>>> Fedora Rawhide is not a user-facing branch in Fedora, because it's
>>> purpose is to develop Fedora, not something else.
>>> Same with ELN. It is not a Fedora Server edition, there is no reason
>>> to ever use it on a server. It is a rebuild of Fedora Rawhide, and
>>> it's purpose is the development of Fedora, and help others to
>>> contribute to that development.
>>>
>>> So it is facing contributors, not users.
>>>
>>> Different types of contributors though.
>> I consider rawhide users our users and I assume many other do consider them our
>> users as well. I consider upstream projects who run their CI on Fedora our
>> users. You are not incorrect that this is a terminology issue, however I think
>> this is a different mindset issue. Please do consider rawhide users and upstream
>> projects our users when designing things.
> You are misinterpreting what I said. And it is a terminology issue.
>
> You somehow assume that if we call people users - we care about them,
> and if we call them contributors, they are _just_ contributors, so we
> don't.
> This is not what I have said, and please don't put such a mindset on me.
>
> The difference between users and contributors is not how you treat
> them, but a level of knowledge about Fedora internals which is
> expected from them.
> Using rawhide on your workstation is possible, but you need to learn
> first what rawhide is and you need to make an educated choice to use
> it.
> Same with ELN.
>
> It does not have impact on Fedora Workstation user experience. My
> grandma, who is Fedora user since Fedora 8, will not see this change
> on her laptop and she doesn't need to be informed about it.
>
>> For example, there is a point to run an ELN on a server - e.g. to run a buildbot
>> worker on it for some CI tests.
> I think this is not the server Neil meant.
> My point was to highlight that ELN is not a "stable edition" like
> Fedora Server. ELN is Rawhide, its quality is no better than Rawhide
> quality, its stability is Rawhide stability, its target audience is
> Rawhide audience.
>
>>>> I'd rather discuss this here and only come to FPC for approval of new
guidelines
>>>> when ready. The FPC members who are likely to discuss this are already
>>>> discussing this here. Why spitting the discussion into two places?
>>> Sorry, my understanding of why we need RelEng and FPC tickets was
>>> completely the opposite. Mailing list discussion about the Change is
>>> generic, and gets side-tracked to one side or the other and digging
>>> through it to get the pieces which are relevant to FPC topic is
>>> harder. While ticket has a fixed topic, discussion associated to it
>>> and the outcome of that discussion. I don't see how you can prevent
>>> people from discussing the topic in the ticket and move it to the
>>> mailing list.
>>>
>>> If you see FPC ticket as a "request to vote" only, why do we need
it
>>> then? Can't we just invite FPC representative to vote on a FESCo
>>> ticket?
>> We could, but there are existing workflows based on the committees using their
>> own ticketing tracker to do the voting.
> Ok.
>
>>>> This is all nice only as long as you prefer conditionals over branching.
For a
>>>> Fedora maintainer who doesn't, this is just "unnecessary
cruft" in the spec file.
>>> It is not really about personal preferences. These are two different
>>> approaches with different purposes, different results and different
>>> requirements.
>>> There are consequences on choosing one other the other.
>> Yes. That's what I've been saying since the beginning. Choosing %ifs
over
>> branches has consequences. Choosing branches over %ifs has consequences. Not
>> being able to choose has consequences.
>>
>>> Branching means forking Fedora Rawhide into something else. Which
>>> eventually will lead to new downstream tree which will ignore the rest
>>> of Fedora and just use the fork instead. It can be done, but I think
>>> it will damage Fedora as a project.
>> Not if we do automation that constantly keeps them in sync. Is that hard? Most
>> likely. But it doesn't put additional burden to the community maintainers.
> It removes community maintainer from the conversation about what
> downstream is doing. While we want to give community member a voice in
> that conversation.
> It also cuts community maintainer from the help of downstream, as
> downstream will be developing a fork.
I don't understand why the focus on the worst case scenario.
>>>>> Yes, there is a risk that it won't work. And we have a very
clean
>>>>> contingency plan for it: we shutdown the whole thing.
>>>>> It will be unfortunate, but it is an option.
>>>> What is to stop us saying "stop acting like we can stop doing this
now and start
>>>> over at this point" when we realize this is hurting the Fedora
community, but we
>>>> need to ship next RHEL? (Sspeaking from experience. Things like this were
said.)
>>> I don't understand your question. Nothing ever stops anyone from
>>> saying anything. But it is FESCo and Fedora Council who have the
>>> decision power.
>> Correct. I just want to avoid us repeating the same mistakes over and over
>> again. I am afraid this change has a potential to alienate community
>> contributors and I would like us to consider the problem before we start doing
>> it and before RHEL is depending on it and before everybody will just repeat
"we
>> cannot change this, because we have this in RHEL already".
>>
>> So can we please not rush this and try to figure things ad hoc, but dedicate
>> some more time to planning things? Especially I'd appreciate if the "how
do we
>> make this work without %if spaghetti everywhere" aspect is considered.
> We can not fully implement it in the planning phase. It is not a
> generic question with generic answer. It needs to be decided on a
> package level. And decision maybe different for each package and for
> each case.
>
> We can come up with guidelines, for example:
>
> 1) Try to find a way to resolve the issue without any conditionals first.
>
> There should be a reason why package X needs a dependency Y in Fedora
> and there should be a reason why it is a required dependency and not a
> recommended one. So why in that case downstream wants it differently?
> The first approach is just to talk through it. I can assume cases
> where downstream adds a dependency, as well as Fedora package removing
> them.
>
> Note that bloated dependency trees is a common problem for all binary
> distributions, it is not an "EL-thing" and we can work on that
> together.
>
> Nicolas has pointed out to another reason why we would get
> EL-conditionals: the outdated rpm stack in RHEL. But we don't have
> this problem with ELN, as we are building Rawhide, and rpm stack is
> going to be the Rawhide rpm stack as well.
>
> 2) Minimize and isolate the conditional, and track the reason.
>
> As ELN SIG we need to have a place where we collect known reasons for
> such conditionals. The overall goal is to reduce this set, not to grow
> indefinitely. As Stephen said we expect it to be about couple of
> hundred packages. We will be able to track each one of them. (We have
> rpminspect to run package diffs for us).
>
> 3) In complex cases - bring it to community and FESCo.
>
> We don't know what those complex cases might be, one of the goals is
> to find them. So we keep it as an option to bring individual case to a
> wider audience. To ask for help and to decide on it.
>
It seems there are missing real life examples of what we sometimes do in
RHEL, so please see attached patch. This patch is coming from RHEL
version of the espeak-ng. Now somebody tell me what it does for what
purpose and which scenario from the above three should be applied here.
Vít
And here is another example for the curious.
Vít
2:22 p.m.
On Wed, Mar 25, 2020, at 1:18 PM, Vít Ondruch wrote:
Dne 25. 03. 20 v 18:06 Vít Ondruch napsal(a):
> Dne 25. 03. 20 v 17:33 Aleksandra Fedorova napsal(a):
>>
[snip]
>> We can come up with guidelines, for example:
>>
>> 1) Try to find a way to resolve the issue without any conditionals first.
>>
>> There should be a reason why package X needs a dependency Y in Fedora
>> and there should be a reason why it is a required dependency and not a
>> recommended one. So why in that case downstream wants it differently?
>> The first approach is just to talk through it. I can assume cases
>> where downstream adds a dependency, as well as Fedora package removing
>> them.
>>
>> Note that bloated dependency trees is a common problem for all binary
>> distributions, it is not an "EL-thing" and we can work on that
>> together.
>>
>> Nicolas has pointed out to another reason why we would get
>> EL-conditionals: the outdated rpm stack in RHEL. But we don't have
>> this problem with ELN, as we are building Rawhide, and rpm stack is
>> going to be the Rawhide rpm stack as well.
>>
>> 2) Minimize and isolate the conditional, and track the reason.
>>
>> As ELN SIG we need to have a place where we collect known reasons for
>> such conditionals. The overall goal is to reduce this set, not to grow
>> indefinitely. As Stephen said we expect it to be about couple of
>> hundred packages. We will be able to track each one of them. (We have
>> rpminspect to run package diffs for us).
>>
>> 3) In complex cases - bring it to community and FESCo.
>>
>> We don't know what those complex cases might be, one of the goals is
>> to find them. So we keep it as an option to bring individual case to a
>> wider audience. To ask for help and to decide on it.
>>
> It seems there are missing real life examples of what we sometimes do in
> RHEL, so please see attached patch. This patch is coming from RHEL
> version of the espeak-ng. Now somebody tell me what it does for what
> purpose and which scenario from the above three should be applied here.
>
>
> Vít
>
And here is another example for the curious.
Both of these examples have to do with docs generation and trying to reduce dependencies
for that process. "Process the man page using kramdown and remove the ronn
dependency."
(So you don't have to open the attachments yourself.)
V/r,
James Cassell
4:33 a.m.
Dne 25. 03. 20 v 20:22 James Cassell napsal(a):
On Wed, Mar 25, 2020, at 1:18 PM, Vít Ondruch wrote:
> Dne 25. 03. 20 v 18:06 Vít Ondruch napsal(a):
>> Dne 25. 03. 20 v 17:33 Aleksandra Fedorova napsal(a):
[snip]
>>> We can come up with guidelines, for example:
>>>
>>> 1) Try to find a way to resolve the issue without any conditionals first.
>>>
>>> There should be a reason why package X needs a dependency Y in Fedora
>>> and there should be a reason why it is a required dependency and not a
>>> recommended one. So why in that case downstream wants it differently?
>>> The first approach is just to talk through it. I can assume cases
>>> where downstream adds a dependency, as well as Fedora package removing
>>> them.
>>>
>>> Note that bloated dependency trees is a common problem for all binary
>>> distributions, it is not an "EL-thing" and we can work on that
>>> together.
>>>
>>> Nicolas has pointed out to another reason why we would get
>>> EL-conditionals: the outdated rpm stack in RHEL. But we don't have
>>> this problem with ELN, as we are building Rawhide, and rpm stack is
>>> going to be the Rawhide rpm stack as well.
>>>
>>> 2) Minimize and isolate the conditional, and track the reason.
>>>
>>> As ELN SIG we need to have a place where we collect known reasons for
>>> such conditionals. The overall goal is to reduce this set, not to grow
>>> indefinitely. As Stephen said we expect it to be about couple of
>>> hundred packages. We will be able to track each one of them. (We have
>>> rpminspect to run package diffs for us).
>>>
>>> 3) In complex cases - bring it to community and FESCo.
>>>
>>> We don't know what those complex cases might be, one of the goals is
>>> to find them. So we keep it as an option to bring individual case to a
>>> wider audience. To ask for help and to decide on it.
>>>
>> It seems there are missing real life examples of what we sometimes do in
>> RHEL, so please see attached patch. This patch is coming from RHEL
>> version of the espeak-ng. Now somebody tell me what it does for what
>> purpose and which scenario from the above three should be applied here.
>>
>>
>> Vít
>>
> And here is another example for the curious.
>
Both of these examples have to do with docs generation and trying to reduce dependencies
for that process. "Process the man page using kramdown and remove the ronn
dependency."
The point is that these types of changes are not upstreamable. And the
conditions would also be awful. Having these changes in separate branch
would be much preferable IMO, because honestly, I would like every
Fedora maintainer save from this cruft not because I would like to hide
something, but for their own sanity.
Vít
6:39 a.m.
On Thu, Mar 26, 2020 at 10:34 AM Vít Ondruch <vondruch(a)redhat.com> wrote:
Dne 25. 03. 20 v 20:22 James Cassell napsal(a):
> On Wed, Mar 25, 2020, at 1:18 PM, Vít Ondruch wrote:
>> Dne 25. 03. 20 v 18:06 Vít Ondruch napsal(a):
>>> Dne 25. 03. 20 v 17:33 Aleksandra Fedorova napsal(a):
> [snip]
>>>> We can come up with guidelines, for example:
>>>>
>>>> 1) Try to find a way to resolve the issue without any conditionals
first.
>>>>
>>>> There should be a reason why package X needs a dependency Y in Fedora
>>>> and there should be a reason why it is a required dependency and not a
>>>> recommended one. So why in that case downstream wants it differently?
>>>> The first approach is just to talk through it. I can assume cases
>>>> where downstream adds a dependency, as well as Fedora package removing
>>>> them.
>>>>
>>>> Note that bloated dependency trees is a common problem for all binary
>>>> distributions, it is not an "EL-thing" and we can work on
that
>>>> together.
>>>>
>>>> Nicolas has pointed out to another reason why we would get
>>>> EL-conditionals: the outdated rpm stack in RHEL. But we don't have
>>>> this problem with ELN, as we are building Rawhide, and rpm stack is
>>>> going to be the Rawhide rpm stack as well.
>>>>
>>>> 2) Minimize and isolate the conditional, and track the reason.
>>>>
>>>> As ELN SIG we need to have a place where we collect known reasons for
>>>> such conditionals. The overall goal is to reduce this set, not to grow
>>>> indefinitely. As Stephen said we expect it to be about couple of
>>>> hundred packages. We will be able to track each one of them. (We have
>>>> rpminspect to run package diffs for us).
>>>>
>>>> 3) In complex cases - bring it to community and FESCo.
>>>>
>>>> We don't know what those complex cases might be, one of the goals
is
>>>> to find them. So we keep it as an option to bring individual case to a
>>>> wider audience. To ask for help and to decide on it.
>>>>
>>> It seems there are missing real life examples of what we sometimes do in
>>> RHEL, so please see attached patch. This patch is coming from RHEL
>>> version of the espeak-ng. Now somebody tell me what it does for what
>>> purpose and which scenario from the above three should be applied here.
>>>
>>>
>>> Vít
>>>
>> And here is another example for the curious.
>>
> Both of these examples have to do with docs generation and trying to reduce
dependencies for that process. "Process the man page using kramdown and remove the
ronn dependency."
The point is that these types of changes are not upstreamable. And the
conditions would also be awful. Having these changes in separate branch
would be much preferable IMO, because honestly, I would like every
Fedora maintainer save from this cruft not because I would like to hide
something, but for their own sanity.
I disagree actually.
Disabling docs to reduce dependencies makes sense. And it is not a
RHEL-only thing.
I had the conversation at the latest Devconf with people who are
aiming to build Linux distribution with a reduced buildroot footprint
for security purposes. So that they can audit the content of the
buildroot, and get to a certain level of certification with it.
I think It can not be done directly in Fedora, but if we add the
flexibility into our builds (with conditionals), then we could
eventually get a new downstream supported by a certain governmental
entity.
What we should avoid is using conditionals randomly and inconsistently.
So let's agree that we are not scattering "%if 0%{?rhel} && (!
0%{?epel})" all over the spec file, but rather define it once at the
top of the spec file:
%if 0%{?rhel} && (! 0%{?epel})
%bcond_with docs
%else
%bcond_without docs
%endif
And use later in a form
...
%if %{with doc}
%package doc
...
%endif
Yes, for now we would go with a "%if 0%{?rhel} && (! 0%{?epel})" in
the header of the affected spec file. But eventually we can think
about adding a USE-flag like functionality to the build process, and
create a global profile for the build system.
This is a very much forward-looking statement, but idea is already
making its round by the dnf team.
So there are some interesting ways how this approach can be developed
further, if we can make it work for a smaller subset first.
--
Aleksandra Fedorova
bookwar
8:39 a.m.
On Thu, Mar 26, 2020 at 7:41 AM Aleksandra Fedorova <alpha(a)bookwar.info> wrote:
On Thu, Mar 26, 2020 at 10:34 AM Vít Ondruch <vondruch(a)redhat.com> wrote:
>
>
> Dne 25. 03. 20 v 20:22 James Cassell napsal(a):
> > On Wed, Mar 25, 2020, at 1:18 PM, Vít Ondruch wrote:
> >> Dne 25. 03. 20 v 18:06 Vít Ondruch napsal(a):
> >>> Dne 25. 03. 20 v 17:33 Aleksandra Fedorova napsal(a):
> > [snip]
> >>>> We can come up with guidelines, for example:
> >>>>
> >>>> 1) Try to find a way to resolve the issue without any conditionals
first.
> >>>>
> >>>> There should be a reason why package X needs a dependency Y in
Fedora
> >>>> and there should be a reason why it is a required dependency and
not a
> >>>> recommended one. So why in that case downstream wants it
differently?
> >>>> The first approach is just to talk through it. I can assume cases
> >>>> where downstream adds a dependency, as well as Fedora package
removing
> >>>> them.
> >>>>
> >>>> Note that bloated dependency trees is a common problem for all
binary
> >>>> distributions, it is not an "EL-thing" and we can work on
that
> >>>> together.
> >>>>
> >>>> Nicolas has pointed out to another reason why we would get
> >>>> EL-conditionals: the outdated rpm stack in RHEL. But we don't
have
> >>>> this problem with ELN, as we are building Rawhide, and rpm stack
is
> >>>> going to be the Rawhide rpm stack as well.
> >>>>
> >>>> 2) Minimize and isolate the conditional, and track the reason.
> >>>>
> >>>> As ELN SIG we need to have a place where we collect known reasons
for
> >>>> such conditionals. The overall goal is to reduce this set, not to
grow
> >>>> indefinitely. As Stephen said we expect it to be about couple of
> >>>> hundred packages. We will be able to track each one of them. (We
have
> >>>> rpminspect to run package diffs for us).
> >>>>
> >>>> 3) In complex cases - bring it to community and FESCo.
> >>>>
> >>>> We don't know what those complex cases might be, one of the
goals is
> >>>> to find them. So we keep it as an option to bring individual case
to a
> >>>> wider audience. To ask for help and to decide on it.
> >>>>
> >>> It seems there are missing real life examples of what we sometimes do
in
> >>> RHEL, so please see attached patch. This patch is coming from RHEL
> >>> version of the espeak-ng. Now somebody tell me what it does for what
> >>> purpose and which scenario from the above three should be applied
here.
> >>>
> >>>
> >>> Vít
> >>>
> >> And here is another example for the curious.
> >>
> > Both of these examples have to do with docs generation and trying to reduce
dependencies for that process. "Process the man page using kramdown and remove the
ronn dependency."
>
>
> The point is that these types of changes are not upstreamable. And the
> conditions would also be awful. Having these changes in separate branch
> would be much preferable IMO, because honestly, I would like every
> Fedora maintainer save from this cruft not because I would like to hide
> something, but for their own sanity.
I disagree actually.
Disabling docs to reduce dependencies makes sense. And it is not a
RHEL-only thing.
I had the conversation at the latest Devconf with people who are
aiming to build Linux distribution with a reduced buildroot footprint
for security purposes. So that they can audit the content of the
buildroot, and get to a certain level of certification with it.
I think It can not be done directly in Fedora, but if we add the
flexibility into our builds (with conditionals), then we could
eventually get a new downstream supported by a certain governmental
entity.
In the context of the governmental usage, I can say from my own
experience that having on-disk documentation is valuable when you have
to work in air-gapped environments. Also, when behaviors are patched,
I hope that the docs are patched too to reflect those changes in
behavior.
That said, it's not my call whether or not RHEL ships documentation
for something, I just hope they do because of how often it gets used
in those scenarios.
What we should avoid is using conditionals randomly and
inconsistently.
So let's agree that we are not scattering "%if 0%{?rhel} && (!
0%{?epel})" all over the spec file, but rather define it once at the
top of the spec file:
%if 0%{?rhel} && (! 0%{?epel})
%bcond_with docs
%else
%bcond_without docs
%endif
And use later in a form
...
%if %{with doc}
%package doc
...
%endif
Yes, for now we would go with a "%if 0%{?rhel} && (! 0%{?epel})" in
the header of the affected spec file. But eventually we can think
about adding a USE-flag like functionality to the build process, and
create a global profile for the build system.
This is a very much forward-looking statement, but idea is already
making its round by the dnf team.
So there are some interesting ways how this approach can be developed
further, if we can make it work for a smaller subset first.
Since we can't build anything that exists in RHEL in EPEL, your
conditional doesn't make sense.
And you might not have known this, but build conditions actually can
be globally flipped. The %bcond_with/%bcond_without macro expands to a
macro that checks for the existence of a macro that flips the behavior
one way or another. Distributions like PLD leverage this property to
use standardized names and inject default settings in their build
targets[1] for everything to use. Since you can define macros in Koji
build tags now, it's possible to implement something like this. And
you've always been able to do this with Mock.
[1]: http://git.pld-linux.org/?p=packages/rpm-build-tools.git;a=blob;f=bconds....
--
真実はいつも一つ！/ Always, there's only one truth!
9:06 a.m.
Hi, Neil,
On Thu, Mar 26, 2020 at 2:41 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
On Thu, Mar 26, 2020 at 7:41 AM Aleksandra Fedorova <alpha(a)bookwar.info> wrote:
>
> On Thu, Mar 26, 2020 at 10:34 AM Vít Ondruch <vondruch(a)redhat.com> wrote:
> >
> >
> > Dne 25. 03. 20 v 20:22 James Cassell napsal(a):
> > > On Wed, Mar 25, 2020, at 1:18 PM, Vít Ondruch wrote:
> > >> Dne 25. 03. 20 v 18:06 Vít Ondruch napsal(a):
> > >>> Dne 25. 03. 20 v 17:33 Aleksandra Fedorova napsal(a):
> > > [snip]
> > >>>> We can come up with guidelines, for example:
> > >>>>
> > >>>> 1) Try to find a way to resolve the issue without any
conditionals first.
> > >>>>
> > >>>> There should be a reason why package X needs a dependency Y in
Fedora
> > >>>> and there should be a reason why it is a required dependency
and not a
> > >>>> recommended one. So why in that case downstream wants it
differently?
> > >>>> The first approach is just to talk through it. I can assume
cases
> > >>>> where downstream adds a dependency, as well as Fedora package
removing
> > >>>> them.
> > >>>>
> > >>>> Note that bloated dependency trees is a common problem for all
binary
> > >>>> distributions, it is not an "EL-thing" and we can
work on that
> > >>>> together.
> > >>>>
> > >>>> Nicolas has pointed out to another reason why we would get
> > >>>> EL-conditionals: the outdated rpm stack in RHEL. But we
don't have
> > >>>> this problem with ELN, as we are building Rawhide, and rpm
stack is
> > >>>> going to be the Rawhide rpm stack as well.
> > >>>>
> > >>>> 2) Minimize and isolate the conditional, and track the
reason.
> > >>>>
> > >>>> As ELN SIG we need to have a place where we collect known
reasons for
> > >>>> such conditionals. The overall goal is to reduce this set, not
to grow
> > >>>> indefinitely. As Stephen said we expect it to be about couple
of
> > >>>> hundred packages. We will be able to track each one of them.
(We have
> > >>>> rpminspect to run package diffs for us).
> > >>>>
> > >>>> 3) In complex cases - bring it to community and FESCo.
> > >>>>
> > >>>> We don't know what those complex cases might be, one of
the goals is
> > >>>> to find them. So we keep it as an option to bring individual
case to a
> > >>>> wider audience. To ask for help and to decide on it.
> > >>>>
> > >>> It seems there are missing real life examples of what we sometimes
do in
> > >>> RHEL, so please see attached patch. This patch is coming from
RHEL
> > >>> version of the espeak-ng. Now somebody tell me what it does for
what
> > >>> purpose and which scenario from the above three should be applied
here.
> > >>>
> > >>>
> > >>> Vít
> > >>>
> > >> And here is another example for the curious.
> > >>
> > > Both of these examples have to do with docs generation and trying to
reduce dependencies for that process. "Process the man page using kramdown and remove
the ronn dependency."
> >
> >
> > The point is that these types of changes are not upstreamable. And the
> > conditions would also be awful. Having these changes in separate branch
> > would be much preferable IMO, because honestly, I would like every
> > Fedora maintainer save from this cruft not because I would like to hide
> > something, but for their own sanity.
>
> I disagree actually.
>
> Disabling docs to reduce dependencies makes sense. And it is not a
> RHEL-only thing.
>
> I had the conversation at the latest Devconf with people who are
> aiming to build Linux distribution with a reduced buildroot footprint
> for security purposes. So that they can audit the content of the
> buildroot, and get to a certain level of certification with it.
> I think It can not be done directly in Fedora, but if we add the
> flexibility into our builds (with conditionals), then we could
> eventually get a new downstream supported by a certain governmental
> entity.
>
In the context of the governmental usage, I can say from my own
experience that having on-disk documentation is valuable when you have
to work in air-gapped environments. Also, when behaviors are patched,
I hope that the docs are patched too to reflect those changes in
behavior.
The problem is not with the docs themselves, but with the tooling
which is used to build them.
Docs are useful, but if upstream decides to use latest JavaScript
framework which has never been packaged or even versioned to build
documentation in 100500 formats, then as downstream(=Fedora) we need
to make amendments to that.
Ideally it needs to be brought all the way upstream, so that it adds
possibility to build docs on different levels. But if it doesn't work
- it is up to us to patch it.
That said, it's not my call whether or not RHEL ships
documentation
for something, I just hope they do because of how often it gets used
in those scenarios.
> What we should avoid is using conditionals randomly and inconsistently.
>
> So let's agree that we are not scattering "%if 0%{?rhel} && (!
> 0%{?epel})" all over the spec file, but rather define it once at the
> top of the spec file:
>
> %if 0%{?rhel} && (! 0%{?epel})
> %bcond_with docs
> %else
> %bcond_without docs
> %endif
>
> And use later in a form
> ...
> %if %{with doc}
> %package doc
> ...
> %endif
>
> Yes, for now we would go with a "%if 0%{?rhel} && (! 0%{?epel})"
in
> the header of the affected spec file. But eventually we can think
> about adding a USE-flag like functionality to the build process, and
> create a global profile for the build system.
> This is a very much forward-looking statement, but idea is already
> making its round by the dnf team.
>
> So there are some interesting ways how this approach can be developed
> further, if we can make it work for a smaller subset first.
>
Since we can't build anything that exists in RHEL in EPEL, your
conditional doesn't make sense.
Please consider it as a concept: disttag conditionals on top to define
the "profile", and then doc/test flags later in the spec file where it
is needed.
And you might not have known this, but build conditions actually can
be globally flipped. The %bcond_with/%bcond_without macro expands to a
macro that checks for the existence of a macro that flips the behavior
one way or another. Distributions like PLD leverage this property to
use standardized names and inject default settings in their build
targets[1] for everything to use. Since you can define macros in Koji
build tags now, it's possible to implement something like this. And
you've always been able to do this with Mock.
It is doable, but it is not just the tooling question. There is a
process, there is a verification system, there are a lot of policy
things which we would need to consider.
ELN is a good opportunity to try it out in a very small, controlled
setup, which we can manage. We have a lot of experience with this
particular type of conditionals already.
[1]:
http://git.pld-linux.org/?p=packages/rpm-build-tools.git;a=blob;f=bconds....
--
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
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@lists.fedoraproject.org
--
Aleksandra Fedorova
bookwar
3:35 a.m.
Dne 26. 03. 20 v 12:39 Aleksandra Fedorova napsal(a):
On Thu, Mar 26, 2020 at 10:34 AM Vít Ondruch
<vondruch(a)redhat.com> wrote:
>
> Dne 25. 03. 20 v 20:22 James Cassell napsal(a):
>> On Wed, Mar 25, 2020, at 1:18 PM, Vít Ondruch wrote:
>>> Dne 25. 03. 20 v 18:06 Vít Ondruch napsal(a):
>>>> Dne 25. 03. 20 v 17:33 Aleksandra Fedorova napsal(a):
>> [snip]
>>>>> We can come up with guidelines, for example:
>>>>>
>>>>> 1) Try to find a way to resolve the issue without any conditionals
first.
>>>>>
>>>>> There should be a reason why package X needs a dependency Y in
Fedora
>>>>> and there should be a reason why it is a required dependency and not
a
>>>>> recommended one. So why in that case downstream wants it
differently?
>>>>> The first approach is just to talk through it. I can assume cases
>>>>> where downstream adds a dependency, as well as Fedora package
removing
>>>>> them.
>>>>>
>>>>> Note that bloated dependency trees is a common problem for all
binary
>>>>> distributions, it is not an "EL-thing" and we can work on
that
>>>>> together.
>>>>>
>>>>> Nicolas has pointed out to another reason why we would get
>>>>> EL-conditionals: the outdated rpm stack in RHEL. But we don't
have
>>>>> this problem with ELN, as we are building Rawhide, and rpm stack is
>>>>> going to be the Rawhide rpm stack as well.
>>>>>
>>>>> 2) Minimize and isolate the conditional, and track the reason.
>>>>>
>>>>> As ELN SIG we need to have a place where we collect known reasons
for
>>>>> such conditionals. The overall goal is to reduce this set, not to
grow
>>>>> indefinitely. As Stephen said we expect it to be about couple of
>>>>> hundred packages. We will be able to track each one of them. (We
have
>>>>> rpminspect to run package diffs for us).
>>>>>
>>>>> 3) In complex cases - bring it to community and FESCo.
>>>>>
>>>>> We don't know what those complex cases might be, one of the goals
is
>>>>> to find them. So we keep it as an option to bring individual case to
a
>>>>> wider audience. To ask for help and to decide on it.
>>>>>
>>>> It seems there are missing real life examples of what we sometimes do in
>>>> RHEL, so please see attached patch. This patch is coming from RHEL
>>>> version of the espeak-ng. Now somebody tell me what it does for what
>>>> purpose and which scenario from the above three should be applied here.
>>>>
>>>>
>>>> Vít
>>>>
>>> And here is another example for the curious.
>>>
>> Both of these examples have to do with docs generation and trying to reduce
dependencies for that process. "Process the man page using kramdown and remove the
ronn dependency."
>
> The point is that these types of changes are not upstreamable. And the
> conditions would also be awful. Having these changes in separate branch
> would be much preferable IMO, because honestly, I would like every
> Fedora maintainer save from this cruft not because I would like to hide
> something, but for their own sanity.
I disagree actually.
Disabling docs to reduce dependencies makes sense. And it is not a
RHEL-only thing.
I am sorry but you have not passed the test. The test question was "Now
somebody tell me what it does for what
purpose and which scenario from the above three should be applied here."
I would really appreciate, if you could pay attention to the two
patches I post and what they do. Including careful analysis why they
were applied and why they were not put into Fedora nor upstreamed.
Hint: They don't disable any documentation.
Thank you.
Vít
P.S. I really thinking if I should write this and if and how much I am
offended, because I typically try to remove my feeling from these
discussions. But really, I and other colleagues have spent quite some
effort to untangle the whole dependency mess, to provide our users as
much as we can, to give back to fedora and upstream as much as we can
and stay sane. That were not easy decisions.
I spent the time to dig out these specific examples of what we did and
why I think it is important to have branches instead of "just
conditions", but you don't pay enough attention and you dismiss them as
"Disabling docs". I am sorry, but this is not fair.
I had the conversation at the latest Devconf with people who are
aiming to build Linux distribution with a reduced buildroot footprint
for security purposes. So that they can audit the content of the
buildroot, and get to a certain level of certification with it.
I think It can not be done directly in Fedora, but if we add the
flexibility into our builds (with conditionals), then we could
eventually get a new downstream supported by a certain governmental
entity.
What we should avoid is using conditionals randomly and inconsistently.
So let's agree that we are not scattering "%if 0%{?rhel} && (!
0%{?epel})" all over the spec file, but rather define it once at the
top of the spec file:
%if 0%{?rhel} && (! 0%{?epel})
%bcond_with docs
%else
%bcond_without docs
%endif
And use later in a form
...
%if %{with doc}
%package doc
...
%endif
Yes, for now we would go with a "%if 0%{?rhel} && (! 0%{?epel})" in
the header of the affected spec file. But eventually we can think
about adding a USE-flag like functionality to the build process, and
create a global profile for the build system.
This is a very much forward-looking statement, but idea is already
making its round by the dnf team.
So there are some interesting ways how this approach can be developed
further, if we can make it work for a smaller subset first.
4:16 a.m.
On Fri, Mar 27, 2020 at 9:36 AM Vít Ondruch <vondruch(a)redhat.com> wrote:
Dne 26. 03. 20 v 12:39 Aleksandra Fedorova napsal(a):
> On Thu, Mar 26, 2020 at 10:34 AM Vít Ondruch <vondruch(a)redhat.com> wrote:
>>
>> Dne 25. 03. 20 v 20:22 James Cassell napsal(a):
>>> On Wed, Mar 25, 2020, at 1:18 PM, Vít Ondruch wrote:
>>>> Dne 25. 03. 20 v 18:06 Vít Ondruch napsal(a):
>>>>> Dne 25. 03. 20 v 17:33 Aleksandra Fedorova napsal(a):
>>> [snip]
>>>>>> We can come up with guidelines, for example:
>>>>>>
>>>>>> 1) Try to find a way to resolve the issue without any
conditionals first.
>>>>>>
>>>>>> There should be a reason why package X needs a dependency Y in
Fedora
>>>>>> and there should be a reason why it is a required dependency and
not a
>>>>>> recommended one. So why in that case downstream wants it
differently?
>>>>>> The first approach is just to talk through it. I can assume
cases
>>>>>> where downstream adds a dependency, as well as Fedora package
removing
>>>>>> them.
>>>>>>
>>>>>> Note that bloated dependency trees is a common problem for all
binary
>>>>>> distributions, it is not an "EL-thing" and we can work
on that
>>>>>> together.
>>>>>>
>>>>>> Nicolas has pointed out to another reason why we would get
>>>>>> EL-conditionals: the outdated rpm stack in RHEL. But we
don't have
>>>>>> this problem with ELN, as we are building Rawhide, and rpm stack
is
>>>>>> going to be the Rawhide rpm stack as well.
>>>>>>
>>>>>> 2) Minimize and isolate the conditional, and track the reason.
>>>>>>
>>>>>> As ELN SIG we need to have a place where we collect known
reasons for
>>>>>> such conditionals. The overall goal is to reduce this set, not
to grow
>>>>>> indefinitely. As Stephen said we expect it to be about couple
of
>>>>>> hundred packages. We will be able to track each one of them. (We
have
>>>>>> rpminspect to run package diffs for us).
>>>>>>
>>>>>> 3) In complex cases - bring it to community and FESCo.
>>>>>>
>>>>>> We don't know what those complex cases might be, one of the
goals is
>>>>>> to find them. So we keep it as an option to bring individual
case to a
>>>>>> wider audience. To ask for help and to decide on it.
>>>>>>
>>>>> It seems there are missing real life examples of what we sometimes
do in
>>>>> RHEL, so please see attached patch. This patch is coming from RHEL
>>>>> version of the espeak-ng. Now somebody tell me what it does for
what
>>>>> purpose and which scenario from the above three should be applied
here.
>>>>>
>>>>>
>>>>> Vít
>>>>>
>>>> And here is another example for the curious.
>>>>
>>> Both of these examples have to do with docs generation and trying to reduce
dependencies for that process. "Process the man page using kramdown and remove the
ronn dependency."
>>
>> The point is that these types of changes are not upstreamable. And the
>> conditions would also be awful. Having these changes in separate branch
>> would be much preferable IMO, because honestly, I would like every
>> Fedora maintainer save from this cruft not because I would like to hide
>> something, but for their own sanity.
> I disagree actually.
>
> Disabling docs to reduce dependencies makes sense. And it is not a
> RHEL-only thing.
I am sorry but you have not passed the test. The test question was "Now
somebody tell me what it does for what
purpose and which scenario from the above three should be applied here."
I would really appreciate, if you could pay attention to the two
patches I post and what they do. Including careful analysis why they
were applied and why they were not put into Fedora nor upstreamed.
Hint: They don't disable any documentation.
You put two patches on the thread without context. I assumed that they
remove the fancy dependency needed to build the doc, and instead
create the doc in a more "old-school" ways.
It maybe a wrong assumption. It happens.
Could you then explain the context, and what these patches actually do?
Thank you.
Vít
P.S. I really thinking if I should write this and if and how much I am
offended, because I typically try to remove my feeling from these
discussions. But really, I and other colleagues have spent quite some
effort to untangle the whole dependency mess, to provide our users as
much as we can, to give back to fedora and upstream as much as we can
and stay sane. That were not easy decisions.
I spent the time to dig out these specific examples of what we did and
why I think it is important to have branches instead of "just
conditions", but you don't pay enough attention and you dismiss them as
"Disabling docs". I am sorry, but this is not fair.
If I were offended every time people don't get my point and the effort
I made to make it, I would give up about 15 years ago.
But that is what discussions are all about: going through a lot of
misunderstanding, trying to actually reach the point where we can
understand each other.
>
> I had the conversation at the latest Devconf with people who are
> aiming to build Linux distribution with a reduced buildroot footprint
> for security purposes. So that they can audit the content of the
> buildroot, and get to a certain level of certification with it.
> I think It can not be done directly in Fedora, but if we add the
> flexibility into our builds (with conditionals), then we could
> eventually get a new downstream supported by a certain governmental
> entity.
>
> What we should avoid is using conditionals randomly and inconsistently.
>
> So let's agree that we are not scattering "%if 0%{?rhel} && (!
> 0%{?epel})" all over the spec file, but rather define it once at the
> top of the spec file:
>
> %if 0%{?rhel} && (! 0%{?epel})
> %bcond_with docs
> %else
> %bcond_without docs
> %endif
>
> And use later in a form
> ...
> %if %{with doc}
> %package doc
> ...
> %endif
>
> Yes, for now we would go with a "%if 0%{?rhel} && (! 0%{?epel})"
in
> the header of the affected spec file. But eventually we can think
> about adding a USE-flag like functionality to the build process, and
> create a global profile for the build system.
> This is a very much forward-looking statement, but idea is already
> making its round by the dnf team.
>
> So there are some interesting ways how this approach can be developed
> further, if we can make it work for a smaller subset first.
>
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
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@lists.fedoraproject.org
--
Aleksandra Fedorova
bookwar
4:59 a.m.
Dne 27. 03. 20 v 10:16 Aleksandra Fedorova napsal(a):
On Fri, Mar 27, 2020 at 9:36 AM Vít Ondruch
<vondruch(a)redhat.com> wrote:
>
> Dne 26. 03. 20 v 12:39 Aleksandra Fedorova napsal(a):
>> On Thu, Mar 26, 2020 at 10:34 AM Vít Ondruch <vondruch(a)redhat.com> wrote:
>>> Dne 25. 03. 20 v 20:22 James Cassell napsal(a):
>>>> On Wed, Mar 25, 2020, at 1:18 PM, Vít Ondruch wrote:
>>>>> Dne 25. 03. 20 v 18:06 Vít Ondruch napsal(a):
>>>>>> Dne 25. 03. 20 v 17:33 Aleksandra Fedorova napsal(a):
>>>> [snip]
>>>>>>> We can come up with guidelines, for example:
>>>>>>>
>>>>>>> 1) Try to find a way to resolve the issue without any
conditionals first.
>>>>>>>
>>>>>>> There should be a reason why package X needs a dependency Y
in Fedora
>>>>>>> and there should be a reason why it is a required dependency
and not a
>>>>>>> recommended one. So why in that case downstream wants it
differently?
>>>>>>> The first approach is just to talk through it. I can assume
cases
>>>>>>> where downstream adds a dependency, as well as Fedora package
removing
>>>>>>> them.
>>>>>>>
>>>>>>> Note that bloated dependency trees is a common problem for
all binary
>>>>>>> distributions, it is not an "EL-thing" and we can
work on that
>>>>>>> together.
>>>>>>>
>>>>>>> Nicolas has pointed out to another reason why we would get
>>>>>>> EL-conditionals: the outdated rpm stack in RHEL. But we
don't have
>>>>>>> this problem with ELN, as we are building Rawhide, and rpm
stack is
>>>>>>> going to be the Rawhide rpm stack as well.
>>>>>>>
>>>>>>> 2) Minimize and isolate the conditional, and track the
reason.
>>>>>>>
>>>>>>> As ELN SIG we need to have a place where we collect known
reasons for
>>>>>>> such conditionals. The overall goal is to reduce this set,
not to grow
>>>>>>> indefinitely. As Stephen said we expect it to be about couple
of
>>>>>>> hundred packages. We will be able to track each one of them.
(We have
>>>>>>> rpminspect to run package diffs for us).
>>>>>>>
>>>>>>> 3) In complex cases - bring it to community and FESCo.
>>>>>>>
>>>>>>> We don't know what those complex cases might be, one of
the goals is
>>>>>>> to find them. So we keep it as an option to bring individual
case to a
>>>>>>> wider audience. To ask for help and to decide on it.
>>>>>>>
>>>>>> It seems there are missing real life examples of what we
sometimes do in
>>>>>> RHEL, so please see attached patch. This patch is coming from
RHEL
>>>>>> version of the espeak-ng. Now somebody tell me what it does for
what
>>>>>> purpose and which scenario from the above three should be applied
here.
>>>>>>
>>>>>>
>>>>>> Vít
>>>>>>
>>>>> And here is another example for the curious.
>>>>>
>>>> Both of these examples have to do with docs generation and trying to
reduce dependencies for that process. "Process the man page using kramdown and remove
the ronn dependency."
>>> The point is that these types of changes are not upstreamable. And the
>>> conditions would also be awful. Having these changes in separate branch
>>> would be much preferable IMO, because honestly, I would like every
>>> Fedora maintainer save from this cruft not because I would like to hide
>>> something, but for their own sanity.
>> I disagree actually.
>>
>> Disabling docs to reduce dependencies makes sense. And it is not a
>> RHEL-only thing.
>
> I am sorry but you have not passed the test. The test question was "Now
> somebody tell me what it does for what
> purpose and which scenario from the above three should be applied here."
> I would really appreciate, if you could pay attention to the two
> patches I post and what they do. Including careful analysis why they
> were applied and why they were not put into Fedora nor upstreamed.
>
> Hint: They don't disable any documentation.
You put two patches on the thread without context. I assumed that they
remove the fancy dependency needed to build the doc, and instead
create the doc in a more "old-school" ways.
It maybe a wrong assumption. It happens.
Could you then explain the context, and what these patches actually do?
There is much more to this.
One think of course is to limit the dependencies. So therefore we didn't
want rubygem-ronn in RHEL. But even if we wanted, it is [1] abandoned
upstream. If Ronn is abandoned upstream, the biggest problem is with its
dependencies, which are officially deprecated upstream. While it is
abandoned upstream, it is still valuable tool, which can easily generate
man pages from markdown. So now on top of the question "should we have
Ronn in RHEL or not" you have suddenly other issues:
* Should we save upstream Ronn? And how to do this if upstream is
unresponsive.
* How to provide the documentation to our users if we don't have Ronn
available.
* Should I go to Fedora and push the Ronn removal out of the package and
possible from all packages, while we still have Ronn in Fedora?
* Should I go to all upstreams and convince them, that they should not
use Ronn, just because I cannot contact Ronn upstream, while the tool
itself is perfectly fine?
* And finally should we just remove the documentation as you framed it?
Not mentioning that if we even put the "document removal" conditional
into the package, that is actually the worst thing we could do, because
if any of the considerations above changes (Ronn gets back to the life,
upstream decided to change tools used to build documentation, there is
high demand for such tool, so we reconsider it inclusion, or there is no
demand and it is removed even from Fedora), there is almost no chance
that somebody would noticed and put the package back into its best
possible shape.
As you can see, there is much more to this just to "put some conditional
somewhere". There are very complex considerations and a lot of work.
Therefore, I would really like to see you try to replace the patches I
provided by conditions to let you feel how ugly and unmaintainable the
packages become.
As a bonus, it might be committed without good enough explanation in
commit message to let the future generations share the pain (sorry, this
is snarky remark, but unfortunately this is the reality package
maintainer lives in, the commit message can't never be good enough).
Vít
[1] I just noticed there is now ronn-ng, but it was not at that time.
And since the project has not taken over the former name, it is
naturally its own can of worms.
> Thank you.
>
>
> Vít
>
>
> P.S. I really thinking if I should write this and if and how much I am
> offended, because I typically try to remove my feeling from these
> discussions. But really, I and other colleagues have spent quite some
> effort to untangle the whole dependency mess, to provide our users as
> much as we can, to give back to fedora and upstream as much as we can
> and stay sane. That were not easy decisions.
>
> I spent the time to dig out these specific examples of what we did and
> why I think it is important to have branches instead of "just
> conditions", but you don't pay enough attention and you dismiss them as
> "Disabling docs". I am sorry, but this is not fair.
If I were offended every time people don't get my point and the effort
I made to make it, I would give up about 15 years ago.
But that is what discussions are all about: going through a lot of
misunderstanding, trying to actually reach the point where we can
understand each other.
>> I had the conversation at the latest Devconf with people who are
>> aiming to build Linux distribution with a reduced buildroot footprint
>> for security purposes. So that they can audit the content of the
>> buildroot, and get to a certain level of certification with it.
>> I think It can not be done directly in Fedora, but if we add the
>> flexibility into our builds (with conditionals), then we could
>> eventually get a new downstream supported by a certain governmental
>> entity.
>>
>> What we should avoid is using conditionals randomly and inconsistently.
>>
>> So let's agree that we are not scattering "%if 0%{?rhel} && (!
>> 0%{?epel})" all over the spec file, but rather define it once at the
>> top of the spec file:
>>
>> %if 0%{?rhel} && (! 0%{?epel})
>> %bcond_with docs
>> %else
>> %bcond_without docs
>> %endif
>>
>> And use later in a form
>> ...
>> %if %{with doc}
>> %package doc
>> ...
>> %endif
>>
>> Yes, for now we would go with a "%if 0%{?rhel} && (!
0%{?epel})" in
>> the header of the affected spec file. But eventually we can think
>> about adding a USE-flag like functionality to the build process, and
>> create a global profile for the build system.
>> This is a very much forward-looking statement, but idea is already
>> making its round by the dnf team.
>>
>> So there are some interesting ways how this approach can be developed
>> further, if we can make it work for a smaller subset first.
>>
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> 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@lists.fedoraproject.org
6:11 a.m.
On 27. 03. 20 10:59, Vít Ondruch wrote:
As you can see, there is much more to this just to "put some
conditional
somewhere". There are very complex considerations and a lot of work.
I would also like to point out the obvious:
The RHEL only patch needs to be rebased every time the package is updated to a
new version.
- RHEL doesn't generally do updates like this
- Fedora generally does updates like this often
A Fedora contributor will try to build the updated package in mock and it will
work, they will submit a PR (better case) or push directly.
When the package is attempted to be built in ELN, the patch(es) won't apply.
If the update was submitted via a PR and the PR pipeline/CI will provide this
kind of feedback, the Fedora contributor will be intimidated by this.
If the package will be gated on ELN, the Fedora contributor will be intimidated
by this.
If there is no gating and there is a direct push, the ELN build will be broken.
The RHEL/ELN maintianer will need to push a fixup patch-rebase commit or live
with a broken ELN package.
This might happen several times between RHEL 8 and 9, while the patch would only
be rebased/created once trough 1 major RHEL release lifetime.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
6:48 a.m.
On Fri, Mar 27, 2020 at 11:00 AM Vít Ondruch <vondruch(a)redhat.com> wrote:
Dne 27. 03. 20 v 10:16 Aleksandra Fedorova napsal(a):
> On Fri, Mar 27, 2020 at 9:36 AM Vít Ondruch <vondruch(a)redhat.com> wrote:
>>
>> Dne 26. 03. 20 v 12:39 Aleksandra Fedorova napsal(a):
>>> On Thu, Mar 26, 2020 at 10:34 AM Vít Ondruch <vondruch(a)redhat.com>
wrote:
>>>> Dne 25. 03. 20 v 20:22 James Cassell napsal(a):
>>>>> On Wed, Mar 25, 2020, at 1:18 PM, Vít Ondruch wrote:
>>>>>> Dne 25. 03. 20 v 18:06 Vít Ondruch napsal(a):
>>>>>>> Dne 25. 03. 20 v 17:33 Aleksandra Fedorova napsal(a):
>>>>> [snip]
>>>>>>>> We can come up with guidelines, for example:
>>>>>>>>
>>>>>>>> 1) Try to find a way to resolve the issue without any
conditionals first.
>>>>>>>>
>>>>>>>> There should be a reason why package X needs a
dependency Y in Fedora
>>>>>>>> and there should be a reason why it is a required
dependency and not a
>>>>>>>> recommended one. So why in that case downstream wants it
differently?
>>>>>>>> The first approach is just to talk through it. I can
assume cases
>>>>>>>> where downstream adds a dependency, as well as Fedora
package removing
>>>>>>>> them.
>>>>>>>>
>>>>>>>> Note that bloated dependency trees is a common problem
for all binary
>>>>>>>> distributions, it is not an "EL-thing" and we
can work on that
>>>>>>>> together.
>>>>>>>>
>>>>>>>> Nicolas has pointed out to another reason why we would
get
>>>>>>>> EL-conditionals: the outdated rpm stack in RHEL. But we
don't have
>>>>>>>> this problem with ELN, as we are building Rawhide, and
rpm stack is
>>>>>>>> going to be the Rawhide rpm stack as well.
>>>>>>>>
>>>>>>>> 2) Minimize and isolate the conditional, and track the
reason.
>>>>>>>>
>>>>>>>> As ELN SIG we need to have a place where we collect
known reasons for
>>>>>>>> such conditionals. The overall goal is to reduce this
set, not to grow
>>>>>>>> indefinitely. As Stephen said we expect it to be about
couple of
>>>>>>>> hundred packages. We will be able to track each one of
them. (We have
>>>>>>>> rpminspect to run package diffs for us).
>>>>>>>>
>>>>>>>> 3) In complex cases - bring it to community and FESCo.
>>>>>>>>
>>>>>>>> We don't know what those complex cases might be, one
of the goals is
>>>>>>>> to find them. So we keep it as an option to bring
individual case to a
>>>>>>>> wider audience. To ask for help and to decide on it.
>>>>>>>>
>>>>>>> It seems there are missing real life examples of what we
sometimes do in
>>>>>>> RHEL, so please see attached patch. This patch is coming
from RHEL
>>>>>>> version of the espeak-ng. Now somebody tell me what it does
for what
>>>>>>> purpose and which scenario from the above three should be
applied here.
>>>>>>>
>>>>>>>
>>>>>>> Vít
>>>>>>>
>>>>>> And here is another example for the curious.
>>>>>>
>>>>> Both of these examples have to do with docs generation and trying to
reduce dependencies for that process. "Process the man page using kramdown and remove
the ronn dependency."
>>>> The point is that these types of changes are not upstreamable. And the
>>>> conditions would also be awful. Having these changes in separate branch
>>>> would be much preferable IMO, because honestly, I would like every
>>>> Fedora maintainer save from this cruft not because I would like to hide
>>>> something, but for their own sanity.
>>> I disagree actually.
>>>
>>> Disabling docs to reduce dependencies makes sense. And it is not a
>>> RHEL-only thing.
>>
>> I am sorry but you have not passed the test. The test question was "Now
>> somebody tell me what it does for what
>> purpose and which scenario from the above three should be applied here."
>> I would really appreciate, if you could pay attention to the two
>> patches I post and what they do. Including careful analysis why they
>> were applied and why they were not put into Fedora nor upstreamed.
>>
>> Hint: They don't disable any documentation.
> You put two patches on the thread without context. I assumed that they
> remove the fancy dependency needed to build the doc, and instead
> create the doc in a more "old-school" ways.
> It maybe a wrong assumption. It happens.
>
> Could you then explain the context, and what these patches actually do?
There is much more to this.
One think of course is to limit the dependencies. So therefore we didn't
want rubygem-ronn in RHEL. But even if we wanted, it is [1] abandoned
upstream. If Ronn is abandoned upstream, the biggest problem is with its
dependencies, which are officially deprecated upstream. While it is
abandoned upstream, it is still valuable tool, which can easily generate
man pages from markdown. So now on top of the question "should we have
Ronn in RHEL or not" you have suddenly other issues:
* Should we save upstream Ronn? And how to do this if upstream is
unresponsive.
* How to provide the documentation to our users if we don't have Ronn
available.
* Should I go to Fedora and push the Ronn removal out of the package and
possible from all packages, while we still have Ronn in Fedora?
* Should I go to all upstreams and convince them, that they should not
use Ronn, just because I cannot contact Ronn upstream, while the tool
itself is perfectly fine?
* And finally should we just remove the documentation as you framed it?
Thanks for the explanation.
Not mentioning that if we even put the "document removal"
conditional
into the package, that is actually the worst thing we could do, because
if any of the considerations above changes (Ronn gets back to the life,
upstream decided to change tools used to build documentation, there is
high demand for such tool, so we reconsider it inclusion, or there is no
demand and it is removed even from Fedora), there is almost no chance
that somebody would noticed and put the package back into its best
possible shape.
This part I don't understand. If we have a with_docs conditional, we
keep building package with docs in Fedora. And downstream needs to
track on its own when it would like to switch this conditional on for
downstream packages.
I think it is not different from what we have right now, is it?
As you can see, there is much more to this just to "put some conditional
somewhere". There are very complex considerations and a lot of work.
Therefore, I would really like to see you try to replace the patches I
provided by conditions to let you feel how ugly and unmaintainable the
packages become.
There is one point to note here: when I posted example of the
guidelines with those three items, i didn't mean it as a choice, as if
you need to choose one out of three. I meant it as steps: you need to
go through all of them.
And you are skipping one here.
So before we go into conditionals, we should have a discussion: can we
solve it in upstream or Fedora itself. Was it discussed with Fedora
maintainer and the upstream? Do they have a strong opinion on that?
If upstream is not interested in removing dependency on the package,
would they consider _adding_ an option to build a "lightweight"
variant of the documentation without it? As a build flag or something.
Would Fedora maintainer be ok to switch to this lightweight version of the docs?
Then there is a downstream-facing question: Do you really need docs
for this package in downstream so much that it justifies maintaining
the entire source of the documentation files?
In that espeak-ng patch if I understand correctly you replace original
sources for the documentation. In this case instead of adding those
pieces into Fedora spec, I would do it differently: I would have
with_docs condition in Fedora spec, which would disable docs when they
are not needed. And then I would have a separate package, downstream
only, with converted docs, which downstream will maintain.
Now if we still go with direct conditional option, then I would limit
what goes under conditional. So instead of putting the whole thing
from the patch under "if", I would add a patch which allows both
options. Which adds the target to Makefile instead of removing it. And
then only put the switch between them under conditional in the spec
file.
The espeak patch is disruptive currently because it edits things in
place. For example it edits README file, instead of adding the
README.EL part. Or it removes doc files instead of adding them into a
different docs-el subfolder. So the goal here would be refactor the
patch so that version bump can be done in a clean way. And then you
either add some automation for the version bump, so it updates the
docs properly. Or you leave it to the downstream maintainer to watch
for the upstream change and send pull-requests to update this part.
Which will bring downstream developer to the position of the
co-maintainer of this package.
So i am not proposing something like "let's convert every patch into a
conditional". The goal is not to have all RHEL content in Fedora
Rawhide tree. The goal is to search for ways to make it easier to
create EL content out of Fedora tree.
As a bonus, it might be committed without good enough explanation in
commit message to let the future generations share the pain (sorry, this
is snarky remark, but unfortunately this is the reality package
maintainer lives in, the commit message can't never be good enough).
Vít
[1] I just noticed there is now ronn-ng, but it was not at that time.
And since the project has not taken over the former name, it is
naturally its own can of worms.
>
>> Thank you.
>>
>>
>> Vít
>>
>>
>> P.S. I really thinking if I should write this and if and how much I am
>> offended, because I typically try to remove my feeling from these
>> discussions. But really, I and other colleagues have spent quite some
>> effort to untangle the whole dependency mess, to provide our users as
>> much as we can, to give back to fedora and upstream as much as we can
>> and stay sane. That were not easy decisions.
>>
>> I spent the time to dig out these specific examples of what we did and
>> why I think it is important to have branches instead of "just
>> conditions", but you don't pay enough attention and you dismiss them
as
>> "Disabling docs". I am sorry, but this is not fair.
> If I were offended every time people don't get my point and the effort
> I made to make it, I would give up about 15 years ago.
> But that is what discussions are all about: going through a lot of
> misunderstanding, trying to actually reach the point where we can
> understand each other.
>
>>> I had the conversation at the latest Devconf with people who are
>>> aiming to build Linux distribution with a reduced buildroot footprint
>>> for security purposes. So that they can audit the content of the
>>> buildroot, and get to a certain level of certification with it.
>>> I think It can not be done directly in Fedora, but if we add the
>>> flexibility into our builds (with conditionals), then we could
>>> eventually get a new downstream supported by a certain governmental
>>> entity.
>>>
>>> What we should avoid is using conditionals randomly and inconsistently.
>>>
>>> So let's agree that we are not scattering "%if 0%{?rhel} &&
(!
>>> 0%{?epel})" all over the spec file, but rather define it once at the
>>> top of the spec file:
>>>
>>> %if 0%{?rhel} && (! 0%{?epel})
>>> %bcond_with docs
>>> %else
>>> %bcond_without docs
>>> %endif
>>>
>>> And use later in a form
>>> ...
>>> %if %{with doc}
>>> %package doc
>>> ...
>>> %endif
>>>
>>> Yes, for now we would go with a "%if 0%{?rhel} && (!
0%{?epel})" in
>>> the header of the affected spec file. But eventually we can think
>>> about adding a USE-flag like functionality to the build process, and
>>> create a global profile for the build system.
>>> This is a very much forward-looking statement, but idea is already
>>> making its round by the dnf team.
>>>
>>> So there are some interesting ways how this approach can be developed
>>> further, if we can make it work for a smaller subset first.
>>>
>> _______________________________________________
>> devel mailing list -- devel(a)lists.fedoraproject.org
>> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>> 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@lists.fedoraproject.org
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
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@lists.fedoraproject.org
--
Aleksandra Fedorova
bookwar
8:55 a.m.
Dne 27. 03. 20 v 12:48 Aleksandra Fedorova napsal(a):
On Fri, Mar 27, 2020 at 11:00 AM Vít Ondruch
<vondruch(a)redhat.com> wrote:
>
> Dne 27. 03. 20 v 10:16 Aleksandra Fedorova napsal(a):
>> On Fri, Mar 27, 2020 at 9:36 AM Vít Ondruch <vondruch(a)redhat.com> wrote:
>>> Dne 26. 03. 20 v 12:39 Aleksandra Fedorova napsal(a):
>>>> On Thu, Mar 26, 2020 at 10:34 AM Vít Ondruch <vondruch(a)redhat.com>
wrote:
>>>>> Dne 25. 03. 20 v 20:22 James Cassell napsal(a):
>>>>>> On Wed, Mar 25, 2020, at 1:18 PM, Vít Ondruch wrote:
>>>>>>> Dne 25. 03. 20 v 18:06 Vít Ondruch napsal(a):
>>>>>>>> Dne 25. 03. 20 v 17:33 Aleksandra Fedorova napsal(a):
>>>>>> [snip]
>>>>>>>>> We can come up with guidelines, for example:
>>>>>>>>>
>>>>>>>>> 1) Try to find a way to resolve the issue without any
conditionals first.
>>>>>>>>>
>>>>>>>>> There should be a reason why package X needs a
dependency Y in Fedora
>>>>>>>>> and there should be a reason why it is a required
dependency and not a
>>>>>>>>> recommended one. So why in that case downstream wants
it differently?
>>>>>>>>> The first approach is just to talk through it. I can
assume cases
>>>>>>>>> where downstream adds a dependency, as well as Fedora
package removing
>>>>>>>>> them.
>>>>>>>>>
>>>>>>>>> Note that bloated dependency trees is a common
problem for all binary
>>>>>>>>> distributions, it is not an "EL-thing" and
we can work on that
>>>>>>>>> together.
>>>>>>>>>
>>>>>>>>> Nicolas has pointed out to another reason why we
would get
>>>>>>>>> EL-conditionals: the outdated rpm stack in RHEL. But
we don't have
>>>>>>>>> this problem with ELN, as we are building Rawhide,
and rpm stack is
>>>>>>>>> going to be the Rawhide rpm stack as well.
>>>>>>>>>
>>>>>>>>> 2) Minimize and isolate the conditional, and track
the reason.
>>>>>>>>>
>>>>>>>>> As ELN SIG we need to have a place where we collect
known reasons for
>>>>>>>>> such conditionals. The overall goal is to reduce this
set, not to grow
>>>>>>>>> indefinitely. As Stephen said we expect it to be
about couple of
>>>>>>>>> hundred packages. We will be able to track each one
of them. (We have
>>>>>>>>> rpminspect to run package diffs for us).
>>>>>>>>>
>>>>>>>>> 3) In complex cases - bring it to community and
FESCo.
>>>>>>>>>
>>>>>>>>> We don't know what those complex cases might be,
one of the goals is
>>>>>>>>> to find them. So we keep it as an option to bring
individual case to a
>>>>>>>>> wider audience. To ask for help and to decide on it.
>>>>>>>>>
>>>>>>>> It seems there are missing real life examples of what we
sometimes do in
>>>>>>>> RHEL, so please see attached patch. This patch is coming
from RHEL
>>>>>>>> version of the espeak-ng. Now somebody tell me what it
does for what
>>>>>>>> purpose and which scenario from the above three should be
applied here.
>>>>>>>>
>>>>>>>>
>>>>>>>> Vít
>>>>>>>>
>>>>>>> And here is another example for the curious.
>>>>>>>
>>>>>> Both of these examples have to do with docs generation and trying
to reduce dependencies for that process. "Process the man page using kramdown and
remove the ronn dependency."
>>>>> The point is that these types of changes are not upstreamable. And
the
>>>>> conditions would also be awful. Having these changes in separate
branch
>>>>> would be much preferable IMO, because honestly, I would like every
>>>>> Fedora maintainer save from this cruft not because I would like to
hide
>>>>> something, but for their own sanity.
>>>> I disagree actually.
>>>>
>>>> Disabling docs to reduce dependencies makes sense. And it is not a
>>>> RHEL-only thing.
>>> I am sorry but you have not passed the test. The test question was "Now
>>> somebody tell me what it does for what
>>> purpose and which scenario from the above three should be applied
here."
>>> I would really appreciate, if you could pay attention to the two
>>> patches I post and what they do. Including careful analysis why they
>>> were applied and why they were not put into Fedora nor upstreamed.
>>>
>>> Hint: They don't disable any documentation.
>> You put two patches on the thread without context. I assumed that they
>> remove the fancy dependency needed to build the doc, and instead
>> create the doc in a more "old-school" ways.
>> It maybe a wrong assumption. It happens.
>>
>> Could you then explain the context, and what these patches actually do?
>
> There is much more to this.
>
> One think of course is to limit the dependencies. So therefore we didn't
> want rubygem-ronn in RHEL. But even if we wanted, it is [1] abandoned
> upstream. If Ronn is abandoned upstream, the biggest problem is with its
> dependencies, which are officially deprecated upstream. While it is
> abandoned upstream, it is still valuable tool, which can easily generate
> man pages from markdown. So now on top of the question "should we have
> Ronn in RHEL or not" you have suddenly other issues:
>
> * Should we save upstream Ronn? And how to do this if upstream is
> unresponsive.
>
> * How to provide the documentation to our users if we don't have Ronn
> available.
>
> * Should I go to Fedora and push the Ronn removal out of the package and
> possible from all packages, while we still have Ronn in Fedora?
>
> * Should I go to all upstreams and convince them, that they should not
> use Ronn, just because I cannot contact Ronn upstream, while the tool
> itself is perfectly fine?
>
> * And finally should we just remove the documentation as you framed it?
Thanks for the explanation.
> Not mentioning that if we even put the "document removal" conditional
> into the package, that is actually the worst thing we could do, because
> if any of the considerations above changes (Ronn gets back to the life,
> upstream decided to change tools used to build documentation, there is
> high demand for such tool, so we reconsider it inclusion, or there is no
> demand and it is removed even from Fedora), there is almost no chance
> that somebody would noticed and put the package back into its best
> possible shape.
This part I don't understand. If we have a with_docs conditional, we
keep building package with docs in Fedora. And downstream needs to
track on its own when it would like to switch this conditional on for
downstream packages.
I think it is not different from what we have right now, is it?
Yes, that is not different from what we have right now and then the
question is what would be the benefit of your proposal. I see just
downsides. I would need to do what I do + on top of that, there would be
conditionals in Fedora to have it working in ELN.
The benefit of branch would be that at minimum, we would do it publicly
+ with all the CI, we would know that something in Fedora broke our
future RHEL package.
> As you can see, there is much more to this just to "put some conditional
> somewhere". There are very complex considerations and a lot of work.
>
>
> Therefore, I would really like to see you try to replace the patches I
> provided by conditions to let you feel how ugly and unmaintainable the
> packages become.
There is one point to note here: when I posted example of the
guidelines with those three items, i didn't mean it as a choice, as if
you need to choose one out of three. I meant it as steps: you need to
go through all of them.
And you are skipping one here.
I am sorry, which one?
So before we go into conditionals, we should have a discussion: can we
solve it in upstream or Fedora itself. Was it discussed with Fedora
maintainer and the upstream? Do they have a strong opinion on that?
If upstream is not interested in removing dependency on the package,
would they consider _adding_ an option to build a "lightweight"
variant of the documentation without it? As a build flag or something.
Would Fedora maintainer be ok to switch to this lightweight version of the docs?
Then there is a downstream-facing question: Do you really need docs
for this package in downstream so much that it justifies maintaining
the entire source of the documentation files?
Of course we did all these steps. While the question "Do you really need
docs for this package in downstream" should not be asked at all". This
is doing disservice to our users, to our support and also disservice to
upstream.
In that espeak-ng patch if I understand correctly you replace original
sources for the documentation. In this case instead of adding those
pieces into Fedora spec, I would do it differently: I would have
with_docs condition in Fedora spec, which would disable docs when they
are not needed. And then I would have a separate package, downstream
only, with converted docs, which downstream will maintain.
We might disagree, but while this is probably possible, it is nowhere
close to be maintainable. Moving this into separate package means 1) I
(and users) have one more package to take care 2) There is higher chance
that the documentation does not reflect the state of the package.
On top of that, you might perceive failed build due to not applicable
patch as a problem, I see it as benefit. It is feedback that something
has changed upstream and I should pay attention.
Now if we still go with direct conditional option, then I would limit
what goes under conditional. So instead of putting the whole thing
from the patch under "if", I would add a patch which allows both
options. Which adds the target to Makefile instead of removing it.
You can touch Makefile only in the simplest projects. I cannot imagine I
should touch Makefile in Ruby for example, which has thousands of lines,
nobody wants to do that.
And
then only put the switch between them under conditional in the spec
file.
The espeak patch is disruptive currently because it edits things in
place. For example it edits README file, instead of adding the
README.EL part.
There is not .EL part as far as I know, there documentation is 1:1 to
upstream AFAIK, the only change is the format change from .ronn to .md
Or it removes doc files instead of adding them into a
different docs-el subfolder. So the goal here would be refactor the
patch so that version bump can be done in a clean way.
If you do just version bump, the patch will likely apply cleanly. Ok,
currently, there is updated release and changelog, but if these were two
commits (or if there was automation or release and changelog bumps), the
rebase of this package would be done by git just fine.
And then you
either add some automation for the version bump, so it updates the
docs properly. Or you leave it to the downstream maintainer to watch
for the upstream change and send pull-requests to update this part.
Which will bring downstream developer to the position of the
co-maintainer of this package.
Now I am lost, who is upstream and who downstream. But anyway, ideal
state is when RHEL/Fedora/Upstream is one person. If there was chance to
have it like RHEL/ELN/Fedora/Upstream, that would be even better. But
you can't reasonably have this with conditional but without branch.
Because the requirements for RHEL and Fedora are from time to time
different. And I am speaking here with both hats, as a RHEL developer as
well as Fedora developer. IOW I am doing different decisions for Fedora
and RHEL.
So i am not proposing something like "let's convert every patch into a
conditional". The goal is not to have all RHEL content in Fedora
Rawhide tree.
Sorry, definitely not for me, speaking again with both hats.
The goal is to search for ways to make it easier to
create EL content out of Fedora tree.
That is indeed noble goal which I support and why I am involved in this
discussion. However, the means you are intend to provide are so far not
acceptable.
Vít
12:15 p.m.
On 25. 03. 20 17:33, Aleksandra Fedorova wrote:
> I consider rawhide users our users and I assume many other do
consider them our
> users as well. I consider upstream projects who run their CI on Fedora our
> users. You are not incorrect that this is a terminology issue, however I think
> this is a different mindset issue. Please do consider rawhide users and upstream
> projects our users when designing things.
You are misinterpreting what I said. And it is a terminology issue.
Let's agree on that.
You somehow assume that if we call people users - we care about
them,
and if we call them contributors, they are _just_ contributors, so we
don't.
This is not what I have said, and please don't put such a mindset on me.
The difference between users and contributors is not how you treat
them, but a level of knowledge about Fedora internals which is
expected from them.
Using rawhide on your workstation is possible, but you need to learn
first what rawhide is and you need to make an educated choice to use
it.
Same with ELN.
This also applies to e.g. "Fedora Workstation". Using "Fedora
Workstation" on
your workstation is possible, but you need to learn first what "Fedora
Workstation" is and you need to make an educated choice to use it. (unless
somebody else makes this choice instead and they install it for you, which also
applies to rawhide or ELN.)
It does not have impact on Fedora Workstation user experience. My
grandma, who is Fedora user since Fedora 8, will not see this change
on her laptop and she doesn't need to be informed about it.
Neither does your grandma need to be notified about most of the other changes in
Fedora just in order to be able to use it.
Never mind. **I see what you mean.** After all those words I understand what you
meant by the statement. However when reading just the change proposal, the
statement doesn't make sense to me. And if it so complicated to explain, maybe
it makes sense to stop saying there will be no user deliverables and rephrase
it? Say that users of rawhide or Fedora (pre)releases will not be affected. And
say how can ELN users consume it (for their CI or for their mock).
> For example, there is a point to run an ELN on a server - e.g. to
run a buildbot
> worker on it for some CI tests.
I think this is not the server Neil meant.
My point was to highlight that ELN is not a "stable edition" like
Fedora Server. ELN is Rawhide, its quality is no better than Rawhide
quality, its stability is Rawhide stability, its target audience is
Rawhide audience.
I get what you **mean**. However I think that "Fedora Server" and
"rawhide" are
not comparable or contradicting terms. You can have Fedora Server while having
rawhide. You cannot say "Fedora Server is a stable edition, unlike rawhide".
I don't want to argue about our terminology anymore. I understand what you are
saying in your emails, but I didn't understand what the change proposal is
saying (and I think neither will all others).
>>> This is all nice only as long as you prefer conditionals
over branching. For a
>>> Fedora maintainer who doesn't, this is just "unnecessary cruft"
in the spec file.
>>
>> It is not really about personal preferences. These are two different
>> approaches with different purposes, different results and different
>> requirements.
>> There are consequences on choosing one other the other.
>
> Yes. That's what I've been saying since the beginning. Choosing %ifs over
> branches has consequences. Choosing branches over %ifs has consequences. Not
> being able to choose has consequences.
>
>> Branching means forking Fedora Rawhide into something else. Which
>> eventually will lead to new downstream tree which will ignore the rest
>> of Fedora and just use the fork instead. It can be done, but I think
>> it will damage Fedora as a project.
>
> Not if we do automation that constantly keeps them in sync. Is that hard? Most
> likely. But it doesn't put additional burden to the community maintainers.
It removes community maintainer from the conversation about what
downstream is doing. While we want to give community member a voice in
that conversation.
I don't see how.
It also cuts community maintainer from the help of downstream, as
downstream will be developing a fork.
This boils down to terminology (again). What you call a fork is a separate
branch. In my eyes a branch with a bcond switched is no more "fork" than a %if
in one branch. Consider this:
Case A:
there is just master branch. it has:
%if 0%{?rhel} && (! 0%{?epel})
%bcond_with tests
%else
%bcond_without tests
%endif
Case B:
there are 2 branches. master has:
%bcond_without tests
eln has:
%bcond_with tests
But their content is otherwise identical. How is Case B more fork-ish than Case A?
We can not fully implement it in the planning phase. It is not a
generic question with generic answer. It needs to be decided on a
package level. And decision maybe different for each package and for
each case.
We can come up with guidelines... (snip)
Sure. Let's try to do that **before** we move on. And while we do that, consider
different approaches as well.
>> But if you look at the change you'll see that it has no
blocking
>> features whatsoever. We are not changing how Fedora is built and how
>> it is released.
>
> 1) This changes how Fedora is maintained.
This is not disruptive. If we stop building ELN compose at certain
point we don't lose anything for Fedora Rawhide.
At the point I was writing this I assumed we are talking about all packages in
Fedora. I was concerned we could lose the maintainers who would leave because of
"forced" changes.
> 2) This has a potential of changing how RHEL is bootstrapped,
making it
> essential and hard to cancel.
If the whole concept doesn't work, it won't become essential to RHEL.
Although this worries me, it is not the problem with canceling the
change, it is a problem with us (as Fedora) not having it.
The concept will work for RHEL quite nicely. What I worry about is how it will
work for Fedora. It mind be already decided that RHEL needs this while we would
still be collecting Fedora feedback. Yet again, I was writing that when I
assumed all packages would be affected.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
12:59 p.m.
Le mercredi 25 mars 2020 à 17:33 +0100, Aleksandra Fedorova a écrit :
My point was to highlight that ELN is not a "stable
edition" like
Fedora Server. ELN is Rawhide, its quality is no better than Rawhide
quality, its stability is Rawhide stability, its target audience is
Rawhide audience.
Ok, then if I may play the devil’s advocate. Why is it not Rawhide? Are
@rh fixes so valueless you wouldn’t want them in Fedora itself? Are
community contributors so scary it is not possible to find
accocmodations with them?
I *think* ELN comes from good intentions. Just like modularity came
from good intentions. Just like Centos stream came from good
intentions. That beind said, good intentions are not enough for a
proposal to succeed.
The core problem (root cause in ITIL speak) is that years of EL
balkanization Centos and RHEL side, with little Fedora involvment, and
a dearth of clear upstream/downstream ground rules, completely tore
down the upstream to downstream packaging pipeline. And that
modularity, didn’t make the situation any better. Which leaves EL with
a huge upstream problem.
Fedora itself has no such problem, except for the experimental not-
quite-releases Adam ranted about a few days ago. Rawhide → stable →
stable - 1. KISS and effective (as long as you do not get into EPEL
land, but that’s not due to the Fedora part of the equation). That’s
why the *community*, by and large, has been thoroughly unimpressed by
the attempts to convert Fedora into the same hodgepole of ill-defined
overlapping package fiefdoms/streams.
So, before we go full charge ahead on technical solutions, without
considering the social challenges (that did not work so well before),
could those proposals come with a clear package lifecycle graph, from
Rawhide to Fedora to ELN to stream to EPEL to whatever? And answer the
following questions:
1. I want <nice software> available on my own non-production system
(and the systems of my friends), at what point of the lifecycle graph
should I contribute? (<nice software> end user)
2. I want <nice software> available on my own production system (that I
maintain without @rh help), at what point of the lifecycle graph should
I contribute? (<nice software> work user)
3. I want <nice software> available on my own production system, but I
don’t want to maintain it myself, and @rh does not include <nice
software> in RHEL/Centos, where should I contract the packaging work
(I’m not a software house but I’m rich enough to sponsor the packaging
of a few pieces). (<nice software> corp user)
4. I want my own <nice software> to be distributed widely, at what
point of the lifecycle graph can I help advancing things? <nice
software> creator)
You can add other reasons to do community packaging work in Fedora if I
missed one.
The point is, *community* work, need to be rewarded one way or another.
And the only thing you can reward community work with, is shipping the
result of this work somewhere. So, all those new proposals, without
clear commitments on shipping the result somewhere the contributor can
make use of it, are quite disturbing.
A picture is worth a thousand words. Please draw us what you are
attempting to achieve. That will make it so much easier for everyone
here to understand it.
And you can say “it’s only for @rh employees”. But that’s giving up on
making Fedora work as a community project.
Regards,
--
Nicolas Mailhot
1:10 p.m.
On Wed, Mar 25, 2020 at 2:00 PM Nicolas Mailhot via devel
<devel(a)lists.fedoraproject.org> wrote:
Le mercredi 25 mars 2020 à 17:33 +0100, Aleksandra Fedorova a écrit :
> My point was to highlight that ELN is not a "stable edition" like
> Fedora Server. ELN is Rawhide, its quality is no better than Rawhide
> quality, its stability is Rawhide stability, its target audience is
> Rawhide audience.
Ok, then if I may play the devil’s advocate. Why is it not Rawhide? Are
@rh fixes so valueless you wouldn’t want them in Fedora itself? Are
community contributors so scary it is not possible to find
accocmodations with them?
Any and all fixes that can apply to Fedora will be applied to Fedora
without conditionals. Period. There are changes that RHEL might make
that Fedora would not like. A fairly common one is to carry
pre-generated documentation instead of rebuilding it in the rpmbuild
so as to avoid having to BuildRequires: the doc tools. Another example
is that RHEL might want to configure the package to build only stable
features where Fedora might also want to enable experimental features.
In general, very few packages should even need conditionalizing at
all; that's why I've been saying that this discussion is premature.
I *think* ELN comes from good intentions. Just like modularity came
from good intentions. Just like Centos stream came from good
intentions. That beind said, good intentions are not enough for a
proposal to succeed.
The core problem (root cause in ITIL speak) is that years of EL
balkanization Centos and RHEL side, with little Fedora involvment, and
a dearth of clear upstream/downstream ground rules, completely tore
down the upstream to downstream packaging pipeline. And that
modularity, didn’t make the situation any better. Which leaves EL with
a huge upstream problem.
While I disagree with the hyperbole, I agree that the
upstream-downstream pipeline has become less clear. This is intended
specifically to improve on that.
1:15 p.m.
On 25. 03. 20 19:10, Stephen Gallagher wrote:
In general, very few packages should even need conditionalizing at
all; that's why I've been saying that this discussion is premature.
Most of the Python packages we maintain in RHEL would need conditionalizing to
disable (part of) tests or docs.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1:19 p.m.
On Wed, Mar 25, 2020 at 2:16 PM Miro Hrončok <mhroncok(a)redhat.com> wrote:
On 25. 03. 20 19:10, Stephen Gallagher wrote:
> In general, very few packages should even need conditionalizing at
> all; that's why I've been saying that this discussion is premature.
Most of the Python packages we maintain in RHEL would need conditionalizing to
disable (part of) tests or docs.
Disabling regeneration of documentation I get, but why would you
disable running the tests? That stuff is important to ensure the
packages aren't broken as you maintain them, patch them, etc.
--
真実はいつも一つ！/ Always, there's only one truth!
1:42 p.m.
Neal Gompa <ngompa13(a)gmail.com> writes:
Miro Hrončok <mhroncok(a)redhat.com> wrote:
> Stephen Gallagher wrote:
>
>> In general, very few packages should even need conditionalizing at
>> all; that's why I've been saying that this discussion is premature.
>
> Most of the Python packages we maintain in RHEL would need conditionalizing to
> disable (part of) tests or docs.
>
Disabling regeneration of documentation I get, but why would you
disable running the tests? That stuff is important to ensure the
packages aren't broken as you maintain them, patch them, etc.
Typically because test dependencies aren't included in the
distribution. They don't get ignored, but they're not run at RPM build
time.
Thanks,
--Robbie
1:44 p.m.
On 25. 03. 20 19:19, Neal Gompa wrote:
On Wed, Mar 25, 2020 at 2:16 PM Miro
Hrončok<mhroncok(a)redhat.com> wrote:
> On 25. 03. 20 19:10, Stephen Gallagher wrote:
>> In general, very few packages should even need conditionalizing at
>> all; that's why I've been saying that this discussion is premature.
> Most of the Python packages we maintain in RHEL would need conditionalizing to
> disable (part of) tests or docs.
>
Disabling regeneration of documentation I get, but why would you
disable running the tests? That stuff is important to ensure the
packages aren't broken as you maintain them, patch them, etc.
Mostly because there are missing test dependencies. That's why we disable (some)
tests. For example I have packages that cannot be tested in RHEL buildroot, but
I test them locally by building them in EPEL mock --with tests. If even EPEL
isn't enough, I install packages from PyPI via pip to my mock buidroot and than
build with %check enabled but without the problematic test BuildRequires.
Take for example python-pip (snippet from rawhide, added notes):
%if %{with tests}
BuildRequires: python%{python3_pkgversion}-mock # PowerTools
BuildRequires: python%{python3_pkgversion}-pytest # AppStream
BuildRequires: python%{python3_pkgversion}-pretend # EPEL
BuildRequires: python%{python3_pkgversion}-freezegun # EPEL
BuildRequires: python%{python3_pkgversion}-scripttest # missing
BuildRequires: python%{python3_pkgversion}-virtualenv # AppStream
BuildRequires: python%{python3_pkgversion}-werkzeug # AppStream
BuildRequires: python%{python3_pkgversion}-pyyaml # BaseOS
%endif
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1:47 p.m.
Le mercredi 25 mars 2020 à 14:19 -0400, Neal Gompa a écrit :
On Wed, Mar 25, 2020 at 2:16 PM Miro Hrončok
<mhroncok(a)redhat.com>
wrote:
> On 25. 03. 20 19:10, Stephen Gallagher wrote:
> > In general, very few packages should even need conditionalizing
> > at
> > all; that's why I've been saying that this discussion is
> > premature.
>
> Most of the Python packages we maintain in RHEL would need
> conditionalizing to
> disable (part of) tests or docs.
>
Disabling regeneration of documentation I get, but why would you
disable running the tests? That stuff is important to ensure the
packages aren't broken as you maintain them, patch them, etc.
Unfortunately, a lot of upstream testing code is poorly written and
maintained, and will do all kinds of horrors: using legally uncumbered
deps, attempting to reconfigure the system as root (because
containers), testing downstream users (creating dependency loops),
testing things you configured away, testing things that were removed
from the main code long ago (but their usnit tests lingers), requiring
a deep dependency tree to test trivial things, etc
Sometimes the only reason it “works” upstream is that upstream stopped
maintaining it and the same unchanging config is tested in a loop all
year round to feed lots of meaningless green lines to hosting service
and the author’s PHB.
As a result, the test suite may be more hassle to package and maintain
than the software it tests (and, with little to show for all this
bother).
Regards,
--
Nicolas Mailhot
3:34 p.m.
On Wed, Mar 25, 2020 at 1:00 PM Nicolas Mailhot via devel
<devel(a)lists.fedoraproject.org> wrote:
Le mercredi 25 mars 2020 à 17:33 +0100, Aleksandra Fedorova a écrit :
> My point was to highlight that ELN is not a "stable edition" like
> Fedora Server. ELN is Rawhide, its quality is no better than Rawhide
> quality, its stability is Rawhide stability, its target audience is
> Rawhide audience.
Ok, then if I may play the devil’s advocate. Why is it not Rawhide? Are
@rh fixes so valueless you wouldn’t want them in Fedora itself? Are
community contributors so scary it is not possible to find
accocmodations with them?
I don't see this as the case at all. I think the point here is all of
those fixes have to be put in through rawhide. One major reason on why
it is not rawhide is because it won't run on the average Fedora
system. Remember that conversation about build flags last year? AVX2
and similar minimum baselines? Enterprise doesn't have to run on 10
year old hardware. They can set new baselines for every release. Once
they are set, that version will support those baselines for years, but
the next version may not support the same baseline. Fedora does
support older systems, and as you might recall from that thread, it
seems a good 70% of current Fedora systems would not support such new
baselines. ELN is rawhide, or at least a subset of rawhide, but the
build flags are optimized for a different type of system.
I *think* ELN comes from good intentions. Just like modularity came
from good intentions. Just like Centos stream came from good
intentions. That beind said, good intentions are not enough for a
proposal to succeed.
The core problem (root cause in ITIL speak) is that years of EL
balkanization Centos and RHEL side, with little Fedora involvment, and
a dearth of clear upstream/downstream ground rules, completely tore
down the upstream to downstream packaging pipeline. And that
modularity, didn’t make the situation any better. Which leaves EL with
a huge upstream problem.
Fedora itself has no such problem, except for the experimental not-
quite-releases Adam ranted about a few days ago. Rawhide → stable →
stable - 1. KISS and effective (as long as you do not get into EPEL
land, but that’s not due to the Fedora part of the equation). That’s
why the *community*, by and large, has been thoroughly unimpressed by
the attempts to convert Fedora into the same hodgepole of ill-defined
overlapping package fiefdoms/streams.
So, before we go full charge ahead on technical solutions, without
considering the social challenges (that did not work so well before),
could those proposals come with a clear package lifecycle graph, from
Rawhide to Fedora to ELN to stream to EPEL to whatever? And answer the
following questions:
1. I want <nice software> available on my own non-production system
(and the systems of my friends), at what point of the lifecycle graph
should I contribute? (<nice software> end user)
2. I want <nice software> available on my own production system (that I
maintain without @rh help), at what point of the lifecycle graph should
I contribute? (<nice software> work user)
3. I want <nice software> available on my own production system, but I
don’t want to maintain it myself, and @rh does not include <nice
software> in RHEL/Centos, where should I contract the packaging work
(I’m not a software house but I’m rich enough to sponsor the packaging
of a few pieces). (<nice software> corp user)
4. I want my own <nice software> to be distributed widely, at what
point of the lifecycle graph can I help advancing things? <nice
software> creator)
You can add other reasons to do community packaging work in Fedora if I
missed one.
The point is, *community* work, need to be rewarded one way or another.
And the only thing you can reward community work with, is shipping the
result of this work somewhere. So, all those new proposals, without
clear commitments on shipping the result somewhere the contributor can
make use of it, are quite disturbing.
I think there can be multiple wins here for Fedora. RHEL developers
paying more attention to Fedora should work out well. For users who
have capable systems, there may be some advantage to running a hybrid
Rawhide/ELN system. This can be done without having releases and
installable media. It just takes a bit of additional dnf configuration
(I am assuming the priority option still works on repositories). At
least the theory was performance would be better with the higher
baseline. Now, none of this does anything to support Fedora stable
releases yet, but it does give us a place to test and see if such an
effort would be worthwhile.
> A picture is worth a thousand words. Please draw us what you are
> attempting to achieve. That will make it so much easier for everyone
> here to understand it.
>
> And you can say “it’s only for @rh employees”. But that’s giving up on
> making Fedora work as a community project.
>
> Regards,
>
> --
> Nicolas Mailhot
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> 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@lists.fedoraproject.org
10:59 p.m.
On Tue, Mar 24, 2020 at 5:33 AM Aleksandra Fedorova <alpha(a)bookwar.info> wrote:
I've finally had an opportunity to digest this change proposal, and
I've got some overall questions and feedback.
== Summary ==
The goal of the ELN project is to continuously build Fedora Rawhide
packages and composes in the way which resembles the CentOS and RHEL
build process and to provide a feedback loop for Fedora maintainers on
the status of those builds.
== Owner ==
* Name: [[User:Bookwar| Aleksandra Fedorova]]
* Email: alpha(a)bookwar.info
* Name: [[User:Sgallagh | Stephen Gallagher]]
* Email: sgallagh(a)redhat.com
== Detailed Description ==
This Change supersedes the previously-approved [[Changes/Additional
buildroot to test x86-64 micro-architecture update|Change]] to enable
an additional buildroot. During development, its scope has expanded to
include the entire process of how the Fedora sources are built and
composed into shippable artifacts.
ELN is an evolution of the request for an alternate buildroot for
newer x86_64 processors. The reasoning behind that new buildroot was
that we expected that the next major release of RHEL would likely drop
support for older hardware and therefore could take advantage of
enhancements and processor extensions available for newer hardware. As
plans for this proceeded, they expanded into a desire to do more than
just test out the processor architecture. Instead, we want to have a
complete alternative compose of Fedora Rawhide that resembles the way
that Red Hat and CentOS builds their packages. The idea being that
Fedora developers and third-party vendors who rely on Red Hat
Enterprise Linux have a place where they can directly contribute to
what will eventually become the next RHEL.
I'd like to point out here that if your proposal on x86_64 changes for
ELN are anything like the ones proposed before that were rejected in
Fedora, I literally would have nearly zero servers that can run ELN
software. Server lifetimes are long, and depending on what you're
optimizing for, you're not as likely to have all the newest whiz-bang
"high end" instructions that Intel puts in their CPUs.
And don't forget that workstations are even worse off in corporate
environments. Remember that Intel segments instruction availability
across CPU lines and price points. You *really* don't want to alienate
your *paying customers* by having them find out all their hardware is
no good or that you're effectively raising the TCO by a significant
degree by forcing "high end" instructions.
ELN (Enterprise Linux Next) is going to be that place. What we want
to
do is establish a set of RPM conditionals that can be used for the set
of packages that may need to be built differently for a RHEL-like
target as compared to a Fedora one. (For example, we may want to skip
regenerating documentation during package-build and instead use
pre-built docs from the tarball or SRPM.)
This includes:
* buildroot configuration, rpm macro and compile flags,
* comps files and the compose content,
* compose itself and the pipeline which builds it.
Under this umbrella we are going to have:
* RPM variables for conditionals to allow tweaking rpm spec files
* A new Koji tag which allows control of the buildroot,
* A fork of the pungi configuration which describes the compose configuration,
* A pipeline which builds a periodic compose based on that configuration,
* Storage for such composes and additional pipelines which will verify
the quality of the compose and test additional scenarios on top of it.
The RPM variables:
* `%{dist}` will return `.eln` (no numerical suffix)
* `%{fedora}` will return `.fcXX` (where XX is the Fedora version
represented by Rawhide).
* `%{rhel}` will be set and will return a number one higher than the
most recent major release of Red Hat Enterprise Linux (at present,
that will be `9`).
* `%{eln}` will be set and will expand to `%{rhel}`
The reasoning behind this approach is so that we break as little as
possible when we implement this new build and compose. Existing
packages that are using conditionals such as `if 0%{?rhel} > 7` will
transition over to building "like RHEL" automatically. Any packages
that do not have a shared Fedora/RHEL specfile will continue to build
as normal. Some unknown number of packages that rely on `if !
0%{?fedora}` will require manual intervention.
The `%{eln}` variable will be set primarily to allow for the
possibility of needing conditionals that apply to ELN only and should
not carry over to RHEL, but we expect its use to be exceptionally
rare.
This sounds interesting....
== Benefit to Fedora ==
Who benefits from the implementation of this feature:
* Fedora Infrastructure
** As we are going to try and test new, more easily maintainable
infrastructure for composes.
This is weird and fuzzy, what do you mean by that? Do you have a
concrete proposal of infrastructure changes you want to test?
* Fedora Minimization
** As we are going to modify the compose content according to
minimization goals and provide feedback to Fedora maintainers on the
results
Uhh, what? What does this mean?
* CentOS Stream, EPEL and RHEL
** We are going to build Fedora packages into a compose similar to the
multi-repo structure of CentOS and RHEL.
OK, this actually makes sense...
* Fedora Community
** The feedback pipelines built for the project will allow downstream
developers to open up their work and bring it closer to Fedora. In
particular, it will enable projects like OpenShift to do their work in
Fedora.
... and this doesn't.
Nothing has ever stopped any project from using Fedora other than
their own lack of desire to do so. And as a member of the OKD Working
Group, I've brought this point up when the CentOS CoreOS was starting
to be discussed. In fact, in all the discussions I've had across
oVirt, RDO, and OpenShift, every single group has said the problem
with Fedora *for them* is that it isn't slow/stale enough for them.
Some of them have also brought up the point that they are not given
the necessary bandwidth to be able to integrate with the Fedora
community and do proper maintenance of their stacks. Consequently, we
wound up in situations like with RDO, where they were massively behind
on bringup for the next RHEL. They were mostly caught flat-footed on
moving to Python 3 and are struggling because they never bothered to
incrementally evolve like those that were integrated into Fedora
(GlusterFS and Ceph) did.
This Change proposal solves none of those issues.
** Making Fedora friendlier to its downstream will justify bringing
more resources and more contributions to Fedora Rawhide. So that
downstream not only tries to catch up with Fedora going forward, but
actively participates in Fedora development and testing.
I don't see anything in here that concretely makes Rawhide more
attractive. Could you please explain how this would improve it over
the current situation?
** The tooling developed for this project will allow further
development of changes in Fedora Infrastructure without blocking the
regular Fedora packaging and release process.
Uhh, what? Again, nothing in here seems to indicate this is true.
== Scope ==
* Proposal owners:
** Setup build environment for a new disttag (`eln`).
I think an unversioned disttag is asking for trouble. Koji's NVR
uniqueness constraint will bite us on this over time. Can we make this
something like .eln.elXX? There's going to have to be an
redhat-eln-release package anyway that defines these things, and it's
better to be versioned upfront to avoid future potential insanity.
** Setup automation to trigger new ELN build every time there is a
new
update submitted to Fedora Rawhide.
** Post build result to Fedora Messaging, so that it appears in Bodhi
and can be used as a
[https://docs.fedoraproject.org/en-US/rawhide-gating/ gating test].
Wouldn't the build AMQP message be a consequence of a build happening
from the trigger anyway? And if the gating flows you've been working
on for Rawhide are working, this should just be a natural consequence
of things. So this could be simplified to "run Fedora Rawhide
submission and gating process".
** Setup automation to run periodic partial composes (via ODCS)
without installation media to generate repositories with these
packages.
What the heck is ODCS? And why no install media if you want this to be
useful to people?
** Update packaging documentation to mention new disttag and how it
can be used.
* Other developers:
*: Anyone who wants to produce different content for the ELN compose
will need to implement the new macros in their specfile. The
overwhelming majority of packages will require no modification.
* Release engineering: [https://pagure.io/releng/issue/9154 #9154]
* Policies and guidelines:
[https://pagure.io/packaging-committee/issue/955 #955]
* Trademark approval: not needed. There is no new shippable artifact.
Nope. Something needs to ship. Otherwise, how would all these
downstreams you list as beneficiaries be able to do anything with it?
== Upgrade/compatibility impact ==
N/A
Though it is a System Wide change it doesn’t impact Fedora upgrades,
as it is a development environment tracking Fedora Rawhide.
Actually, I would suggest we should consider noting that EL8 -> ELN
upgrades should be considered here, since this an attempt to integrate
rhel-rawhide into Fedora.
== How To Test ==
There is going to be a development snapshot of the state of the ELN
repositories.
It is under discussion whether this snapshot will have its own
installation media. For now the preferred way to test ELN composes
would be to use standard Fedora Rawhide images and then include ELN as
an additional repository.
This makes no sense. A cursory evaluation of what this Change entails
means that under no point would this "ELN" tree be able to be
validated as a freestanding tree if this remained the case. If this is
intended to be properly useful, it should contain the full scope of
deliverables, including installation media. It should become
eventually possible to use OpenQA and everything else we have against
ELN and validate it accordingly.
== User Experience ==
There is no user-facing part in this change. No ELN artifacts are
going to be shipped to the end-user.
This is not okay. Without a shipped component, nobody can do anything with it.
== Dependencies ==
There is no dependency on other changes, though some of the
infrastructure services like ODCS composes and Fedora CI will be
involved.
That sounds like dependencies? Please elaborate on the specifics here.
Dependencies are not just about Change proposals, but components,
infrastructure, and people too.
== Contingency Plan ==
* 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 cancelled.
* Contingency deadline: N/A as it is a continuous process in Fedora
Rawhide and it is not pinned to a specific release.
* Blocks release? No
* Blocks product? No
Additional risk: Infrastructure resources taken by ELN builds can
create load on Fedora build system
This is absolutely guaranteed. Especially since you plan to schedule
rebuilds automatically.
Mitigation: In case of such load we cancel or reschedule ELN tasks
(package and compose builds and tests) on request from the Fedora
Infrastructure team. At least initially, we will also set ELN tasks to
low-priority, similar to how COPR does it.
This mitigation strategy will not work for the same reason that it
didn't work for MBS. It's not the priority of the tasks, it's the
quantity. In another thread, I did the calculation of how much builder
resources we have, and as it currently stands, we're being pushed to
the limits with 3~4 distro releases and module streams for each of
those, plus three addon distros (EPEL). And I'm not including the
Koschei stuff and the non-RPM builds we do (Flatpaks, containers, disk
images, ISOs...)!
Please come up with a plan on how to scale up Fedora build
infrastructure to handle the additional demand. I'm not saying
implement said plan immediately, but we need a strategy to add more
resources to build infrastructure sooner rather than later. This
combined with the Fedora CI work and various auto-rebuild strategies
already in place will likely push us past reasonable performance
thresholds for the infrastructure, and I'd rather us be ready for
that.
== Documentation ==
https://fedoraproject.org/wiki/ELN
See also previous discussions:
* "Alternative buildroot as a development tool" @ devel
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
== Release Notes ==
N/A
Though it is a System-Wide Change it has no user-facing component. We
may announce it through other channels.
What's the point if there's no user-facing component? This seems
fundamentally broken. How do people use it? Consume and build on it?
I know that's not the aim, but from my perspective as a Fedora
contributor, package maintainer, and ISV developer, I *should* be
attracted to this Change. But I'm not, because it feels like it's
written for Red Hat people to move their sandbox outside of Red Hat
into Fedora without anyone else to be able to play in the sandbox. The
number of times it was indicated that there are no installation media
or end-user deliverables just reinforces this perception.
Please realize that I *want* to be excited by this. So give me
something to be excited about! :)
--
真実はいつも一つ！/ Always, there's only one truth!
2:46 a.m.
On Wed, Mar 25, 2020 at 5:00 AM Neal Gompa <ngompa13(a)gmail.com> wrote:
On Tue, Mar 24, 2020 at 5:33 AM Aleksandra Fedorova <alpha(a)bookwar.info> wrote:
>
> https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
>
I've finally had an opportunity to digest this change proposal, and
I've got some overall questions and feedback.
> == Summary ==
>
> The goal of the ELN project is to continuously build Fedora Rawhide
> packages and composes in the way which resembles the CentOS and RHEL
> build process and to provide a feedback loop for Fedora maintainers on
> the status of those builds.
>
> == Owner ==
>
> * Name: [[User:Bookwar| Aleksandra Fedorova]]
> * Email: alpha(a)bookwar.info
> * Name: [[User:Sgallagh | Stephen Gallagher]]
> * Email: sgallagh(a)redhat.com
>
> == Detailed Description ==
>
> This Change supersedes the previously-approved [[Changes/Additional
> buildroot to test x86-64 micro-architecture update|Change]] to enable
> an additional buildroot. During development, its scope has expanded to
> include the entire process of how the Fedora sources are built and
> composed into shippable artifacts.
>
> ELN is an evolution of the request for an alternate buildroot for
> newer x86_64 processors. The reasoning behind that new buildroot was
> that we expected that the next major release of RHEL would likely drop
> support for older hardware and therefore could take advantage of
> enhancements and processor extensions available for newer hardware. As
> plans for this proceeded, they expanded into a desire to do more than
> just test out the processor architecture. Instead, we want to have a
> complete alternative compose of Fedora Rawhide that resembles the way
> that Red Hat and CentOS builds their packages. The idea being that
> Fedora developers and third-party vendors who rely on Red Hat
> Enterprise Linux have a place where they can directly contribute to
> what will eventually become the next RHEL.
>
I'd like to point out here that if your proposal on x86_64 changes for
ELN are anything like the ones proposed before that were rejected in
Fedora, I literally would have nearly zero servers that can run ELN
software. Server lifetimes are long, and depending on what you're
optimizing for, you're not as likely to have all the newest whiz-bang
"high end" instructions that Intel puts in their CPUs.
And don't forget that workstations are even worse off in corporate
environments. Remember that Intel segments instruction availability
across CPU lines and price points. You *really* don't want to alienate
your *paying customers* by having them find out all their hardware is
no good or that you're effectively raising the TCO by a significant
degree by forcing "high end" instructions.
> ELN (Enterprise Linux Next) is going to be that place. What we want to
> do is establish a set of RPM conditionals that can be used for the set
> of packages that may need to be built differently for a RHEL-like
> target as compared to a Fedora one. (For example, we may want to skip
> regenerating documentation during package-build and instead use
> pre-built docs from the tarball or SRPM.)
>
> This includes:
>
> * buildroot configuration, rpm macro and compile flags,
> * comps files and the compose content,
> * compose itself and the pipeline which builds it.
>
> Under this umbrella we are going to have:
> * RPM variables for conditionals to allow tweaking rpm spec files
> * A new Koji tag which allows control of the buildroot,
> * A fork of the pungi configuration which describes the compose configuration,
> * A pipeline which builds a periodic compose based on that configuration,
> * Storage for such composes and additional pipelines which will verify
> the quality of the compose and test additional scenarios on top of it.
>
> The RPM variables:
>
> * `%{dist}` will return `.eln` (no numerical suffix)
> * `%{fedora}` will return `.fcXX` (where XX is the Fedora version
> represented by Rawhide).
> * `%{rhel}` will be set and will return a number one higher than the
> most recent major release of Red Hat Enterprise Linux (at present,
> that will be `9`).
> * `%{eln}` will be set and will expand to `%{rhel}`
>
> The reasoning behind this approach is so that we break as little as
> possible when we implement this new build and compose. Existing
> packages that are using conditionals such as `if 0%{?rhel} > 7` will
> transition over to building "like RHEL" automatically. Any packages
> that do not have a shared Fedora/RHEL specfile will continue to build
> as normal. Some unknown number of packages that rely on `if !
> 0%{?fedora}` will require manual intervention.
>
> The `%{eln}` variable will be set primarily to allow for the
> possibility of needing conditionals that apply to ELN only and should
> not carry over to RHEL, but we expect its use to be exceptionally
> rare.
>
This sounds interesting....
> == Benefit to Fedora ==
>
> Who benefits from the implementation of this feature:
> * Fedora Infrastructure
> ** As we are going to try and test new, more easily maintainable
> infrastructure for composes.
This is weird and fuzzy, what do you mean by that? Do you have a
concrete proposal of infrastructure changes you want to test?
> * Fedora Minimization
> ** As we are going to modify the compose content according to
> minimization goals and provide feedback to Fedora maintainers on the
> results
Uhh, what? What does this mean?
> * CentOS Stream, EPEL and RHEL
> ** We are going to build Fedora packages into a compose similar to the
> multi-repo structure of CentOS and RHEL.
OK, this actually makes sense...
> * Fedora Community
> ** The feedback pipelines built for the project will allow downstream
> developers to open up their work and bring it closer to Fedora. In
> particular, it will enable projects like OpenShift to do their work in
> Fedora.
... and this doesn't.
Nothing has ever stopped any project from using Fedora other than
their own lack of desire to do so. And as a member of the OKD Working
Group, I've brought this point up when the CentOS CoreOS was starting
to be discussed. In fact, in all the discussions I've had across
oVirt, RDO, and OpenShift, every single group has said the problem
with Fedora *for them* is that it isn't slow/stale enough for them.
Some of them have also brought up the point that they are not given
the necessary bandwidth to be able to integrate with the Fedora
community and do proper maintenance of their stacks. Consequently, we
wound up in situations like with RDO, where they were massively behind
on bringup for the next RHEL. They were mostly caught flat-footed on
moving to Python 3 and are struggling because they never bothered to
incrementally evolve like those that were integrated into Fedora
(GlusterFS and Ceph) did.
This Change proposal solves none of those issues.
> ** Making Fedora friendlier to its downstream will justify bringing
> more resources and more contributions to Fedora Rawhide. So that
> downstream not only tries to catch up with Fedora going forward, but
> actively participates in Fedora development and testing.
I don't see anything in here that concretely makes Rawhide more
attractive. Could you please explain how this would improve it over
the current situation?
> ** The tooling developed for this project will allow further
> development of changes in Fedora Infrastructure without blocking the
> regular Fedora packaging and release process.
>
Uhh, what? Again, nothing in here seems to indicate this is true.
> == Scope ==
> * Proposal owners:
> ** Setup build environment for a new disttag (`eln`).
I think an unversioned disttag is asking for trouble. Koji's NVR
uniqueness constraint will bite us on this over time. Can we make this
something like .eln.elXX? There's going to have to be an
redhat-eln-release package anyway that defines these things, and it's
better to be versioned upfront to avoid future potential insanity.
> ** Setup automation to trigger new ELN build every time there is a new
> update submitted to Fedora Rawhide.
> ** Post build result to Fedora Messaging, so that it appears in Bodhi
> and can be used as a
> [https://docs.fedoraproject.org/en-US/rawhide-gating/ gating test].
Wouldn't the build AMQP message be a consequence of a build happening
from the trigger anyway? And if the gating flows you've been working
on for Rawhide are working, this should just be a natural consequence
of things. So this could be simplified to "run Fedora Rawhide
submission and gating process".
> ** Setup automation to run periodic partial composes (via ODCS)
> without installation media to generate repositories with these
> packages.
What the heck is ODCS? And why no install media if you want this to be
useful to people?
I will just answer the "What the heck is ODCS" part, since I'm the dev
and maintainer of Fedora ODCS instance.
ODCS is On Demand Compose Service. It is a service allowing people or
other services to run Pungi composes providing some nice features like
rebuilding the very same compose again even after a few years,
tracking who built which compose and when, allowing people to build
'smaller' predefined composes on demand. It also makes compose process
scalable, because it supports multiple backends for doing composes.
Deployment of ODCS or its maintenance is *not* part of this proposal
definitely, because this is already done in Fedora and ODCS is used
for flatpak builds. The Fedora releng team is also going to use it for
some of their internal composes independently on the Change proposed
in this thread.
It is however not a service for general Fedora users - it's more
service for relengs and developers of other services which depend on
composes.
Upstream is here: https://pagure.io/odcs.
Docs: https://docs.pagure.org/odcs/
Fedora prod instance is running here for quite some time:
https://odcs.fedoraproject.org/api/1/composes/
In case you want to know more, write me off-list, on IRC or in new
thread. Please do not derail this thread ;).
Regards,
Jan Kaluza
> ** Update packaging documentation to mention new disttag and how
it can be used.
>
> * Other developers:
> *: Anyone who wants to produce different content for the ELN compose
> will need to implement the new macros in their specfile. The
> overwhelming majority of packages will require no modification.
>
> * Release engineering: [https://pagure.io/releng/issue/9154 #9154]
>
> * Policies and guidelines:
> [https://pagure.io/packaging-committee/issue/955 #955]
>
> * Trademark approval: not needed. There is no new shippable artifact.
>
Nope. Something needs to ship. Otherwise, how would all these
downstreams you list as beneficiaries be able to do anything with it?
> == Upgrade/compatibility impact ==
>
> N/A
>
> Though it is a System Wide change it doesn’t impact Fedora upgrades,
> as it is a development environment tracking Fedora Rawhide.
>
Actually, I would suggest we should consider noting that EL8 -> ELN
upgrades should be considered here, since this an attempt to integrate
rhel-rawhide into Fedora.
> == How To Test ==
>
> There is going to be a development snapshot of the state of the ELN
> repositories.
>
> It is under discussion whether this snapshot will have its own
> installation media. For now the preferred way to test ELN composes
> would be to use standard Fedora Rawhide images and then include ELN as
> an additional repository.
>
This makes no sense. A cursory evaluation of what this Change entails
means that under no point would this "ELN" tree be able to be
validated as a freestanding tree if this remained the case. If this is
intended to be properly useful, it should contain the full scope of
deliverables, including installation media. It should become
eventually possible to use OpenQA and everything else we have against
ELN and validate it accordingly.
> == User Experience ==
>
> There is no user-facing part in this change. No ELN artifacts are
> going to be shipped to the end-user.
>
This is not okay. Without a shipped component, nobody can do anything with it.
> == Dependencies ==
>
> There is no dependency on other changes, though some of the
> infrastructure services like ODCS composes and Fedora CI will be
> involved.
>
That sounds like dependencies? Please elaborate on the specifics here.
Dependencies are not just about Change proposals, but components,
infrastructure, and people too.
> == Contingency Plan ==
>
> * 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 cancelled.
> * Contingency deadline: N/A as it is a continuous process in Fedora
> Rawhide and it is not pinned to a specific release.
> * Blocks release? No
> * Blocks product? No
>
> Additional risk: Infrastructure resources taken by ELN builds can
> create load on Fedora build system
>
This is absolutely guaranteed. Especially since you plan to schedule
rebuilds automatically.
> Mitigation: In case of such load we cancel or reschedule ELN tasks
> (package and compose builds and tests) on request from the Fedora
> Infrastructure team. At least initially, we will also set ELN tasks to
> low-priority, similar to how COPR does it.
>
This mitigation strategy will not work for the same reason that it
didn't work for MBS. It's not the priority of the tasks, it's the
quantity. In another thread, I did the calculation of how much builder
resources we have, and as it currently stands, we're being pushed to
the limits with 3~4 distro releases and module streams for each of
those, plus three addon distros (EPEL). And I'm not including the
Koschei stuff and the non-RPM builds we do (Flatpaks, containers, disk
images, ISOs...)!
Please come up with a plan on how to scale up Fedora build
infrastructure to handle the additional demand. I'm not saying
implement said plan immediately, but we need a strategy to add more
resources to build infrastructure sooner rather than later. This
combined with the Fedora CI work and various auto-rebuild strategies
already in place will likely push us past reasonable performance
thresholds for the infrastructure, and I'd rather us be ready for
that.
> == Documentation ==
>
> https://fedoraproject.org/wiki/ELN
>
> See also previous discussions:
> * "Alternative buildroot as a development tool" @ devel
>
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
>
> == Release Notes ==
>
> N/A
>
> Though it is a System-Wide Change it has no user-facing component. We
> may announce it through other channels.
>
What's the point if there's no user-facing component? This seems
fundamentally broken. How do people use it? Consume and build on it?
I know that's not the aim, but from my perspective as a Fedora
contributor, package maintainer, and ISV developer, I *should* be
attracted to this Change. But I'm not, because it feels like it's
written for Red Hat people to move their sandbox outside of Red Hat
into Fedora without anyone else to be able to play in the sandbox. The
number of times it was indicated that there are no installation media
or end-user deliverables just reinforces this perception.
Please realize that I *want* to be excited by this. So give me
something to be excited about! :)
--
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
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@lists.fedoraproject.org
4:30 a.m.
Dne 25. 03. 20 v 4:59 Neal Gompa napsal(a):
On Tue, Mar 24, 2020 at 5:33 AM Aleksandra Fedorova
<alpha(a)bookwar.info> wrote:
> == Detailed Description ==
>
> This Change supersedes the previously-approved [[Changes/Additional
> buildroot to test x86-64 micro-architecture update|Change]] to enable
> an additional buildroot. During development, its scope has expanded to
> include the entire process of how the Fedora sources are built and
> composed into shippable artifacts.
>
> ELN is an evolution of the request for an alternate buildroot for
> newer x86_64 processors. The reasoning behind that new buildroot was
> that we expected that the next major release of RHEL would likely drop
> support for older hardware and therefore could take advantage of
> enhancements and processor extensions available for newer hardware. As
> plans for this proceeded, they expanded into a desire to do more than
> just test out the processor architecture. Instead, we want to have a
> complete alternative compose of Fedora Rawhide that resembles the way
> that Red Hat and CentOS builds their packages. The idea being that
> Fedora developers and third-party vendors who rely on Red Hat
> Enterprise Linux have a place where they can directly contribute to
> what will eventually become the next RHEL.
>
I'd like to point out here that if your proposal on x86_64 changes for
ELN are anything like the ones proposed before that were rejected in
Fedora, I literally would have nearly zero servers that can run ELN
software. Server lifetimes are long, and depending on what you're
optimizing for, you're not as likely to have all the newest whiz-bang
"high end" instructions that Intel puts in their CPUs.
Since Neal have mentioned Intel and x86_64, I assume that ELN is going
to support as much architectures as Fedora provides, is that right?
Vít
8:17 a.m.
On Tue, Mar 24, 2020 at 10:32:26AM +0100, Aleksandra Fedorova wrote:
This includes:
* buildroot configuration, rpm macro and compile flags,
* comps files and the compose content,
* compose itself and the pipeline which builds it.
[...]
The discussion so far was mostly about *mechanisms*, i.e. how
inheritance will be set up, if there will be macros, etc.
In the discussion of conditionals vs. branches and how many changes
will be necessary and how likely packagers are to accept the patches,
it was hard to reach a conclusion because we don't know what type
of changes will be introduced, i.e. what *policy* will be implemented
using those newly available mechanisms.
What kind of changes from Fedora are planned in eln:
- making the package look like what will be in next rhel?
- some kind of experimentation with compile settings, for example to
change amd64 baseline requirements?
- ???
I understand that a full answer cannot be given at this time, but if
we knew the general plan, we could judge more easily the amount of
changes, the burden on packagers, and maybe even the amount of build
failures.
Zbyszek
10:47 a.m.
Starting a new sub-thread.
On Tue, Mar 24, 2020 at 5:33 AM Aleksandra Fedorova <alpha(a)bookwar.info> wrote:
As Ben is on PTO, I'd like to present the System-Wide Change
https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
== Summary ==
The goal of the ELN project is to continuously build Fedora Rawhide
packages and composes in the way which resembles the CentOS and RHEL
build process and to provide a feedback loop for Fedora maintainers on
the status of those builds.
I think we managed to miss a few key points in the Change Proposal
which is directly resulting in a bit of the confusion here.
The first and most important of these is that ELN will *not* be
building the complete Fedora package set. We're going to be building a
selected subset of packages (derived from packages in RHEL 8 and
EPEL). Our current expectation is that we are going to be looking at
fewer than 2500 source packages. We are still working up the initial
list of these and we will update the Change Proposal with it (as well
as providing a fedora-devel post breaking down the known owners).
Second, from this reduced subset, we expect that the overwhelming
majority of the maintainers are Red Hat employees that already work on
RHEL. With this in mind, we think that the level of concern about how
this will affect non-Red Hat contributors is premature. We will reach
out directly to those non-Red Hat contributors we identify.
Finally, of the set of packages that we're going to be including, we
anticipate around 200-300 of them will have distro conditionals that
need investigation (with fewer needing actual modification). The ELN
SIG will be doing this initial investigation and will provide guidance
(and/or PRs) to affected packagers.
11:03 a.m.
Dne 25. 03. 20 v 16:47 Stephen Gallagher napsal(a):
Starting a new sub-thread.
On Tue, Mar 24, 2020 at 5:33 AM Aleksandra Fedorova <alpha(a)bookwar.info> wrote:
> As Ben is on PTO, I'd like to present the System-Wide Change
>
> https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
>
> == Summary ==
>
> The goal of the ELN project is to continuously build Fedora Rawhide
> packages and composes in the way which resembles the CentOS and RHEL
> build process and to provide a feedback loop for Fedora maintainers on
> the status of those builds.
I think we managed to miss a few key points in the Change Proposal
which is directly resulting in a bit of the confusion here.
The first and most important of these is that ELN will *not* be
building the complete Fedora package set. We're going to be building a
selected subset of packages (derived from packages in RHEL 8 and
EPEL). Our current expectation is that we are going to be looking at
fewer than 2500 source packages. We are still working up the initial
list of these and we will update the Change Proposal with it (as well
as providing a fedora-devel post breaking down the known owners).
I assume that for the beginning we are talking about the RHEL8 BaseOS
and CRB components and as soon as you figure out modules, then this will
apply to AppStream as well (although not everything in AppStream are
modules)?
Vít
Second, from this reduced subset, we expect that the overwhelming
majority of the maintainers are Red Hat employees that already work on
RHEL. With this in mind, we think that the level of concern about how
this will affect non-Red Hat contributors is premature. We will reach
out directly to those non-Red Hat contributors we identify.
Finally, of the set of packages that we're going to be including, we
anticipate around 200-300 of them will have distro conditionals that
need investigation (with fewer needing actual modification). The ELN
SIG will be doing this initial investigation and will provide guidance
(and/or PRs) to affected packagers.
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
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@lists.fedoraproject.org
11:10 a.m.
On 25. 03. 20 16:47, Stephen Gallagher wrote:
I think we managed to miss a few key points in the Change Proposal
which is directly resulting in a bit of the confusion here.
Reading the rest of you e-mail I must agree that this is what happened. Would
you mind putting the change back to incomplete state and resend it once more for
feedback once this is addressed?
The first and most important of these is that ELN will*not* be
building the complete Fedora package set. We're going to be building a
selected subset of packages (derived from packages in RHEL 8 and
EPEL). Our current expectation is that we are going to be looking at
fewer than 2500 source packages. We are still working up the initial
list of these and we will update the Change Proposal with it (as well
as providing a fedora-devel post breaking down the known owners).
Glad to hear that.
Second, from this reduced subset, we expect that the overwhelming
majority of the maintainers are Red Hat employees that already work on
RHEL. With this in mind, we think that the level of concern about how
this will affect non-Red Hat contributors is premature. We will reach
out directly to those non-Red Hat contributors we identify.
As a Red employee if I need to diverge a RHEL package from Fedora, I prefer to
use branches as well. And I know for a fact I am not alone in this. Please don't
forget to identify and reach out to Red Hat contributors as well, not just the
non-Red Hat contributors.
Finally, of the set of packages that we're going to be including,
we
anticipate around 200-300 of them will have distro conditionals that
need investigation (with fewer needing actual modification). The ELN
SIG will be doing this initial investigation and will provide guidance
(and/or PRs) to affected packagers.
My concerns still remain, although I am now not so scared that this will
alienate the community. Now the concern is more personal (= previously I was
worried that everybody will be encouraged to use the conditionals, while now I'm
mostly concerned they I will be encouraged to use the conditionals).
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
9:54 a.m.
On 2020-03-25 17:33, Aleksandra Fedorova wrote:
[Branching] removes community maintainer from the conversation about
what
downstream is doing. While we want to give community member a voice in
that conversation.
I fear that this proposal *forces* the community member to participate
in the discussion. That is a very different thing than giving them a voice.
On 2020-03-25 17:10, Miro Hrončok wrote:
On 25. 03. 20 16:47, Stephen Gallagher wrote:
> I think we managed to miss a few key points in the Change Proposal
> which is directly resulting in a bit of the confusion here.
Reading the rest of you e-mail I must agree that this is what happened.
Would you mind putting the change back to incomplete state and resend it
once more for feedback once this is addressed?
> The first and most important of these is that ELN will*not* be
> building the complete Fedora package set. We're going to be building a
> selected subset of packages (derived from packages in RHEL 8 and
> EPEL). Our current expectation is that we are going to be looking at
> fewer than 2500 source packages. We are still working up the initial
> list of these and we will update the Change Proposal with it (as well
> as providing a fedora-devel post breaking down the known owners).
Glad to hear that.
> Second, from this reduced subset, we expect that the overwhelming
> majority of the maintainers are Red Hat employees that already work on
> RHEL. With this in mind, we think that the level of concern about how
> this will affect non-Red Hat contributors is premature. We will reach
> out directly to those non-Red Hat contributors we identify.
This actually worries me very much.
The subset of packages will need to form a working system; it will
include the most important packages. I hope this doesn't end up limiting
maintainers of Fedora's most central packages to only Red Hatters or
those that agree to play by RHEL rules that they have no say in.
I am pretty sure that most packages/packagers will be OK with the ELN
change. But "most" is not enough. We do need to take the "worst cases"
into account. Consider a package that:
- is needed in RHEL, but only as a dependency of something vital; the
RHEL maintainer doesn't care too much about it outside their work duties
- has an enthusiastic packager in Fedora, who prefers to leave RHEL work
to paid developers
(As member of a team that, some time ago, used to be catch-all RHEL
maintainer for anything that happened to be written in Python, I can
definitely imagine situations similar to this.)
For such a package, we need to avoid pushing ELN macros into the
package, otherwise we lose an enthusiastic contributor who does amazing
work in Fedora.
Such a package might even be hypothetical right now, but the case still
needs to be adressed. A package can fall into this category at any time
in the future. It's not enough to identifying packagers that are
affected now, and work with them. There needs to be a process for cases
like these, and it can't be "merge these ELN macros now, there's a
deadline coming; maybe we'll come up with a better process in the
future". (Especially if Red Hat is unlikely to drive setting up a better
process.)
IMO, any changes needed in EL need to be opt-in, with the understanding
that opting in will be (almost always) beneficial for everyone involved.
They need to feel like a gift ("Hello fedora packager, please accept
this PR with EL macros; it'll make it easier to work on this together!")
rather than forced ("Red Hat needs this; merge it or else").
To borrow Neal Gompa's words, ELN needs to not feel "like it's written
for Red Hat people to move their sandbox outside of Red Hat into Fedora
without anyone else to be able to play in the sandbox."
For ELN changes to be to be opt-in, there essentially needs to be a
place to diverge -- a place for ELN hotfixes to live while polishing
them and debating their usefulness in Fedora and further upstreams.
Here by "hotfix" I need something required in RHEL that is not yet ready
for upstream. It is healthy to have a place for such things: it removes
time pressure from discussions (people from the community very often
have good ideas but less time), but allows the fix to be used now (so
the rest of ELN isn't blocked).
Forks are good if they're not permanent (but, making them not permanent
needs effort).
As Miro Hrončok continues:
As a Red employee if I need to diverge a RHEL package from Fedora, I
prefer to use branches as well. And I know for a fact I am not alone in
this. Please don't forget to identify and reach out to Red Hat
contributors as well, not just the non-Red Hat contributors.
[Stephen Gallagher]:
> Finally, of the set of packages that we're going to be including, we
> anticipate around 200-300 of them will have distro conditionals that
> need investigation (with fewer needing actual modification). The ELN
> SIG will be doing this initial investigation and will provide guidance
> (and/or PRs) to affected packagers.
What would IMO help would be tracking all such divergences from Fedora
as bugs/issues on the Red Hat side, and spending effort to triage them,
polish them and discuss them with the community. Not as initial
investigation, but ongoing effort.
10:10 a.m.
On Thu, Mar 26, 2020 at 03:54:07PM +0100, Petr Viktorin wrote:
On 2020-03-25 17:33, Aleksandra Fedorova wrote:
> [Branching] removes community maintainer from the conversation about what
> downstream is doing. While we want to give community member a voice in
> that conversation.
I fear that this proposal *forces* the community member to participate in
the discussion. That is a very different thing than giving them a voice.
That reminds me that even if all the ELN changes were pushed into dedicated
branch, the package owner would have to grant commit access to the packagers
who is going to maintain the ELN branch. This how Pagure works.
We has already observed this issue with EPEL branches where someone else wants
to maintain an EPEL package in the EPEL branch but cannot because the package
owner in Fedora does not respond to grant him the commit access to that
package.
-- Petr
10:23 a.m.
On Thu, Mar 26, 2020 at 04:10:08PM +0100, Petr Pisar wrote:
On Thu, Mar 26, 2020 at 03:54:07PM +0100, Petr Viktorin wrote:
> On 2020-03-25 17:33, Aleksandra Fedorova wrote:
> > [Branching] removes community maintainer from the conversation about what
> > downstream is doing. While we want to give community member a voice in
> > that conversation.
>
> I fear that this proposal *forces* the community member to participate in
> the discussion. That is a very different thing than giving them a voice.
>
That reminds me that even if all the ELN changes were pushed into dedicated
branch, the package owner would have to grant commit access to the packagers
who is going to maintain the ELN branch. This how Pagure works.
We has already observed this issue with EPEL branches where someone else wants
to maintain an EPEL package in the EPEL branch but cannot because the package
owner in Fedora does not respond to grant him the commit access to that
package.
Yep, that happens and is very frustrating to people blocked by this.
Most of the time it's the usual story of people being too busy, but a
contributing factor is that there's no per-branch access — in pagure
it's all or nothing — so one has too trust the new co-maintainer fully.
Zbyszek
5:14 p.m.
On Thu, Mar 26, 2020 at 11:24 AM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
On Thu, Mar 26, 2020 at 04:10:08PM +0100, Petr Pisar wrote:
> On Thu, Mar 26, 2020 at 03:54:07PM +0100, Petr Viktorin wrote:
> > On 2020-03-25 17:33, Aleksandra Fedorova wrote:
> > > [Branching] removes community maintainer from the conversation about what
> > > downstream is doing. While we want to give community member a voice in
> > > that conversation.
> >
> > I fear that this proposal *forces* the community member to participate in
> > the discussion. That is a very different thing than giving them a voice.
> >
> That reminds me that even if all the ELN changes were pushed into dedicated
> branch, the package owner would have to grant commit access to the packagers
> who is going to maintain the ELN branch. This how Pagure works.
>
> We has already observed this issue with EPEL branches where someone else wants
> to maintain an EPEL package in the EPEL branch but cannot because the package
> owner in Fedora does not respond to grant him the commit access to that
> package.
Yep, that happens and is very frustrating to people blocked by this.
Most of the time it's the usual story of people being too busy, but a
contributing factor is that there's no per-branch access — in pagure
it's all or nothing — so one has too trust the new co-maintainer fully.
This is finally going to be fixed: https://pagure.io/pagure/pull-request/4786
--
真実はいつも一つ！/ Always, there's only one truth!
4:54 a.m.
On Thu, Mar 26, 2020 at 3:55 PM Petr Viktorin <pviktori(a)redhat.com> wrote:
On 2020-03-25 17:33, Aleksandra Fedorova wrote:
> [Branching] removes community maintainer from the conversation about what
> downstream is doing. While we want to give community member a voice in
> that conversation.
I fear that this proposal *forces* the community member to participate
in the discussion. That is a very different thing than giving them a voice.
On 2020-03-25 17:10, Miro Hrončok wrote:
> On 25. 03. 20 16:47, Stephen Gallagher wrote:
>> I think we managed to miss a few key points in the Change Proposal
>> which is directly resulting in a bit of the confusion here.
>
> Reading the rest of you e-mail I must agree that this is what happened.
> Would you mind putting the change back to incomplete state and resend it
> once more for feedback once this is addressed?
>
>> The first and most important of these is that ELN will*not* be
>> building the complete Fedora package set. We're going to be building a
>> selected subset of packages (derived from packages in RHEL 8 and
>> EPEL). Our current expectation is that we are going to be looking at
>> fewer than 2500 source packages. We are still working up the initial
>> list of these and we will update the Change Proposal with it (as well
>> as providing a fedora-devel post breaking down the known owners).
>
> Glad to hear that.
>
>> Second, from this reduced subset, we expect that the overwhelming
>> majority of the maintainers are Red Hat employees that already work on
>> RHEL. With this in mind, we think that the level of concern about how
>> this will affect non-Red Hat contributors is premature. We will reach
>> out directly to those non-Red Hat contributors we identify.
This actually worries me very much.
The subset of packages will need to form a working system; it will
include the most important packages. I hope this doesn't end up limiting
maintainers of Fedora's most central packages to only Red Hatters or
those that agree to play by RHEL rules that they have no say in.
I am pretty sure that most packages/packagers will be OK with the ELN
change. But "most" is not enough. We do need to take the "worst
cases"
into account. Consider a package that:
- is needed in RHEL, but only as a dependency of something vital; the
RHEL maintainer doesn't care too much about it outside their work duties
- has an enthusiastic packager in Fedora, who prefers to leave RHEL work
to paid developers
(As member of a team that, some time ago, used to be catch-all RHEL
maintainer for anything that happened to be written in Python, I can
definitely imagine situations similar to this.)
For such a package, we need to avoid pushing ELN macros into the
package, otherwise we lose an enthusiastic contributor who does amazing
work in Fedora.
Such a package might even be hypothetical right now, but the case still
needs to be adressed. A package can fall into this category at any time
in the future. It's not enough to identifying packagers that are
affected now, and work with them. There needs to be a process for cases
like these, and it can't be "merge these ELN macros now, there's a
deadline coming; maybe we'll come up with a better process in the
future". (Especially if Red Hat is unlikely to drive setting up a better
process.)
IMO, any changes needed in EL need to be opt-in, with the understanding
that opting in will be (almost always) beneficial for everyone involved.
They need to feel like a gift ("Hello fedora packager, please accept
this PR with EL macros; it'll make it easier to work on this together!")
rather than forced ("Red Hat needs this; merge it or else").
I wonder how we ended up with people feeling like we are proposing
latter rather than the former.
I guess I took couple of wrong turns in this discussion, and I'd like
to step back and try again.
Me, Stephen and Troy are going to update the proposal, and come up
with a better description of how opt-in will look like.
To borrow Neal Gompa's words, ELN needs to not feel "like
it's written
for Red Hat people to move their sandbox outside of Red Hat into Fedora
without anyone else to be able to play in the sandbox."
For ELN changes to be to be opt-in, there essentially needs to be a
place to diverge -- a place for ELN hotfixes to live while polishing
them and debating their usefulness in Fedora and further upstreams.
Here by "hotfix" I need something required in RHEL that is not yet ready
for upstream. It is healthy to have a place for such things: it removes
time pressure from discussions (people from the community very often
have good ideas but less time), but allows the fix to be used now (so
the rest of ELN isn't blocked).
Forks are good if they're not permanent (but, making them not permanent
needs effort).
As Miro Hrončok continues:
> As a Red employee if I need to diverge a RHEL package from Fedora, I
> prefer to use branches as well. And I know for a fact I am not alone in
> this. Please don't forget to identify and reach out to Red Hat
> contributors as well, not just the non-Red Hat contributors.
>
> [Stephen Gallagher]:
>> Finally, of the set of packages that we're going to be including, we
>> anticipate around 200-300 of them will have distro conditionals that
>> need investigation (with fewer needing actual modification). The ELN
>> SIG will be doing this initial investigation and will provide guidance
>> (and/or PRs) to affected packagers.
What would IMO help would be tracking all such divergences from Fedora
as bugs/issues on the Red Hat side, and spending effort to triage them,
polish them and discuss them with the community. Not as initial
investigation, but ongoing effort.
Yes, this is what ELN SIG supposed to be doing. It is not something we
can just turn on once.
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
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@lists.fedoraproject.org
--
Aleksandra Fedorova
bookwar
10:13 a.m.
On 25. 03. 20 17:10, Miro Hrončok wrote:
>
Finally, of the set of packages that we're going to be including, we
> anticipate around 200-300 of them will have distro conditionals that
> need investigation (with fewer needing actual modification). The ELN
> SIG will be doing this initial investigation and will provide guidance
> (and/or PRs) to affected packagers.
My concerns still remain, although I am now not so scared that this will
alienate the community. Now the concern is more personal (= previously I was
worried that everybody will be encouraged to use the conditionals, while now I'm
mostly concerned they I will be encouraged to use the conditionals).
Also, to make this more clear:
I am not worried about the conditionals because I would need to maintain them.
I am worried that "my" packages will be harder to co-maintain (or generally
changed) by people from the community.
As an example, I will know the RHEL 9 (10, 11...) plans and I can structure my
specs accordingly. However if there is a passionate Fedora contributor who would
like so submit a Pull Request for e.g. python-virtualenv to update it to a new
fancy version that does things differently, they are not familiar about our RHEL
plans and they would not be capable to wrap their head around such conditionals.
They would also need to rebase any RHEL-only patches for this to work. At the
end, they are more likely to just go away and not do it at all.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
6:32 a.m.
On 26. 03. 20 16:13, Miro Hrončok wrote:
On 25. 03. 20 17:10, Miro Hrončok wrote:
>> Finally, of the set of packages that we're going to be including, we
>> anticipate around 200-300 of them will have distro conditionals that
>> need investigation (with fewer needing actual modification). The ELN
>> SIG will be doing this initial investigation and will provide guidance
>> (and/or PRs) to affected packagers.
>
> My concerns still remain, although I am now not so scared that this will
> alienate the community. Now the concern is more personal (= previously I was
> worried that everybody will be encouraged to use the conditionals, while now
> I'm mostly concerned they I will be encouraged to use the conditionals).
Also, to make this more clear:
I am not worried about the conditionals because I would need to maintain them.
I am worried that "my" packages will be harder to co-maintain (or generally
changed) by people from the community.
As an example, I will know the RHEL 9 (10, 11...) plans and I can structure my
specs accordingly. However if there is a passionate Fedora contributor who would
like so submit a Pull Request for e.g. python-virtualenv to update it to a new
fancy version that does things differently, they are not familiar about our RHEL
plans and they would not be capable to wrap their head around such conditionals.
They would also need to rebase any RHEL-only patches for this to work. At the
end, they are more likely to just go away and not do it at all.
Another example. In a corporate meeting with the product owners/managers, we
decide that the next major RHEL release will include Brainfuck 7 because it an
LTS release. Fedora rawhide is updated to Brainfuck 7 and everything is nice and
fine.
Later, Brainfuck 8 is released. The Fedora community wants this new version,
because it finally has a support for Brainloller and the Ook! stack depends on
this new feature. The Ook! stack is not planned to be in RHEL, so from RHEL
perspective, this new feature is not that important. But the Ook! SIG obviously
wants this.
The RHEL maintainer now needs to artificially block the Brainfuck 8 update from
rawhide until next RHEL is branched (they probably cannot even share when this
is going to be with the Fedora community because NDA). This prevents the "First"
foundation of Fedora (and TBH it also prevents "Friends", the RHEL maintainer is
actively blocking the Ook SIG here by their (in)action).
The conditional approach will only allow this:
%if 0%{?rhel}
Version: 7.4.5
%else
Version: 8.0.0~rc1
%endif
(And I assume the rest of the spec file would need major %if/%else mess as well,
because Brainfuck 8 is built with meson, while Brainfuck 7 is built with
autotools. Or the implementation language changed from C to Rust...)
And trust me, you don't want to maintain that. It is not maintainable. And it
has problems like this:
https://pagure.io/copr/copr/issue/1315
Another approach is compat packages, but Brainfuck 8 is backwards compatible
with 7, so it brings no benefit for Fedora.
Another approach is modularity, but the Ook! SIG doesn't want to use modules
because they want their Ook-based apps to be easily available to Fedora users.
Sorry for going artificial with the example, but I didn't want you to say "you
are always talking about Python, what you say is Python specific" -- because it
isn't.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
6:40 a.m.
Dne 27. 03. 20 v 12:32 Miro Hrončok napsal(a):
And trust me, you don't want to maintain that. It is not maintainable.
And it has problems like this:
https://pagure.io/copr/copr/issue/1315
Heh, nice one :) Thanks for sharing
Vít
7:03 a.m.
On 3/27/20 1:32 PM, Miro Hrončok wrote:
The conditional approach will only allow this:
%if 0%{?rhel}
Version: 7.4.5
%else
Version: 8.0.0~rc1
%endif
(And I assume the rest of the spec file would need major %if/%else mess
as well, because Brainfuck 8 is built with meson, while Brainfuck 7 is
built with autotools. Or the implementation language changed from C to
Rust...)
And trust me, you don't want to maintain that. It is not maintainable.
And it has problems like this:
https://pagure.io/copr/copr/issue/1315
Ough.
- Panu -
8:28 a.m.
Hi, Miro,
On Fri, Mar 27, 2020 at 12:35 PM Miro Hrončok <mhroncok(a)redhat.com> wrote:
On 26. 03. 20 16:13, Miro Hrončok wrote:
> On 25. 03. 20 17:10, Miro Hrončok wrote:
>>> Finally, of the set of packages that we're going to be including, we
>>> anticipate around 200-300 of them will have distro conditionals that
>>> need investigation (with fewer needing actual modification). The ELN
>>> SIG will be doing this initial investigation and will provide guidance
>>> (and/or PRs) to affected packagers.
>>
>> My concerns still remain, although I am now not so scared that this will
>> alienate the community. Now the concern is more personal (= previously I was
>> worried that everybody will be encouraged to use the conditionals, while now
>> I'm mostly concerned they I will be encouraged to use the conditionals).
>
> Also, to make this more clear:
>
> I am not worried about the conditionals because I would need to maintain them.
>
> I am worried that "my" packages will be harder to co-maintain (or
generally
> changed) by people from the community.
>
> As an example, I will know the RHEL 9 (10, 11...) plans and I can structure my
> specs accordingly. However if there is a passionate Fedora contributor who would
> like so submit a Pull Request for e.g. python-virtualenv to update it to a new
> fancy version that does things differently, they are not familiar about our RHEL
> plans and they would not be capable to wrap their head around such conditionals.
> They would also need to rebase any RHEL-only patches for this to work. At the
> end, they are more likely to just go away and not do it at all.
Another example. In a corporate meeting with the product owners/managers, we
decide that the next major RHEL release will include Brainfuck 7 because it an
LTS release. Fedora rawhide is updated to Brainfuck 7 and everything is nice and
fine.
Later, Brainfuck 8 is released. The Fedora community wants this new version,
because it finally has a support for Brainloller and the Ook! stack depends on
this new feature. The Ook! stack is not planned to be in RHEL, so from RHEL
perspective, this new feature is not that important. But the Ook! SIG obviously
wants this.
The RHEL maintainer now needs to artificially block the Brainfuck 8 update from
rawhide until next RHEL is branched (they probably cannot even share when this
is going to be with the Fedora community because NDA). This prevents the
"First"
foundation of Fedora (and TBH it also prevents "Friends", the RHEL maintainer
is
actively blocking the Ook SIG here by their (in)action).
The conditional approach will only allow this:
%if 0%{?rhel}
Version: 7.4.5
%else
Version: 8.0.0~rc1
%endif
(And I assume the rest of the spec file would need major %if/%else mess as well,
because Brainfuck 8 is built with meson, while Brainfuck 7 is built with
autotools. Or the implementation language changed from C to Rust...)
Thank you for bringing this example.
I agree with your point that in case of choices like this,
conditionals do not make sense. It is a branch. But this branch in my
opinion has nothing to do with ELN.
ELN is not RHEL. It is a development tool, which gives us a preview,
so that we can plan the work better. We are not planning to release
RHEL from ELN packages.
Therefore ELN is all about the form, not the content. The goal of this
project is to apply downstream form to Fedora Rawhide content and see
what issues RHEL or downstream in general will have in the future. But
the work itself doesn't always have to happen in Fedora Rawhide. ELN
doesn't bring any new changes here, as you keep working with upstream
and downstream the way you as package maintainer worked before.
So while we may ask for some adjustments to Fedora spec files to fit
into that EL-form, these adjustments are structural. And in the case
you have described I am against branching not because I would like to
have conditional instead, but because I don't want to fork Fedora
Rawhide content into something else in ELN at all.
I think the kind of branching you have described should happen
somewhere down the line, in RHEL(CentOS Stream maybe).
And trust me, you don't want to maintain that. It is not
maintainable. And it
has problems like this:
https://pagure.io/copr/copr/issue/1315
If I understand it correctly, this only illustrates the issue which
may happen, not the example itself. As the reasons to have conditional
in that particular spec file are not relevant to ELN.
Another approach is compat packages, but Brainfuck 8 is backwards
compatible
with 7, so it brings no benefit for Fedora.
Another approach is modularity, but the Ook! SIG doesn't want to use modules
because they want their Ook-based apps to be easily available to Fedora users.
Sorry for going artificial with the example, but I didn't want you to say "you
are always talking about Python, what you say is Python specific" -- because it
isn't.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
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@lists.fedoraproject.org
--
Aleksandra Fedorova
bookwar
12:29 p.m.
On 3/25/20 4:47 PM, Stephen Gallagher wrote:
Starting a new sub-thread.
On Tue, Mar 24, 2020 at 5:33 AM Aleksandra Fedorova <alpha(a)bookwar.info> wrote:
> As Ben is on PTO, I'd like to present the System-Wide Change
>
> https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
>
> == Summary ==
>
> The goal of the ELN project is to continuously build Fedora Rawhide
> packages and composes in the way which resembles the CentOS and RHEL
> build process and to provide a feedback loop for Fedora maintainers on
> the status of those builds.
I think we managed to miss a few key points in the Change Proposal
which is directly resulting in a bit of the confusion here.
The first and most important of these is that ELN will *not* be
building the complete Fedora package set. We're going to be building a
selected subset of packages (derived from packages in RHEL 8 and
EPEL). Our current expectation is that we are going to be looking at
fewer than 2500 source packages.We are still working up the initial
list of these and we will update the Change Proposal with it (as well
as providing a fedora-devel post breaking down the known owners).
Second, from this reduced subset, we expect that the overwhelming
majority of the maintainers are Red Hat employees that already work on
RHEL. With this in mind, we think that the level of concern about how
this will affect non-Red Hat contributors is premature. We will reach
out directly to those non-Red Hat contributors we identify.
Finally, of the set of packages that we're going to be including, we
anticipate around 200-300 of them will have distro conditionals that
need investigation (with fewer needing actual modification). The ELN
SIG will be doing this initial investigation and will provide guidance
(and/or PRs) to affected packagers.
Above you indicate that you're looking at fewer than 2500 source
packages, but you expect only 200-300 to have distro conditionals. I
find that rather optimistic that only ~ %10 of the packages will need
conditionals. With such a small initial set, the likelihood is great
that a given package will have at least one missing BuildRequires (there
are no "BuildRecommends" tags to use). Especially since due to the small
package set, a lot of test dependencies will have to be left out.
As others have pointed out, when these conditionals are *required* for
ELN to be built, we can't count on every package maintainer
*voluntarily* agreeing to have them in rawhide. And the added complexity
to maintainers is all too real. If your spec file is used to build 2
builds, good maintainers will feel obligated to make sure any change
doesn't break either of those builds. Which means that they have to know
how ELN works, where it builds and how to test it.
I fully support the proposed solution to have a separate branch, which
can just symbolically point to rawhide if not needed. It's important to
give people a choice.
Tomas
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
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@lists.fedoraproject.org
10:46 a.m.
On Tue, Mar 24, 2020 at 10:32:26AM +0100, Aleksandra Fedorova wrote:
As Ben is on PTO, I'd like to present the System-Wide Change
https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
[snip]
It has taken me some time, but I have read through the entire thread in
addition to the change proposal. The idea sounds really interesting to me and
a lot of points have come up on the thread. I decided to group my responses
together as this single email after reading through the entire thread to make
it a bit easier to read (and to write).
TL;DR -- I think this proposal should be broken up in to 2 proposals
The turning point for me in the change proposal was the discussion of the RPM
spec file macros and getting in to the mechanics of how ELN will work. It
looks like a lot of other people had the same reaction because many of the
responses get in to the technical details and for some questions, there are no
answers yet. After thinking about it for a while, it would make sense to me
to have ELN come up in multiple phases/proposals.
Suggested Proposals:
1) ELN buildroot and install media
In this proposal, I'd like to see the ELN buildroot defined, the Koji
changes implemented, the automated builds implemented, and install media
composes happening.
The expectation here should be that it is rough around the edges. But
doing this gives the community something to see, use, and discuss further
when reviewing the next change proposals.
We should have some community goals with this proposal to capture a list of
EL vs. Fedora differences and how to address those per package and in the
context of ELN.
2) ELN lifecycle
This gets in to more of the mechanics of how ELN builds can be handled by
the community. I do not think there is a one size fits all and we should
give developers control over how best to handle this for the packages they
maintain.
The spec file macros, git branch ideas, inheritance, pull request workflow,
what builds block what composes, who is responsible for ELN failures, and
other expectations of package maintainers (both Fedora and RHEL) should be
discussed here. This proposal is definitely the policy side of things, but
I think it would be easier to talk about after #1 is done.
Having seen multiple efforts to do a "RHEL rawhide" in a way (one even called
rhel-rawhide at one point), the ELN idea is one where the work is being
targeted in the right place. As a Fedora contributor, I see RHEL as a
customer and if we can make their work easier, I want to do that. As a RHEL
package maintainer, I see Fedora as a place where I can make my job easier as
a RHEL package maintainer. The more things we get right on the community side
of things, the easier it is to produce RHEL.
Various comments from reading the thread:
* I'm not crazy about the %{?rhel} macro name. I would prefer we use 'el'
instead to cover RHEL and CentOS and EPEL. Or at least have a 'el' macro
that covers all three of those.
* I prefer the '.eln' dist tag carry a number indicating N+1 from the RHEL
major release. This should be ok in the community since Red Hat ultimately
makes the decision to version RHEL. This is an engineering decision and I
think it would help imply that ELN is _not_ meant for current RHEL. This
also lets us entertain the idea of multiple ELN major versions concurrently
should we ever want to do that.
* There has to be a deliverable for ELN. What I would prefer is a live or
install .iso. Something I can install on a spare system or in a virt
guest. If it is only available as a buildroot in Koji, that becomes "black
box" development which makes me less interested in working on it.
* There were a lot of comments about build differences between RHEL and Fedora
where certain features are disabled or build dependencies reduced (e.g.,
docs). I think this is something that the community could even discuss
rearchitecting at the package level in Fedora. Things like vim-minimal, for
instance. Having different packages built with different features
enabled/disabled. Some of these things may be easiest handled with macros
and others might be something we could handle by refactoring the packages
themselves.
* Regardless of the mechanics, there is going to be more work here. We all
need to understand the expectations of the work required of a package
maintainer and how best to coordinate with RHEL downstream. In many cases,
the package maintainers between RHEL and Fedora are the same. But in many
other cases they are not. As a community we should set some clear
guidelines on where the responsibility lies and have the right communication
workflow in place to make sure that's easy for everyone.
* On that same note, RHEL package maintainers should have an expectation to
co-maintain the corresponding package(s) in Fedora if they do not already.
Most of my comments here are on the mechanics, but before getting in to that
I'd like to see proposal #1 in some form happen first. I'd like to talk about
the actual details once I have download an ELN iso and installed in a virt
guest.
This is a huge effort and I appreciate the proposal and discussion so far.
I've wanted something like this in Fedora for a long time simply because it
makes RHEL easier to work on.
Thanks,
--
David Cantrell <dcantrell(a)redhat.com>
Red Hat, Inc. | Boston, MA | EST5EDT
1:48 p.m.
On Fri, Mar 27, 2020 at 10:47 AM David Cantrell <dcantrell(a)redhat.com> wrote:
On Tue, Mar 24, 2020 at 10:32:26AM +0100, Aleksandra Fedorova wrote:
>As Ben is on PTO, I'd like to present the System-Wide Change
>
>https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
[snip]
It has taken me some time, but I have read through the entire thread in
addition to the change proposal. The idea sounds really interesting to me and
a lot of points have come up on the thread. I decided to group my responses
together as this single email after reading through the entire thread to make
it a bit easier to read (and to write).
TL;DR -- I think this proposal should be broken up in to 2 proposals
The turning point for me in the change proposal was the discussion of the RPM
spec file macros and getting in to the mechanics of how ELN will work. It
looks like a lot of other people had the same reaction because many of the
responses get in to the technical details and for some questions, there are no
answers yet. After thinking about it for a while, it would make sense to me
to have ELN come up in multiple phases/proposals.
Suggested Proposals:
1) ELN buildroot and install media
In this proposal, I'd like to see the ELN buildroot defined, the Koji
changes implemented, the automated builds implemented, and install media
composes happening.
The expectation here should be that it is rough around the edges. But
doing this gives the community something to see, use, and discuss further
when reviewing the next change proposals.
We should have some community goals with this proposal to capture a list of
EL vs. Fedora differences and how to address those per package and in the
context of ELN.
2) ELN lifecycle
This gets in to more of the mechanics of how ELN builds can be handled by
the community. I do not think there is a one size fits all and we should
give developers control over how best to handle this for the packages they
maintain.
The spec file macros, git branch ideas, inheritance, pull request workflow,
what builds block what composes, who is responsible for ELN failures, and
other expectations of package maintainers (both Fedora and RHEL) should be
discussed here. This proposal is definitely the policy side of things, but
I think it would be easier to talk about after #1 is done.
Having seen multiple efforts to do a "RHEL rawhide" in a way (one even called
rhel-rawhide at one point), the ELN idea is one where the work is being
targeted in the right place. As a Fedora contributor, I see RHEL as a
customer and if we can make their work easier, I want to do that. As a RHEL
package maintainer, I see Fedora as a place where I can make my job easier as
a RHEL package maintainer. The more things we get right on the community side
of things, the easier it is to produce RHEL.
Various comments from reading the thread:
* I'm not crazy about the %{?rhel} macro name. I would prefer we use 'el'
instead to cover RHEL and CentOS and EPEL. Or at least have a 'el' macro
that covers all three of those.
The %{?rhel} macro name currently exists and is in use in some
packages as I recall.
* I prefer the '.eln' dist tag carry a number indicating N+1
from the RHEL
major release. This should be ok in the community since Red Hat ultimately
makes the decision to version RHEL. This is an engineering decision and I
think it would help imply that ELN is _not_ meant for current RHEL. This
also lets us entertain the idea of multiple ELN major versions concurrently
should we ever want to do that.
I rather equate this to RHELhide, it should be evolving. Once N is
branched (CentOS?) and moving on, this is N+1. This is the rolling
development location.
2:08 p.m.
On Fri, Mar 27, 2020 at 01:48:15PM -0500, Justin Forbes wrote:
On Fri, Mar 27, 2020 at 10:47 AM David Cantrell
<dcantrell(a)redhat.com> wrote:
>
> On Tue, Mar 24, 2020 at 10:32:26AM +0100, Aleksandra Fedorova wrote:
> >As Ben is on PTO, I'd like to present the System-Wide Change
> >
> >https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
> [snip]
>
> It has taken me some time, but I have read through the entire thread in
> addition to the change proposal. The idea sounds really interesting to me and
> a lot of points have come up on the thread. I decided to group my responses
> together as this single email after reading through the entire thread to make
> it a bit easier to read (and to write).
>
> TL;DR -- I think this proposal should be broken up in to 2 proposals
>
> The turning point for me in the change proposal was the discussion of the RPM
> spec file macros and getting in to the mechanics of how ELN will work. It
> looks like a lot of other people had the same reaction because many of the
> responses get in to the technical details and for some questions, there are no
> answers yet. After thinking about it for a while, it would make sense to me
> to have ELN come up in multiple phases/proposals.
>
> Suggested Proposals:
>
> 1) ELN buildroot and install media
>
> In this proposal, I'd like to see the ELN buildroot defined, the Koji
> changes implemented, the automated builds implemented, and install media
> composes happening.
>
> The expectation here should be that it is rough around the edges. But
> doing this gives the community something to see, use, and discuss further
> when reviewing the next change proposals.
>
> We should have some community goals with this proposal to capture a list of
> EL vs. Fedora differences and how to address those per package and in the
> context of ELN.
>
> 2) ELN lifecycle
>
> This gets in to more of the mechanics of how ELN builds can be handled by
> the community. I do not think there is a one size fits all and we should
> give developers control over how best to handle this for the packages they
> maintain.
>
> The spec file macros, git branch ideas, inheritance, pull request workflow,
> what builds block what composes, who is responsible for ELN failures, and
> other expectations of package maintainers (both Fedora and RHEL) should be
> discussed here. This proposal is definitely the policy side of things, but
> I think it would be easier to talk about after #1 is done.
>
> Having seen multiple efforts to do a "RHEL rawhide" in a way (one even
called
> rhel-rawhide at one point), the ELN idea is one where the work is being
> targeted in the right place. As a Fedora contributor, I see RHEL as a
> customer and if we can make their work easier, I want to do that. As a RHEL
> package maintainer, I see Fedora as a place where I can make my job easier as
> a RHEL package maintainer. The more things we get right on the community side
> of things, the easier it is to produce RHEL.
>
> Various comments from reading the thread:
>
> * I'm not crazy about the %{?rhel} macro name. I would prefer we use
'el'
> instead to cover RHEL and CentOS and EPEL. Or at least have a 'el' macro
> that covers all three of those.
>
The %{?rhel} macro name currently exists and is in use in some
packages as I recall.
Sorry, what I meant was I'm not crazy about the %{?rhel} macro for this work.
I would prefer a new macro for the ELN work to distinguish it from the
existing macros.
> * I prefer the '.eln' dist tag carry a number indicating
N+1 from the RHEL
> major release. This should be ok in the community since Red Hat ultimately
> makes the decision to version RHEL. This is an engineering decision and I
> think it would help imply that ELN is _not_ meant for current RHEL. This
> also lets us entertain the idea of multiple ELN major versions concurrently
> should we ever want to do that.
>
I rather equate this to RHELhide, it should be evolving. Once N is
branched (CentOS?) and moving on, this is N+1. This is the rolling
development location.
I agree. The 'N' value seen in this dist tag should always be greater than
the latest major version we see for RHEL and CentOS.
Thanks,
--
David Cantrell <dcantrell(a)redhat.com>
Red Hat, Inc. | Boston, MA | EST5EDT
2:20 p.m.
On Fri, Mar 27, 2020 at 2:09 PM David Cantrell <dcantrell(a)redhat.com> wrote:
On Fri, Mar 27, 2020 at 01:48:15PM -0500, Justin Forbes wrote:
>On Fri, Mar 27, 2020 at 10:47 AM David Cantrell <dcantrell(a)redhat.com> wrote:
>>
>> On Tue, Mar 24, 2020 at 10:32:26AM +0100, Aleksandra Fedorova wrote:
>> >As Ben is on PTO, I'd like to present the System-Wide Change
>> >
>> >https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
>> [snip]
>>
>> It has taken me some time, but I have read through the entire thread in
>> addition to the change proposal. The idea sounds really interesting to me and
>> a lot of points have come up on the thread. I decided to group my responses
>> together as this single email after reading through the entire thread to make
>> it a bit easier to read (and to write).
>>
>> TL;DR -- I think this proposal should be broken up in to 2 proposals
>>
>> The turning point for me in the change proposal was the discussion of the RPM
>> spec file macros and getting in to the mechanics of how ELN will work. It
>> looks like a lot of other people had the same reaction because many of the
>> responses get in to the technical details and for some questions, there are no
>> answers yet. After thinking about it for a while, it would make sense to me
>> to have ELN come up in multiple phases/proposals.
>>
>> Suggested Proposals:
>>
>> 1) ELN buildroot and install media
>>
>> In this proposal, I'd like to see the ELN buildroot defined, the Koji
>> changes implemented, the automated builds implemented, and install media
>> composes happening.
>>
>> The expectation here should be that it is rough around the edges. But
>> doing this gives the community something to see, use, and discuss further
>> when reviewing the next change proposals.
>>
>> We should have some community goals with this proposal to capture a list of
>> EL vs. Fedora differences and how to address those per package and in the
>> context of ELN.
>>
>> 2) ELN lifecycle
>>
>> This gets in to more of the mechanics of how ELN builds can be handled by
>> the community. I do not think there is a one size fits all and we should
>> give developers control over how best to handle this for the packages they
>> maintain.
>>
>> The spec file macros, git branch ideas, inheritance, pull request workflow,
>> what builds block what composes, who is responsible for ELN failures, and
>> other expectations of package maintainers (both Fedora and RHEL) should be
>> discussed here. This proposal is definitely the policy side of things, but
>> I think it would be easier to talk about after #1 is done.
>>
>> Having seen multiple efforts to do a "RHEL rawhide" in a way (one even
called
>> rhel-rawhide at one point), the ELN idea is one where the work is being
>> targeted in the right place. As a Fedora contributor, I see RHEL as a
>> customer and if we can make their work easier, I want to do that. As a RHEL
>> package maintainer, I see Fedora as a place where I can make my job easier as
>> a RHEL package maintainer. The more things we get right on the community side
>> of things, the easier it is to produce RHEL.
>>
>> Various comments from reading the thread:
>>
>> * I'm not crazy about the %{?rhel} macro name. I would prefer we use
'el'
>> instead to cover RHEL and CentOS and EPEL. Or at least have a 'el'
macro
>> that covers all three of those.
>>
>
>The %{?rhel} macro name currently exists and is in use in some
>packages as I recall.
Sorry, what I meant was I'm not crazy about the %{?rhel} macro for this work.
I would prefer a new macro for the ELN work to distinguish it from the
existing macros.
>> * I prefer the '.eln' dist tag carry a number indicating N+1 from the
RHEL
>> major release. This should be ok in the community since Red Hat ultimately
>> makes the decision to version RHEL. This is an engineering decision and I
>> think it would help imply that ELN is _not_ meant for current RHEL. This
>> also lets us entertain the idea of multiple ELN major versions concurrently
>> should we ever want to do that.
>>
>
>I rather equate this to RHELhide, it should be evolving. Once N is
>branched (CentOS?) and moving on, this is N+1. This is the rolling
>development location.
I agree. The 'N' value seen in this dist tag should always be greater than
the latest major version we see for RHEL and CentOS.
Sorry, I wasn't clear. I mean that the rhelhide/evolving nature of
this seems it should carry no number, similar to the rawhide it is
inheriting from. Let them deal with numbers in CentOS and RHEL.
Justin
2:32 p.m.
On 27. 03. 20 20:20, Justin Forbes wrote:
Sorry, I wasn't clear. I mean that the rhelhide/evolving nature
of
this seems it should carry no number, similar to the rawhide it is
inheriting from. Let them deal with numbers in CentOS and RHEL.
But rawhide also has a number (currently 33).
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
3:49 p.m.
On Fri, Mar 27, 2020 at 02:20:29PM -0500, Justin Forbes wrote:
On Fri, Mar 27, 2020 at 2:09 PM David Cantrell
<dcantrell(a)redhat.com> wrote:
>
> On Fri, Mar 27, 2020 at 01:48:15PM -0500, Justin Forbes wrote:
> >On Fri, Mar 27, 2020 at 10:47 AM David Cantrell <dcantrell(a)redhat.com>
wrote:
> >>
> >> On Tue, Mar 24, 2020 at 10:32:26AM +0100, Aleksandra Fedorova wrote:
> >> >As Ben is on PTO, I'd like to present the System-Wide Change
> >> >
> >> >https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
> >> [snip]
> >>
> >> It has taken me some time, but I have read through the entire thread in
> >> addition to the change proposal. The idea sounds really interesting to me
and
> >> a lot of points have come up on the thread. I decided to group my
responses
> >> together as this single email after reading through the entire thread to
make
> >> it a bit easier to read (and to write).
> >>
> >> TL;DR -- I think this proposal should be broken up in to 2 proposals
> >>
> >> The turning point for me in the change proposal was the discussion of the
RPM
> >> spec file macros and getting in to the mechanics of how ELN will work. It
> >> looks like a lot of other people had the same reaction because many of the
> >> responses get in to the technical details and for some questions, there are
no
> >> answers yet. After thinking about it for a while, it would make sense to
me
> >> to have ELN come up in multiple phases/proposals.
> >>
> >> Suggested Proposals:
> >>
> >> 1) ELN buildroot and install media
> >>
> >> In this proposal, I'd like to see the ELN buildroot defined, the
Koji
> >> changes implemented, the automated builds implemented, and install
media
> >> composes happening.
> >>
> >> The expectation here should be that it is rough around the edges. But
> >> doing this gives the community something to see, use, and discuss
further
> >> when reviewing the next change proposals.
> >>
> >> We should have some community goals with this proposal to capture a list
of
> >> EL vs. Fedora differences and how to address those per package and in
the
> >> context of ELN.
> >>
> >> 2) ELN lifecycle
> >>
> >> This gets in to more of the mechanics of how ELN builds can be handled
by
> >> the community. I do not think there is a one size fits all and we
should
> >> give developers control over how best to handle this for the packages
they
> >> maintain.
> >>
> >> The spec file macros, git branch ideas, inheritance, pull request
workflow,
> >> what builds block what composes, who is responsible for ELN failures,
and
> >> other expectations of package maintainers (both Fedora and RHEL) should
be
> >> discussed here. This proposal is definitely the policy side of things,
but
> >> I think it would be easier to talk about after #1 is done.
> >>
> >> Having seen multiple efforts to do a "RHEL rawhide" in a way (one
even called
> >> rhel-rawhide at one point), the ELN idea is one where the work is being
> >> targeted in the right place. As a Fedora contributor, I see RHEL as a
> >> customer and if we can make their work easier, I want to do that. As a
RHEL
> >> package maintainer, I see Fedora as a place where I can make my job easier
as
> >> a RHEL package maintainer. The more things we get right on the community
side
> >> of things, the easier it is to produce RHEL.
> >>
> >> Various comments from reading the thread:
> >>
> >> * I'm not crazy about the %{?rhel} macro name. I would prefer we use
'el'
> >> instead to cover RHEL and CentOS and EPEL. Or at least have a
'el' macro
> >> that covers all three of those.
> >>
> >
> >The %{?rhel} macro name currently exists and is in use in some
> >packages as I recall.
>
> Sorry, what I meant was I'm not crazy about the %{?rhel} macro for this work.
> I would prefer a new macro for the ELN work to distinguish it from the
> existing macros.
>
> >> * I prefer the '.eln' dist tag carry a number indicating N+1 from
the RHEL
> >> major release. This should be ok in the community since Red Hat
ultimately
> >> makes the decision to version RHEL. This is an engineering decision and
I
> >> think it would help imply that ELN is _not_ meant for current RHEL.
This
> >> also lets us entertain the idea of multiple ELN major versions
concurrently
> >> should we ever want to do that.
> >>
> >
> >I rather equate this to RHELhide, it should be evolving. Once N is
> >branched (CentOS?) and moving on, this is N+1. This is the rolling
> >development location.
>
> I agree. The 'N' value seen in this dist tag should always be greater than
> the latest major version we see for RHEL and CentOS.
Sorry, I wasn't clear. I mean that the rhelhide/evolving nature of
this seems it should carry no number, similar to the rawhide it is
inheriting from. Let them deal with numbers in CentOS and RHEL.
I find it useful to have that information in the dist tag so that you can see
a built package and have an idea of when it was built.
--
David Cantrell <dcantrell(a)redhat.com>
Red Hat, Inc. | Boston, MA | EST5EDT
5:06 a.m.
On Fri, Mar 27, 2020 at 8:09 PM David Cantrell <dcantrell(a)redhat.com> wrote:
On Fri, Mar 27, 2020 at 01:48:15PM -0500, Justin Forbes wrote:
>On Fri, Mar 27, 2020 at 10:47 AM David Cantrell <dcantrell(a)redhat.com> wrote:
>>
>> On Tue, Mar 24, 2020 at 10:32:26AM +0100, Aleksandra Fedorova wrote:
>> >As Ben is on PTO, I'd like to present the System-Wide Change
>> >
>> >https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
>> [snip]
>>
>> It has taken me some time, but I have read through the entire thread in
>> addition to the change proposal. The idea sounds really interesting to me and
>> a lot of points have come up on the thread. I decided to group my responses
>> together as this single email after reading through the entire thread to make
>> it a bit easier to read (and to write).
>>
>> TL;DR -- I think this proposal should be broken up in to 2 proposals
>>
>> The turning point for me in the change proposal was the discussion of the RPM
>> spec file macros and getting in to the mechanics of how ELN will work. It
>> looks like a lot of other people had the same reaction because many of the
>> responses get in to the technical details and for some questions, there are no
>> answers yet. After thinking about it for a while, it would make sense to me
>> to have ELN come up in multiple phases/proposals.
>>
>> Suggested Proposals:
>>
>> 1) ELN buildroot and install media
>>
>> In this proposal, I'd like to see the ELN buildroot defined, the Koji
>> changes implemented, the automated builds implemented, and install media
>> composes happening.
>>
>> The expectation here should be that it is rough around the edges. But
>> doing this gives the community something to see, use, and discuss further
>> when reviewing the next change proposals.
>>
>> We should have some community goals with this proposal to capture a list of
>> EL vs. Fedora differences and how to address those per package and in the
>> context of ELN.
>>
>> 2) ELN lifecycle
>>
>> This gets in to more of the mechanics of how ELN builds can be handled by
>> the community. I do not think there is a one size fits all and we should
>> give developers control over how best to handle this for the packages they
>> maintain.
>>
>> The spec file macros, git branch ideas, inheritance, pull request workflow,
>> what builds block what composes, who is responsible for ELN failures, and
>> other expectations of package maintainers (both Fedora and RHEL) should be
>> discussed here. This proposal is definitely the policy side of things, but
>> I think it would be easier to talk about after #1 is done.
>>
>> Having seen multiple efforts to do a "RHEL rawhide" in a way (one even
called
>> rhel-rawhide at one point), the ELN idea is one where the work is being
>> targeted in the right place. As a Fedora contributor, I see RHEL as a
>> customer and if we can make their work easier, I want to do that. As a RHEL
>> package maintainer, I see Fedora as a place where I can make my job easier as
>> a RHEL package maintainer. The more things we get right on the community side
>> of things, the easier it is to produce RHEL.
>>
>> Various comments from reading the thread:
>>
>> * I'm not crazy about the %{?rhel} macro name. I would prefer we use
'el'
>> instead to cover RHEL and CentOS and EPEL. Or at least have a 'el'
macro
>> that covers all three of those.
>>
>
>The %{?rhel} macro name currently exists and is in use in some
>packages as I recall.
Sorry, what I meant was I'm not crazy about the %{?rhel} macro for this work.
I would prefer a new macro for the ELN work to distinguish it from the
existing macros.
>> * I prefer the '.eln' dist tag carry a number indicating N+1 from the
RHEL
>> major release. This should be ok in the community since Red Hat ultimately
>> makes the decision to version RHEL. This is an engineering decision and I
>> think it would help imply that ELN is _not_ meant for current RHEL. This
>> also lets us entertain the idea of multiple ELN major versions concurrently
>> should we ever want to do that.
>>
Numbering by RHEL versions can not be done based on RHEL release
dates. Because RHEL stops consuming Fedora Rawhide code much earlier.
To implement such numbering properly we would need to have a
coordination with RHEL on a much deeper level. It will be additionally
confusing, as RHEL can have as many overrides and branches on top of
ELN packages as it wants and we can not say if ELN package built
during the times of RHEL 9 development lands in RHEL 9 and is not
consumed much later in RHEL 10 for example.
ELN is not RHEL, it is what RHEL could have been if we try to cut it
right now from Fedora Rawhide. Therefore there is no direct link
between ELN state and RHEL versions. ELN is an abstract continuously
developed "future" which will be consumed by downstream on downstream
terms.
If we ever go with versioning for ELN, then we could use Fedora
versioning for it. This link is much cleaner and logical.
But I don't really want to do that.
I think that versioned tag for Fedora Rawhide is the reason why every
time we do Fedora branching we have a major infrastructure hiccup. And
the more infrastructure we add (ODCS, Gating..) the harder it is to
coordinate the version jump in Rawhide across it.
If Rawhide wasn't versioned, branching would be a small isolated
effort, which could have been prepared and tested in advance without
disrupting anyone's workflow. Rawhide would just keep going, with no
changes. And new release branch would be _added_ to the infrastructure
and opened to contributions as soon as infra for this particular new
part is ready and verified.
Now we have to do the verification of entire infra (because entire
infra is impacted by branching). We have to do it after the change, as
we can not test it on the side. And if something fails, it blocks
everyone.
Therefore if we _can_ proceed without versioning, I'd rather do it that way.
>I rather equate this to RHELhide, it should be evolving. Once N
is
>branched (CentOS?) and moving on, this is N+1. This is the rolling
>development location.
I agree. The 'N' value seen in this dist tag should always be greater than
the latest major version we see for RHEL and CentOS.
Thanks,
--
David Cantrell <dcantrell(a)redhat.com>
Red Hat, Inc. | Boston, MA | EST5EDT
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
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@lists.fedoraproject.org
--
Aleksandra Fedorova
bookwar
5:53 a.m.
Aleksandra Fedorova wrote:
The goal of the ELN project is to continuously build Fedora Rawhide
packages and composes in the way which resembles the CentOS and RHEL
build process and to provide a feedback loop for Fedora maintainers on
the status of those builds.
I don't see why it would be the job of Fedora developers to alpha-test RHEL
this way. This has absolutely no business being on Fedora infrastructure and
consuming Fedora maintainers' time.
Kevin Kofler
1480
days inactive
1487
days old
89 comments
23 participants
participants (23)
-
Aleksandra Fedorova -
Dan Horák -
David Cantrell -
David Tardon -
Fabio Valentini -
James Cassell -
Jan Kaluza -
John M. Harris Jr -
Justin Forbes -
Kevin Kofler -
Miro Hrončok -
Neal Gompa -
Nicolas Mailhot -
Panu Matilainen -
Petr Pisar -
Petr Viktorin -
Robbie Harwood -
Stephen Gallagher -
Tom Hughes -
Tomas Orsava -
Troy Dawson -
Vít Ondruch -
Zbigniew Jędrzejewski-Szmek