On Wed, Dec 11, 2019 at 9:55 PM Adrian Bunk <[email protected]> wrote: > On Wed, Dec 11, 2019 at 08:48:04PM -0800, Andre McCurdy wrote: > > On Wed, Dec 11, 2019 at 7:38 PM Adrian Bunk <[email protected]> wrote: > > > > > > There is no need to question whether niche features like gcc or GNOME > > > for the target is a useful way of spending resources since the work is > > > done by the people interested in the feature. > > > > Yes, that's probably expected. Developers work on stuff which > > interests them. That's precisely why there's a danger that effort and > > resources don't always get spent on the work which would benefit the > > widest range of users. > > This is not a danger, this is how open source projects work.
Yes, it's how open source projects work. It's also a model where there's a risk that the best interests of the wider user base don't get much consideration. There's no conflict between those two statements. > Yocto is not a company where all developers are paid resources that can > be told what to spend their time on. > > Developers spend effort on what is useful for their local paid work, > or what is fun to do as a hobby. > > >... > > > In some cases this even creates new bugs for everyone else, > > > like the breakage caused by an incorrect CentOS 7 workaround in nettle > > > that needed a last-minute fixup before the release of Yocto 2.7. > > > > That was an embarrassing mistake, which you've brought up before. > > Not exactly embarrassing, the problem is obvious only in hindsight. > > > It happens sometimes. Dropping support for CentOS 7 or musl isn't going > > to stop embarrassing mistakes happening again. > >... > > It avoids bugs being introduced by workarounds. > > Trying to build and run 2020 software on a 2013 distribution is > problematic, and will generate more and more problems noone else > has seen or is interested in fixing. In general yes, but build environments are somewhat of a special in that one of their key functions is to isolate the code being built from any specific details of the host. OE already does a very good job of doing that (by building -native versions of many of the tools traditionally provided by the host in legacy build environment, etc) but if there are ways to improve that isolation even further then I don't think we should dismiss efforts to work on them just because key developers are happy with the level of isolation we have already. > Bumping the baseline by 3 years to Ubuntu 16.04 would make both existing > and future OE-specific workarounds for ancient hosts unnecessary. > > cu > Adrian _______________________________________________ Openembedded-architecture mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
