Re: Alternative buildroot as a development tool

[Brian (bex) Exelbierd]

I am chiming in with a slightly long form of +1 because of the lack of
comments.

I think this is HUGE.  To be able to connect to new use cases and ideas and
have the bonus of helping a downstream stay more closely connected feels
like a big win!

regards,

bex

On Tue, Jan 14, 2020 at 5:54 AM Brendan Conoboy <blc(a)redhat.com&gt; wrote:

>  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(a)redhat.com&gt; 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/[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
>  > _______________________________________________
>  > 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/[e-mail]
>
>
>
>  --
>  Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc.
>  _______________________________________________
>  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/[e-mail]
>  

-- 
Brian "bex" Exelbierd (he/him/his)
RHEL Product Management & Community Architect
@bexelbie | http://www.winglemeyer.org
bexelbie(a)redhat.com