Jeff Gazso <> 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?
> 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.)


Attachment: signature.asc
Description: PGP signature

Reply via email to