On Thu, Jan 16, 2020 at 9:30 PM Brendan Conoboy <blc@xxxxxxxxxx> wrote: > > On Thu, Jan 16, 2020 at 5:14 PM Kevin Fenzi <kevin@xxxxxxxxx> 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 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. > > This may be true, but if the number of people grows as a result, that > might be worth it. No need to decide right nwo of course. Part of > what is good about Aleksandra's proposal is that it's incremental- > each step along the way has a specific benefit. The long term > potential for this is exciting, but the short and medium term benefits > seem good too. Change can happen a little at a time then be measured > and adjusted as needed. > > > But I'm perfectly happy to give this a try and see where it leads us. :) > > Cool :-) > I don't think I've made any secret that I would love to have the ability to do awesome large-scale improvements in Fedora more easily. I've mentioned in various avenues that I'd love for us to have that to give people the ability to build an awesome distro and take it in crazy directions to see where we can truly go. 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 failed in other ways. We have not learned from what other communities are or are not doing, either out of hubris or ignorance (I'm really hoping it's the latter, personally). Some of these problems have been broadly exposed as part of the Modularity bringup, but there's an underlying general problem that it is okay to hobble along because we've hobbled along for so long. If anyone wants to know details, feel free to ask me. I don't want to fill this with the sordid details... I've had the pleasure of becoming involved in many other communities over the past several years, and have had exposure to how others have solved problems we've had. Consequently, I've been spoiled at $DAYJOB where some of these issues we've been talking about for a couple of years simply don't exist because our tooling and infrastructure has effectively solved it for us. That's not to say it's perfect and we have no problems at all. There are still issues and quirks that I have to work around just like Fedora does with what the project has. I'm slowly working through trying to make what I use for $DAYJOB available within Fedora so members of the Fedora community can use it for their own purposes. After all, the stuff I use is open source too (except for the stuff I wrote, which I'm trying to get that ready to be opened up too...). I can't believe I'm saying this, but I think "alternative buildroots" is not enough. It's a step in the right direction in terms of thinking about how to make developing bigger and more interesting changes. But we need to be thinking more holistically about packager and developer workflows within Fedora. Some of this is happening under the remit of the Fedora CI work, and that's awesome! But why are these things happening in haphazard pieces where we will likely wind up with more half-implemented solutions or things that people don't really like but stomach because some overlord is forcing it? Incrementalism has its place, but this is something where once we implement the "just enough increment", we'll stop again and everything will just be uncomfortable and somewhat unhelpful, in much of the same way the pkgdb to pagure transition was handled. The reason why it'll happen is the same reason why it happened then: this stuff is legitimately difficult to improve and it's easy to pull the brakes once you reach a certain level of usefulness. So... I guess I'm trying to say is "think bigger and go for broke", because I think we're really only going to have one chance to do this for the decade. Think like the people who made stuff like Koji and Dist-Git a reality over nearly 15 years ago, when *those* ideas were crazy and new! Just because the project is approaching being old enough to drink in the US doesn't mean we can't do these kinds of big things still! -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
