From: Adrian Bunk <bunk@stusta.de>
To: richard.purdie@linuxfoundation.org
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 2/2] uninative: Switch from bz2 to xz
Date: Thu, 30 May 2019 17:25:18 +0300 [thread overview]
Message-ID: <20190530142518.GC318@localhost> (raw)
In-Reply-To: <e7536283bb0d7d255826585a3222aedd0d7950ad.camel@linuxfoundation.org>
On Thu, May 30, 2019 at 03:06:56PM +0100, richard.purdie@linuxfoundation.org wrote:
> On Thu, 2019-05-30 at 16:59 +0300, Adrian Bunk wrote:
> > There are also some other related topics that might be considered
> > on how this should develop long-term:
> >
> > 1. How important is it to support host distributions that are not
> > listed as supported? Not limited to uninative it can be painful
> > adding support for new distributions to stable branches.
>
> The distros we do support were chosen to give a decent cross section of
> the Linux ecosystem. Whilst not full coverage, the delta between those
> and other systems should be relatively minimal as we have both older
> and modern in there.
I agree that it usually works on the range between the oldest and the
newest supported host distribution.
But adding support for more recent host distributions to stable
branches could end up being any amount of troubles if you are
unlucky.
> > 2. Does using uninative by default bring enough benefits to
> > outweight the problems with new host distributions, or should it
> > become non-default in master?
>
> We test it heavily on the autobuilder and also benefit from it
> massively there so in my view its a significant win for us alone. We
> chose to share it with the ecosystem. You're not forced to use it.
>
> > The sum of the two points above is especially problematic:
> > "re-use of native shared state artifacts across different host
> > distributions" is a more exotic feature, and effectively supporting
> > this for unsupported host distributions is the problem here.
>
> Which distros are you seeing a problem with and what kinds of problems?
> I'd hoped/believed the problems should be relatively minor unless
> they're really old.
>...
The problem is that uninative is expected to break 3 times per year,
with every new release of gcc or glibc.
Are the problems people regularly see on bleeding-edge distributions
really offset by the benefits of having it enabled by default?
> Cheers,
>
> Richard
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
next prev parent reply other threads:[~2019-05-30 14:25 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-29 18:43 [PATCH 1/2] yocto-uninative: Update to 2.5 release Richard Purdie
2019-05-29 18:43 ` [PATCH 2/2] uninative: Switch from bz2 to xz Richard Purdie
2019-05-29 19:21 ` akuster808
2019-05-29 19:26 ` richard.purdie
2019-05-29 20:39 ` akuster808
2019-05-29 20:50 ` richard.purdie
2019-05-29 21:25 ` Tom Rini
2019-05-29 21:29 ` richard.purdie
2019-05-29 22:17 ` Adrian Bunk
2019-05-29 22:29 ` Tom Rini
2019-05-29 23:02 ` Adrian Bunk
2019-05-30 8:13 ` richard.purdie
2019-05-30 13:32 ` akuster808
2019-05-30 13:55 ` richard.purdie
2019-05-30 15:57 ` Tom Rini
2019-05-31 13:44 ` richard.purdie
2019-05-30 13:59 ` Adrian Bunk
2019-05-30 14:06 ` richard.purdie
2019-05-30 14:25 ` Adrian Bunk [this message]
2019-05-30 14:15 ` akuster808
2019-05-30 2:54 ` Tim Orling
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190530142518.GC318@localhost \
--to=bunk@stusta.de \
--cc=openembedded-core@lists.openembedded.org \
--cc=richard.purdie@linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox