While I agree with you, as indicated by my comment about Google having de facto control, the terms upstream or downstream when discussing forking an open source codebase has specific meaning. Chromium is not a downstream forked that has ripped all the google pieces out. It is the upstream codebase that Google then builds all their telemetry and other Google shenanigans into.

If we're discussing someone else forking Chromium because hypothetically Google decided to once again Be Evil it is important to understand, from a technical standpoint, that the fork comes from code before Google does their stuff and not after. Ripping all of google's tendrils out would be a monumental undertaking. Building a similar browser from before Google bakes in their telemetry is infinitely easier and more trustworthy in my opinion.

▲

cosmic_cheese 4 days ago | parent | next [-]

Some of the "evil" isn't the Google stuff, but rather "standards" that Google is pushing or dropping support for without the support of the other members of the consortium and just as present in Chromium as it is in Chrome.

▲

immibis 4 days ago | parent | prev [-]

"upstream" and "downstream" is about the direction changes flow. Changes flow from Chrome into Chromium. The fact they arrive in the Chromium repository before they arrive in a public release of Chrome is not relevant.

	▲	dpranke 3 days ago \| parent [-]
		Context: I worked on Chrome for 15 years (until June) and am still a Chromium committer. I am probably as familiar with how development in Chrome actually works as anyone (at least as of a couple months ago). It is correct that Google can and does decide that some features should remain private before they are developed. However, there are significant logistic and cultural hurdles to keeping something private, and as a result it's really only possible in certain parts of the codebase. Sometimes things that have been developed in private are eventually made public, and Chrome devs will often call that "upstreaming", but I think that's not really the same thing as what most people are talking about when they use the words upstream and downstream. And these instances are fairly uncommon in the history of the project. Otherwise, IMO it is not really correct to say that changes flow from Chrome into Chromium. Nearly all development is done in the public repos and so they would be available simultaneously for either build. There aren't really official releases of Chromium per se, but a full build of Chromium containing a given change is basically always available before the corresponding full build of Chrome. There may be very rare exceptions for security fixes that are shipped before they are made public, but it would actually pretty hard to land such a change so I doubt it's happened more than a few times. So, more generally speaking, in my opinion it's not really useful to talk about "upstream" and "downstream" for Chrome and Chromium, definitely not in the day-to-day sense. Chrome and Chromium are multi-repo projects, and there is only ever a single copy of a particular repo that is used for either. The same branches in a given repo are used for both Chrome and Chromium at any point in time. There is a main branch and release branches, and most of the time (but not always) a change will land in the main branch before a release branch. But I don't think most people would call "main" upstream of "release" in that sense. [ There are rare situations where Google will develop experiments on a private branch of a repo, but those don't usually end up getting shipped to anyone. ] This is different from how (most of?) the other Chromium-based browsers operate, where my understanding is that they usually do have true forks of (some of) the repos and changes flow downstream from the Google-maintained ones to ones under their control in the normal sense of the word.