Vivaldi’s code integration. Our developers speak.
-
-
What would interest me is how many of these estimated 600 chromium developers are community volunteers. I don't think all of them are paid by Google and the ratio would be interesting.
-
This is a really nice insight into the process. Thanks for offering an english translation!
-
I just love tech blogs... keep em' coming!
-
So... what's Vivaldi team strategy?
Rebase or merge?Is it full Gitflow or something lighter / heavier?
-
@rotfl said in Vivaldi’s code integration. Our developers speak.:
Rebase or merge?
Vivaldi are masters of web browsers. They just re-code vivaldi from scratch each time chrome updates.
-
@luetage: I suppose that Chromium development has steep learning curve because of codebase size so Googlers are the vast majority
-
@luetage: You are forgetting that it's not only Google who pays people to help Chromium, there's also Opera, Samsung, Amazon, Intel, and many others.
Community volunteers are probably nearly none.
-
To answer the question at the end of the article, I found it not complex enough. I would have loved lots more details
BTW, this link might interest readers here : https://chromium-review.googlesource.com/q/owner:yngve%2540vivaldi.com
-
@cqoicebordel: Thanks for sharing the link. More details? We'll catch Ygnve to share more details another time
-
Interesting.
-
@rotfl: We tried "Merge". It got rather messy in a hurry, particularly if you wan to follow the Chromium branches, because then you have to undo all the merges since the branch point using rather specialized git merge commands, before merging with the new branch.
After a reorganization of the codebase, we are doing all updates in the chromium source using rebasing of branches, and workbranches in the vivaldi code are also rebased on top before being integrated. Makes for a much cleaner history.
OTOH, our version of the GN code that we recently published on Github (there are a couple of differences in the history between those two repositories), will likely be using the merge strategy, especially since it is not a frequently updated, which means that the history gets less messy.
Merge vs. Rebase really comes down to one thing: Who is controlling the majority of the source? If you control it yourself, merge should work fine; if you don't, and you need to sync back and forth between a lot of branches, then rebase is probably easier for maintaining the code as you incorporate new releases.
-
@yngve Thanks for detailed (and interesting) answer
I experienced "dark sides" of both strategies so I know that there is always some kind of trade-off...
Cleaner history vs easier coordination of team / tasks and so on...It always makes me smile when guy from different project who sits next to me sighs "ooooooomg....... they rebased my source branch again...." xD
-
Very interesting. I knew there had to be a lot of behind building Vivaldi. This shows some of it. Process management must also take its toll with trying to rework the code needed to make Vivaldi.
Thumbs Up to all of you!! -
@an_dz: that sounds like the linux community! (soz for replying to a 2 year old comment)
-