Many of us deeply involved in RHEL's production are excited about this
idea.  We are looking for ways to do more of the RHEL 9 creation
activities in public and this could help serve that purpose.
Something along these lines would be fantastic because identical
Fedora sources could be used to produce differentiated builds, where
only inherited rpm macros would differ.  Perhaps even better is that
it looks like it would give Fedora the ability to do more to serve its
own mission, by allowing customization without forking sources.
Fedora would be able to grow beyond the traditional
one-set-of-defaults-must-fit-all model.


On Mon, Jan 13, 2020 at 8:45 AM Aleksandra Fedorova
<afedorova@redhat.com> wrote:
>
> Hi, all,
>
> This topic goes along the lines of Matthew’s Operating System Factory
> discussion[1], but with a slightly different angle. It also is the
> generalization of the Change we have proposed recently [2]
>
> So let me start with the problem:
>
> In Fedora now we have a well known and established process of how to
> deal with updates that bring new content through packages. There are
> ways to package new content side by side with the old one, to perform
> a non-disruptive testing, iterate and upgrade.
>
> What I think is missing is the way to safely iterate on the process,
> which happens after the content is packaged. Examples are: changes to
> buildroot configuration as in [2], changes in comps files, for example
> required for Minimization Objective [3], changes in compose building
> process, changes in Mass Rebuild and so on.
>
> For such changes we have to use an all-or-nothing approach, which
> means we either implement the change too early or postpone it for too
> long.
>
> To add flexibility to the Fedora process, I’d like to propose the
> concept of alternative buildroots.
>
> ------
> Note: The naming is hard here, and while I tend to call it
> “buildroot”, it actually needs to be called “alternative everything,
> except the srpms”.
>
> I think we shouldn’t use the word “variant”, “spin”, “flavour” or
> something like that to describe it, as it is strictly the shared
> development playground linked to the latest Fedora Rawhide state and
> focused on the build and compose process. It is definitely not the
> alternative Fedora. It shouldn’t have releases on its own, it has no
> branches in the source code and it doesn’t target end-users.
> ------
>
> The good thing is that, with the distributed CI approach we have
> implemented, we are ready to consume the feedback from such
> alternative setups in a non-blocking but informative way. I think we
> can extend our use of CI machinery so that it simplifies the
> development process for everyone, removing redundant heads-ups but
> increasing the targeted collaboration in places where it is actually
> needed.
>
> ### Use cases ###
>
> The first example of such a buildroot is provided by the CPU baseline
> testing [1].
>
> There will be more, since we may want to work on comps files for
> Minimization Objective.
>
> There is also one particularly important case of the RHEL bootstrap:
> RHEL tries hard to inherit as much as possible from Fedora, but since
> both Fedora and RHEL have historically different build and compose
> configurations, it is often problematic to deal with dependency and
> build issues which arise from it. To the point that RHEL sometimes
> just can’t use Fedora as an origin, and needs to find its way around.
>
> The alternative buildroot targeting CentOS and RHEL would provide an
> open shared development environment. There we can work on converging
> the RHEL process to Fedora, and also on improving Fedora process with
> things, which RHEL and CentOS have discovered.
>
> ### Proposal ###
>
> This idea doesn’t quite fit into the Fedora Changes framework, as
> there is no actual change to Fedora. And we don't even have a concept
> of an Infrastructure Change at this point.
>
> But there are several items one can think about:
>
> 1) Though as I said above the “buildroot” term is slightly misleading
> but it is a start. And the change [2] is a first step, the prototype,
> which goes into that direction. Its main focus is the compiler
> parameters rather than anything else.
>
> 2) The second part of the proposal is to setup a CentOS/RHEL-targeting
> buildroot and compose, with a focus on comps, dependency chains and
> compose differences. Which I think overlaps in a certain way with the
> Minimization Objective.
>
> 3) And the third part is to generally develop the alternative
> buildroot as a concept. It should be our toolbox item, something
> similar to the alternative architectures approach. So that it can be
> requested by anyone based on the existence of a SIG or working group,
> which would own and maintain it.
>
> [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/ZBU4MYRMMAE2Z7DL4NPPECTMX2FBQAVL/
> [2] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/IFBHS2WKKPKJH6H54OX4DV3U7A4XYOPU/
> [3] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/IFBHS2WKKPKJH6H54OX4DV3U7A4XYOPU/
>
> --
> Aleksandra Fedorova
> bookwar
> _______________________________________________
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-leave@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



--
Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc.
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@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