2023 Maintenance of Chromium downstream
- Date: 7th Jun 2023
- Issue: https://github.com/Igalia/webengineshackfest/issues/9
Dape starts the session. Attendants introduces by themselves. Most of attendants are interested in managing the downstream project and have experiences to work on the downstream projects. (E.g. Ozone/Wayland, Gecko/Firefox, Never Whale, and so on)
Dape started to proceed the presentation. The reason why we need to have a downstream is we need port them to various hardwares, different toolkits.
Tiago: Tell why Ozone/wayland needed to work on downstream.
Dape: it’s a good example.
Nick: Mentions the use case where someone needs to experiment with alternative implementations for specific features, such as, a GStreamer-based media backend.
Alex: There is a another reason, financial. When one aims for example to to sell the search engine feature as part of its business model.
Antonio: Mentions the WebCL use case, where a big Web facing feature must be developed and would not be easily accepted right away upstream.
Dape moves to 'Upgrade Strategies' topic.
Roger: Mentions that on chromium webos ose the upgrade strategy is to cherry-pick the changes from the previous milestone, and this can take a while, and on CEF they use a different strategy - the patches are applied by an automated script and there are different patches on the tree: big patches containing all the code needed to change the chromium code to inject CEF code, and separate patches for fixes, and with this strategy they are able to move quite fast and keep up with the stable milestones, and ask dape abou his experience with those strategies and which one he thinks is best.
Dape: LG has several downstream layers. LG keeps a references platform that tracks the upstream, then different teams follow the reference platform. The important part of tis is that explicitly the size of depth of the layres. Because if we fail to follow the upstream rebase, it will be much difficult to track the upstream. CEF started a shortest rebase term to avoid huge conflict against the upstream changes. Brave has good experience to follow the upstream changes.
Ivan: Mentions some aspects of his experience on Brave port, such as, toolchain needs, browser runtime. They started to contribute to the upstream for the patches(??). Had to deal with changes and decisions taken and suddenly announced by Google (TODO: confirm the actual case)
Dan:Bloomberg terminal is all based on the browser. There are a lot of downstream pathches. They maintains features branches to maintain them individually.
Dape: There are many downstream pathches in //contents for LG webOS. And there ususally many changes in //contents of the upstream. So conflicts happened frequencly.(??)
AlexD: In his previous company, they used a script to rebase automatically(?)
Dape: (He explains how WebOS has been doing rebase with their product features again with product schedule)
Tiago: Suggests to Bloomberg example, an approach they have used in the past when Ozone/Wayland downstream branch was in early development.
Antonio: Asks if the strategies from LG, Bloomberg, Brave, etc are well documented internally and mentions how important it is to determine the strategy to resolve conflicts. Also asks if contributing changes back to upstream is on the backlog and how often this is done.
Ivan: Shares some interesting use cases on how to maintain changes, used in Brave project, eg: file replacement using meta-tree tool and some c++ tricks using macros and it sometimes led to some readability issues. They also have created tool for mojom files to avoid original mojom file conflicts.
Antonio: Previous gyp config was easy to insert and remove some features comparing to gn. Having gn tool like Brave would be a good option.
Dape moves forward to the next topic: How upstream may better support downstreams
Alex mentions the better componentization and extensibility aspects.
Dape suggests a more aggressive refactoring moving things out of //chrome into //components where possible.
Ivan mentions maybe if Google has some downstream advocates to suggest how to upstream downstream patches, it would be more helpful to upstream patches.
Dape: In case of Fugu, they have some support channel for helping updtreaming patches.
Alex mentions that the embedders mailing list is the best way to communicate the work you are doing
Dan: people on chromium team are used to know the contact people and communicate with them often, bug google lacks a formal structure for communication
Mirko: Mentions that CI is a big problem when working downstream, and you don't have many options other than maintaining the CI infrastructure for your downstream project
Dape: [fill in later]
Dape moves to the topic of typical problems
Ivan: Mention the case when google disables a feature and all downstreams run into trouble
Dape moves to the topic of measuring downstreams
Dape: Asks if we are missing some metric (apart from the delta, modifying delta)
Dape moves to open discussion
Alex: the issues and solutions of working on downstream are recurrent problems, so we can continue the discussion
Dape closes the session