Alternative buildroot as a development tool

[Aleksandra Fedorova]

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/[e-mail].o...
[2]
https://lists.fedoraproject.org/archives/list/[e-mail].o...
[3]
https://lists.fedoraproject.org/archives/list/[e-mail].o...

--
Aleksandra Fedorova
bookwar