Re: Alternative buildroot as a development tool

2020-01-20 Thread Stephen John Smoogen
On Fri, 17 Jan 2020 at 04:33, Nicolas Mailhot via devel wrote: > > Le jeudi 16 janvier 2020 à 22:24 -0500, Neal Gompa a écrit : > > Hi Neal, > > > I've also said that I don't think we can handle it as our > > infrastructure currently stands. Our build system tooling has > > suffered from a decade

Re: Alternative buildroot as a development tool

2020-01-17 Thread Nicolas Mailhot via devel
Le jeudi 16 janvier 2020 à 22:24 -0500, Neal Gompa a écrit : Hi Neal, > I've also said that I don't think we can handle it as our > infrastructure currently stands. Our build system tooling has > suffered from a decade of neglect, and attempts to reinvent or > improve that have been rebuffed or

Re: Alternative buildroot as a development tool

2020-01-16 Thread Neal Gompa
On Thu, Jan 16, 2020 at 9:30 PM Brendan Conoboy wrote: > > On Thu, Jan 16, 2020 at 5:14 PM Kevin Fenzi wrote: > > On Thu, Jan 16, 2020 at 11:27:36AM -0800, Brendan Conoboy wrote: > > > One potential output of this change would be to have editions choose > > > what buildroot they are based on.

Re: Alternative buildroot as a development tool

2020-01-16 Thread Brendan Conoboy
On Thu, Jan 16, 2020 at 5:14 PM Kevin Fenzi wrote: > On Thu, Jan 16, 2020 at 11:27:36AM -0800, Brendan Conoboy wrote: > > 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

Re: Alternative buildroot as a development tool

2020-01-16 Thread Kevin Fenzi
On Thu, Jan 16, 2020 at 11:27:36AM -0800, Brendan Conoboy wrote: > On Wed, Jan 15, 2020 at 8:31 AM Kevin Fenzi 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

Re: Alternative buildroot as a development tool

2020-01-16 Thread Brendan Conoboy
On Wed, Jan 15, 2020 at 8:31 AM Kevin Fenzi 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

Re: Alternative buildroot as a development tool

2020-01-15 Thread Kevin Fenzi
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”,

Re: Alternative buildroot as a development tool

2020-01-15 Thread Adam Samalik
I really like this proposal. I feel like it's something we needed for a long time. More comments inline! On Mon, Jan 13, 2020 at 5:45 PM Aleksandra Fedorova wrote: > Hi, all, > > This topic goes along the lines of Matthew’s Operating System Factory > discussion[1], but with a slightly different

Re: Alternative buildroot as a development tool

2020-01-14 Thread 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

Re: Alternative buildroot as a development tool

2020-01-13 Thread Brendan Conoboy
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

Alternative buildroot as a development tool

2020-01-13 Thread Aleksandra Fedorova
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