Vivaldi lager nettleseren med kode fra Google: – De er overraskende behjelpelige

MØLLEPARKEN, OSLO (digi.no): Produktet som for alvor bringer den norske nettleserarven videre, Vivaldi, er basert på Googles Chromium-prosjekt. Dette byr på mange fordeler, men også store utfordringer. Nå har tre av utviklerne hos Vivaldi gitt digi.no innblikk i hvordan dette arbeidet gjøres.

Vivaldi Technologies ble som de fleste kjenner til, etablert av Jon von Tetzchner i 2014, etter at han i 2011 hadde forlatt Opera Software på grunn av uenighet med styret og den øvrige ledelsen om veien videre.

Den nye nettleseren, som fikk navnet Vivaldi, ble første gang presentert i begynnelsen av 2015.

To alternativer

– Den gangen Jon fant ut at vi skulle lage en ny nettleser, så var jo det første spørsmålet «hva baserer vi den på?» Det var egentlig bare to alternativer, Firefox eller Chromium, siden Opera-koden selvsagt ikke var tilgjengelig, forteller Yngve N. Pettersen, som har hovedansvaret for vedlikeholdet av kodebasen hos Vivaldi.

I likhet med flere andre hos Vivaldi, har Pettersen bakgrunn fra Opera Software, hvor han ble ansatt som nummer tre i selskapet og blant annet jobbet med sikkerhet. 16 år senere forlot han selskapet.

I forbindelse med valget mellom Firefox og Chromium som utgangspunkt, ble det blant annet sett på lisenser og hvordan produktene så ut.

– Vi satt med et inntrykk av at Firefox ikke var helt god når det gjaldt «devices». Spesielt operativsystemet deres virket veldig prototypeaktig på dette tidspunktet. Vi fant da ut at Chromium var best plassert når det gjaldt features og plattformstøtte for det vi hadde lyst til å gå løs på, forteller Pettersen.

Omfattende kode og høyt tempo

Ingenting tyder på at det har blitt angret på dette valget i ettertid, men Pettersen legger ikke skjul på at det har vært utfordringer underveis.

– Vi ville nok hatt utfordringer i begge tilfeller med å gjøre våre endringer. Det ville nok ha vært like komplisert, eller enkelt, uavhengig av hva vi hadde valgt, sier han.

Fra starten av var den største utfordringen rett og slett å bli kjent med koden.

– Den er jo ganske stor, sier Pettersen.

I ettertid har det derimot vært tempoet i utgivelsene som har skapt de største utfordringene. Det kommer en ny versjon av Chromium-koden hver sjette uke, og den må Vivaldi-utviklerne integrere med selskapets egen kode.

– Det er en jobb som kan ta flere uker, sier Pettersen.

Har blitt mer effektive

Tidligere har det tatt både tre og fire uker, men med de siste versjonene har Vivaldi-utviklerne greid å gjøre dette på under to uker.

Mye av dette skyldes omorganisering av Vivaldis egne patcher til Chromium-koden.

– Vi bruker ganske mye tid på fikse ting som fungerte i forrige versjon, men som ikke lenger fungerer på grunn av endringer som er gjort i Chromium, skyter prosjektleder Jarle Antonsen inn.

Antonsen jobber stort sett på et nivå over Chromium-kodebasen, blant annet med installasjonsprogramvaren.

Får god hjelp

Utviklerne opplever samarbeidet innen Chromium-fellesskapet, og da særlig med Google, som godt.

– De er overraskende behjelpelige og prøver å gjøre ting enkelt. Jeg har stått fast mang en gang og har sendt spørsmål til moduleiere, som kommer direkte tilbake med forslag om hvor jeg skal lete, forteller André Schultz, den tredje av utviklerne som digi.no møtte hos Vivaldi.

Han jobber primært med brukergrensesnittet.

Også Pettersen forteller at han gjerne tar kontakt direkte med de personene som er involvert i et tilsynelatende problem.

– Jeg pleier ikke å gå ut og gjøre skittentøyvask på Chromium-dev-listen. Jeg liker å være litt mer direkte overfor dem, enn å kjøre en diskusjon i full åpenhet, forteller han.

Bidrar selv også

Vivaldi-teamet har i det siste halve året i økende grad sendt inn patcher til Chromium-koden. Ifølge Pettersen har dette først og fremst dreid seg om rydding, men også noen feilfikser. Han antyder at det dreier seg om rundt et dusin patcher.

