On Mon, Jan 13, 2020 at 05:43:26PM +0100, Aleksandra Fedorova wrote: ...snip... > ------ > 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. > ------ petri dish? too hard to say...fields (like planting a test crop in another field)? Naming is hard. :) > > 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. 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). > 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. +1 ! > ### 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. Well, infrastructure has a Request for resources process. However, it's a bit dated these days, not taking into account OpenShift or the like. The CPE team has been wanting to move to a higher level process for this kind of thing... but yeah, nothing is really clear, I'd say just get buyin from stakeholders/fesco. > > 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? > 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. Yeah, although I think we should still examine if a thing is ready for testing this way. I don't think we should just add anything that anyone can think of. It does use resources. That said, I think if the concept for testing is reasonable we could add it. Thanks for working on this and I'm eager to see how well we can get it working! :) 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
