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@xxxxxxxxxxxxxxxxxxxxxxx/thread/ZBU4MYRMMAE2Z7DL4NPPECTMX2FBQAVL/ [2] https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/thread/IFBHS2WKKPKJH6H54OX4DV3U7A4XYOPU/ [3] https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/thread/IFBHS2WKKPKJH6H54OX4DV3U7A4XYOPU/ -- Aleksandra Fedorova bookwar _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