Blant de større var hvordan linjeendelser blir håndtert i Chromium-koden. I Windows og mange Windows-programmer, benyttes vanligvis som standard CRLF (Carriage Return & Line Feed) som tegn på linjeendelser. I de fleste Unix-lignende systemer, og som standard i Chromium-koden, benyttes bare LF.

– Vi så at Chromium-utviklere som var på Windows, plutselig hadde lagt inn en CRLF eller to midt inne i et «LF-only»-dokument. Det gjorde at vi helt uventet støtte på problemer, for vi hadde en regel i vår Git-utsjekking som sier at det var «LF-only» på for eksempel C++-filer. Da det så dukket opp CRLF-er, så ble disse filene plutselig markert som endret. Den eneste måten å løse dette på, var å fikse linjeendelsene, forklarer Pettersen.

– Med de nye reglene i Chromium, så blir alt automatisk gjort om til LF selv om det er CRLF lokalt, fortsetter han.

Det tok rundt tre måneder å få dette på plass, da det involverte mange moduleiere og ulike filer.

Pettersen forteller at han har planer om å sende flere andre ting oppstrøms, men at det krever ukesvis med forberedelser.

Vivaldi har nylig utgitt på Github flere utvidelser til prosjektgeneratorsystemet GN, som selskapet bruker til å spesifisere hvordan nettleserapplikasjonen skal bygges. Et blogginnlegg om GN og utvidelsene, skrevet av Pettersen, kan leses her.

En omfattende prosess

Da digi.no møtte Vivaldi-utviklerne for en uke siden, hadde Vivaldi allerede hatt Chromium 69-koden i hoved-branch'en en ukes tid. Før dette hadde Pettersen jobbet med den i to uker, men han fikk tilgang til den enda noen uker tidligere. Nå har han allerede jobbet en stund med Chromium 70-koden.

Digi.no ba Pettersen beskrive hele prosessen fram til at Chromium 69-koden utgis som en del av en Vivaldi-oppdatering.

– De fleste av utviklerne her jobber med hoved-branchen vår. Når det kommer en Chromium-oppdatering, jobber jeg på en separat branch og flytter dette i blant opp i hoved-branchen etter hvert som ting tar form. Det fører til at de må rekompilere en god del, innleder han.

– Aller først når jeg henter inn koden fra Chromium, og så synkroniserer jeg alle undermodulene som vi har og gjør noen få småendringer der. Prosessen der er ganske automatisk. Så gjelder det å ta våre egne oppdateringer og kopiere dem på toppen av Chromium-kodebasen. Dette er en prosess som er temmelig manuell til tider, fordi man får såkalte «merge conflicts». Disse har i blant vært problematiske, men jeg har som nevnt fått ryddet opp en del, slik at det har blitt enklere, forklarer Pettersen.

I den siste runden skal det ha vært rundt 80 slike konflikter på omtrent 400 «commits».

– På de rundt 900 filene som vi har endret, så var det rundt 80 filer som måtte ryddes opp i. Det tok meg fem-seks timer, en prosess som tidligere har tatt opptil en uke, forteller Pettersen.

Når dette har kommet på plass, gjelder det å få koden til å kompilere.

– Det kan variere hvor lang tid dette tar, men vanligvis en dag eller så å få Windows-versjonen opp å gå. Linux, Mac og de andre plattformene kan ta noen timer å bygge opp, men er vanligvis uproblematiske. Totalt tar denne prosessen normalt to-tre dager, sier Pettersen.

Avdekker nye problemer

Under den samme prosessen oppdager han ikke sjelden at det har blitt gjort så store endringer i Chromium-koden at han må ta vekk Vivaldis egne patcher. Disse må da skrives om. Kompleksiteten i alt dette kan også føre til at det tar noe tid før alle de mindre kritiske sikkerhetsfiksene som kommer i Chromium, blir en del av Vivaldi.

– Etter dette begynner andre, spesielt André og Jarle, å fikse de problemene jeg fant, i tillegg til nye problemer som avdekkes under testing, sier Pettersen.

I forbindelse med Chromium 69 hadde utviklerne løst de fleste av problemene allerede den samme uken som kildekoden kom.

Saken fortsetter under bildet.

En lærepenge

Ifølge Schultz er det mest krevende når Google gjør arkitekturendringer.

– Dette har skjedd et par ganger, hvor vi har skrudd av et feature-flagg og jobbet parallelt ved siden av Chromium, på en feature som egentlig er døende. Det har skapt masse arbeid, sier han.

Han forteller om et tilfelle som ble introdusert i Chromium 64, mens det er først nå at Vivaldi-utviklerne begynner å få det skikkelig ryddet opp i.

