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 <b...@redhat.com> 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 > <afedor...@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-le...@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-le...@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 > -- Brian "bex" Exelbierd (he/him/his) RHEL Product Management & Community Architect @bexelbie | http://www.winglemeyer.org bexel...@redhat.com
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
