On Thu, Jan 16, 2020 at 11:27:36AM -0800, Brendan Conoboy wrote: > On Wed, Jan 15, 2020 at 8:31 AM Kevin Fenzi <kevin@xxxxxxxxx> wrote: > [snip] > > > ### 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. > > > > Yeah, but comps files are used in composes, so we would have to do > > composes to see changes there. I guess the CI part would do the > > composing in that case? But we would also need a different comps (so we > > didn't change the default one). > > You would need a different comps, but that also means you would get to > have a different comps to experiment with... Sure. > > [snip] > > > 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. > > > > Yep. > > > > > 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. > > > > So, this would have composes? Or they would be test composes in CI/ODCS? > > One potential output of this change would be to have editions choose > what buildroot they are based on. As an example, Fedora Server, which > has struggled to find its element, could actually be built in ways > more conducive to server use cases: different compiler flags, kernel > parameters, baselines, etc. Possibly, but also splitting things means they have less people using them, and also there may be less compromise to come up with something everyone can share. But I'm perfectly happy to give this a try and see where it leads us. :) kevin
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 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
