I think most of the issues the author has could be solved by a sparse git checkout. Basically you only fetch one subdirectory of the whole got repo. It’s faster, plus allows for smaller checkouts.
There is definitely thruth in the objections though, a monorepo has disadvantages too. What I did was create the monorepo and do a split to commit to the individual repo’s again. It allowed us to see if it was a match for us without changing our tooling as the individual repos where being kept up to date too. It helped us a lot to PoC it fast and don’t waste too much time.
That would definitely help to improve the git performance if the repository’s history is too big, but there are other problems such as executing only the tests for checking the correctness of the changed parts that are hard to solve. Big companies using a monorepo model such as Facebook and Google have invested a lot of effort in designing tools (and even its own build system, see https://bazel.build/ and https://buckbuild.com/) for an efficient monorepo.
Hey all, some context on this. Shield studies are studies run by Mozilla to try new features in a random population (https://wiki.mozilla.org/Firefox/Shield/Shield_Studies). Here you can get some context on why and how, and it’s possible to see which ones are being executed and which ones are in the queue to be executed in the future (https://wiki.mozilla.org/Firefox/Shield/Shield_Studies/Queue).
It’s also important to point that, even if you have the study installed, it doesn’t mean you’re sending data. Those studies usually only send data from 1%-2% of the population.
Moreover, running this kind of studies is always optional. They can be disabled in about:preferences#privacy, unchecking the “Allow Firefox to install and run studies” checkbox. And it’s also possible to see more information about the studies in about:studies#shieldStudies.
If you really, really, want to see what data is sent by Firefox (Telemetry data, health data, Shield studies data…), it’s possible to go to about:telemetry and filter by type, see archived pings, and the raw JSON that is sent.
There are several main problems with this.
Optional does not mean opt-out, it means opt-in. You want to collect data from loyal Mozilla fans, then by all means give them the ability to turn it ON.
If #1 is unavoidable, don’t be unprofessional and don’t do mysterious things with the power that you grabbed from the opt-out default. “MY REALITY IS DIFFERENT THAN YOURS” is like one of the worst things you can put in the description that loyal unexpecting users will see.
If #2 happens by accident, write an apology and clean up your act. The replies from Mozilla thus far have been “it’s shield studies”. This is so cold and tone-deaf. Tell us what you’re going to do to make it better and make sure we can still trust Firefox!
I agree with you, but tbh, I don’t understand the problem with sharing anonymous data that can help to improve a product you use every day. If users have to give explicit consent to share even the most basic data, Mozilla would never be able to understand how people use Firefox.
Don’t misunderstand me, I really care about my privacy and I don’t want my data to be sold or used to show me ads, as other big companies do, but Mozilla’s policy on data privacy (https://www.mozilla.org/en-US/privacy/principles/) is very strict with that.
Also, about:studies shows which studies are ongoing, and a link to prefs to change this.