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? * Looking at chromium-browser-official and the GitHub mirror, it's unclear to me which release is stable. How is that sorted out? > - 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? * I don't know C++, is that a major obstacle? > - 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? * 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? ~Jeff On Wed, Jun 7, 2023 at 2:38 PM Maciej Barć <x...@gentoo.org> wrote: > I think Google does all this intentionally to piss off people trying to > use the "free-er" version of Chrome... let's face it, "their" aim is to > create a one-fits-all spyware named Google Chrome. > > Google does not want you to touch their mess. > Google does not want you to even think about going a extra mile to not > have telemetry in software you use every day. > > Having said all this, it really is a miracle to me that the Gentoo > Chromium team had put up with this for so insanely long and I have the > most respect for you guys! > > W dniu 7.06.2023 o 19:45, Mike Gilbert pisze: > > On Wed, Jun 7, 2023 at 9:09 AM Jeff Gazso <jeff.ga...@gmail.com> wrote: > >> > >> I'm in the process of getting Gentoo dev status. I'm willing to consider > >> maintaining www-client/chromium. I have a high core count rack server > that > >> should be able to handle the build process quite well. Can you give me > a list > >> of common pain points? If that is a long conversation feel free to > email me > >> directly. > > > > I'll start by giving a brief overview of the Chromium release process > upstream: > > > > - 3 release channels: stable, beta, dev/unstable > > - Major development occurs on the master branch. > > - Once a month, a new major version is forked from master, and this > > becomes the "dev channel" release series. > > - Over the next several weeks in the dev channel the major version is > > tested and fixed, with releases roughly once per week. > > - Eventually, the branch is promoted to the "beta channel". > > - A similar process occurs in the beta channel, with weekly releases > > until the major version is finally promoted to the "stable channel". > > - The stable channel sees around 1 to 2 releases per month, usually > > with security fixes included. > > > > Downstream, we have historically tried to keep up with all 3 channels. > > Keeping the dev channel working is the biggest challenge. The other > > channels usually just involve build testing and the occasional > > backport of fixes. > > > > Common problems: > > > > - Across the 3 channels, you are looking at roughly 12 releases per > > month. That's a lot of churn. > > - The dev channel never compiles the first time you try it. There are > > always problems to fix. > > - Upstream only really supports using their bundled toolchain (an LLVM > > git snapshot on Ubuntu). On Gentoo, we try to make it work with the > > stable release of GCC and LLVM/clang. > > - 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. > > - Upstream bundles many libraries. The Gentoo ebuild has some logic to > > unbundle a number of these, but maintaining it is a pain. > > - Using the bundled libraries sometimes is problematic, especially on > > non-x86-64 targets which upstream doesn't support well. > > - Upstream cross-compiles their ARM binaries, whereas we compile > > natively on Gentoo. This sometimes causes conflicts. > > > > I'm probably missing some things, but I think that should give you > > some idea of what you're in for. :-) > > > > -- > Have a great day! > > ~ Maciej XGQT Barć > > x...@gentoo.org > Gentoo Linux developer > (dotnet, emacs, math, ml, nim, scheme, sci) > https://wiki.gentoo.org/wiki/User:Xgqt > 9B0A 4C5D 02A3 B43C 9D6F D6B1 14D7 4A1F 43A6 AC3C >
