Jeff Gazso <jeff.ga...@gmail.com> writes: > That does sound painful. > >> - Across the 3 channels, you are looking at roughly 12 releases per month. >> That's a lot of churn. > > * Why build unstable stuff, why not build only stable releases and fix the > problems once?
The idea is that you end up fixing stuff before you have a big mountain of things to fix in stable. I don't know if that's necessary nowadays or not, but that's the concept, I think. > > * Looking at chromium-browser-official and the GitHub mirror, it's unclear to > me which release is stable. How is that sorted out? > The chrome release blog announces the changes. >> - Upstream likes to use modern C++ features, and they write C++ code that >> tends to break or is unsupported on stable releases of GCC and LLVM. > > * How common of a problem is the C++ issue? > Depends on if we want to keep GCC working. > * I don't know C++, is that a major obstacle? > You will need to know at least a little bit (or learn it) to fix problems. >> - Upstream bundles many libraries. The Gentoo ebuild has some logic to >> unbundle a number of these, but maintaining it is a pain. > > * What tends to go wrong? > >> - Using the bundled libraries sometimes is problematic, especially on >> non-x86-64 targets which upstream doesn't support well. > > * What tends to break here? > https://bugs.gentoo.org/904850 was an example of an arm64-only bug, although it was an easy fix. > * Is the upstream likely to take patches or are we stuck maintaining a patch > set for pretty much all non-x86-64 targets? > > * Is this why Sam maintains a bunch of PPC64 patches? Do these ever make > their way upstream? I don't maintain those - that's somebody else. The PPC64 patches originate from Raptor who produce PPC64 workstations and I think the community helps maintain them. Upstream tend to not want patches for things they can't test in CI. (Also, please don't top-post - quote and reply underneath an email.) >k
signature.asc
Description: PGP signature