– Da har vi lært at vi ikke for lenge skal gå på siden av det de andre gjør, sier Schultz.

Når de verste feilene har blitt rettet, fortsetter arbeidet enda en stund inntil man har en versjon som er stabilisert nok å kunne gå ut som et ferdig produkt.

– Da lager vi en ny branch av dette og gjør bare fikser for å få den stabilisert skikkelig før vi gir den ut til brukerne som en ferdig versjon. Dette prøver vi å få til innen en uke eller to etter den store Chromium-utgivelsen, sier Pettersen.

Plattformforskjeller

På spørsmål om det er noen større forskjeller mellom versjonene til Windows, Linux og Mac, sier Pettersen at særlig Mac-utgaven skiller seg ut når gjelder brukergrensesnittet.

– Selve UI-koden er temmelig lik på toppnivå på Windows og Linux med Aura-systemet, som de kaller det, mens det er en del egne ting på Mac. Ellers forsøker vi å ha det samme UI-et og feature-settet på alle, selv om det kan være andre ting i for eksempel Chromium som varierer litt, forteller han.

Hele det grafiske brukergrensesnittet er for øvrig webbasert.

Ny funksjonalitet

Parallelt med endringene som integreres under skallet, kjøres det hele tiden bygging av hovedkoden, som inkluderer Vivaldis egen funksjonalitet.

– Hver gang det kommer inn en ny «commit», så blir det laget en ny «build». Denne blir testet med en god del av testene til Chromium, samt noen av våre egne. Når det nærmer seg en «release», er det «QA» som sier ifra om dette holder eller ikke, sier Pettersen.

En slik stor, ny versjon av Vivaldi er på trappene. Den skal blant annet inkludere synkroniseringsfunksjonen som egentlig var ventet allerede i fjor. I stedet har den bare vært tilgjengelig i snapshot-utgaver av nettleseren.

PR- og kommunikasjonssjef Varsha Chowdhury hos Vivaldi vil ikke love for mye, men antyder at det bare gjenstår noen få uker.

– Synkroniseringen krever mer testing. Det er et lite team og det tar tid å få det riktig, sier hun.

Skalaforskjeller

Ifølge Pettersen er det under 20 utviklere hos Vivaldi. Han vet ikke nøyaktig hvor mange det er hos Google som jobber med Chromium, men det er selvfølgelig langt flere. For å gi et bilde av skalaforskjellen, sammenligner han mengden av commits de to teamene har gjort i det siste.

– Vi har totalt 17 tusen commits på hovedkoden vår siden 2013, altså på fem år. I løpet av det siste året, var det omtrent 2700 commits. Til sammenligning var ble det mellom Chromium 67 og 68 var det mellom 11 og 12 tusen commits. Det var 15 tusen mellom 68 og 69 på branch-punktet. I løpet av ti dager har de gjort det samme antall commits som vi har gjort på et år, sier han.

Han legger til at man ut fra disse tallene kan estimere at Chromium-teamet består av rundt 600 utviklere.

Med knapt 20 utviklere hos Vivaldi, er det begrenset hvor raskt de greier å utvikle ny funksjonalitet.

– Noe tar lang tid, og brukerne er utålmodige. Men slik som mobil og mail er store prosjekter som ikke skjer over natten, sier Chowdhury.

Andre ting kan derimot skje temmelig raskt

– Vanligvis tar det veldig kort tid fra vi kommer på ideen til vi har noe å teste. Vi har ikke voldsomt byråkrati for dette, sier Antonsen. Han forteller at sjefen selv, Jon von Tetzchner, er veldig involvert i både testingen og feedbacken.

Chowdhury mener feedbacken fra brukerne er helt avgjørende for utviklerne. Mange av endringene som kommer i nye versjoner av Vivaldi, er basert på tilbakemeldinger fra brukerne. Andre funksjonalitetsnyheter kan være ting Vivaldi-teamet selv savner.

– Ny funksjonalitet avhenger mye av hva brukerne våre ber om. Noen ganger kommer det inn en sprø idé som er enkel å implementere. For eksempel er det et par av tingene som vi vil se i den nye versjonen, som bare skjedde fordi det var en glimrende idé og det ikke var så tidkrevende å lage det, avslutter hun.

Les også intervjuet med Jon von Tetzchner: – Jeg skulle gjerne ha kodet mer selv

Informasjonen om hvor lenge Vivaldi har hatt tilgang til Chromium 69-koden har blitt korrigert i saken.