Udvikling/Engager dig

This page is a translated version of the page Development/GetInvolved and the translation is 100% complete.

TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate

Other languages:

Udviklere og brugere kan bidrage til udvikling af LibreOffice på mange måder og alle er velkomne i projektet.

Brugere kan fx hjælpe til med udviklingen ved at beta-teste udgivelser af softwaren, reportere og teste fejl, skrive dokumentation, bidrage til skabeloner, opdatere synonym- og retskrivningsordbøger, oversætte til dit modersmål, tilføje billeder, sprede budskabet og promovere LibreOffice.

På denne side koncentrerer vi os om udviklere. Vi er en af de største, ældste og mest kendte (som OpenOffice) frie software-pakker. Hvis du studerer eller leder efter ansættelse, er det et stort plus på dit CV at kunne skrive "Jeg har arbejdet for LibreOffice". Udviklere hjælper til med at forbedre LibreOffices kodebase. I begyndelsen kan den enorme kodebase virke skræmmende, men dokumentationen forbedres og du vil blive støttet af det eksisterende udviklingsteam. Denne side til hjælpe dig med at få sendt din første rettelse. Hjælpe dig med at få overblik.

Trin-for-trin vejledning for nye udviklere

Det er let at blive overvældet af LibreOffices størrelse og kompleksitet. Kilden er skrevet i mange forskellige sprog og formater  — C, C++, Java, Bash, JavaScript, Python, Perl, SQL, Test, XML — og består af rundt regnet 102.000 filer (alle lokaliseringer undtaget) med 36.000.000 tekstlinjer (7.000.000 linjer kildekode)

Ingen forstår hele koden i detaljer, men vi har mange kerneudviklere, som hver for sig kender en del af koden til bunds. Denne trin for trin vejledning viser en let vej fra "ønsker at bidrage" til succesfuldt at have den første rettelse flettet ind i master(filen).

Forbindelse til vore kommunikationskanaler

Vores mailliste er libreoffice@lists.freedesktop.org; vi anbefaler dig at abonnere. Du kan også følge listen online.

Til chat i realtid bruger vi IRC på Libera Chat-netværket #libreoffice-dev ^IRC://

Byg LibreOffice

For at udvikle har du brug for en lokal kopi af kildekoden. . Kloning af kildekoden er forklaret i artiklerne med byggeinstruktioner til hvert operativsystem.

Windows

Windows-udviklere har brug for at hve Cygwin og andre værktøjer installeret. Det letteste er at bruge LibreOffice Development Environment (LODE). det findes også detaljerede build-instruktioner til Windows.

macOS

Vi foreslår at følge de instruktioner, som bruger LibreOffice Development Environment (LODE). Flere oplysninger og detaljer om Xcode kan læses i artiklen Building LibreOffice under macOS.

Linux

Linux (de fleste varianter) kan sættes op med pakkeinstallatorer. Vi foreslår at du følger Programmering under Linux

Forbered indsendelse af rettelser

Når du først har kompileret LibreOffice med succes, er du klar til indsende rettelser. Vi bruger gerrit til at holde styr på rettelserne, så du har brug for at oprette en konto der. Følg denne gerrit guide til opsætning

Der er grundliggende to måder at indsende/arbejde med rettelser. Dem, der er fortrolige med Git review kan bruge det, men vi anbefaler et enklere værktøj ved navn logerrit.

Vær omhyggelig, når du indsender ændringer til undermoduler såsom Hjælp (og kun kloner Hjælp) eftersom gerrit-scriptet ikke er tilgængeligt og du måske ikke har gerrit-krogen installeret. Se opsætningstrin i Development/Submodules.

Find din første fejl at rette

Tillykke, du har nået den interessante del.

At rette den første fejl indebærer, at du lærer nye værktøjer og metoder, derfor har vi identificeret nogle lette fejl kaldet Easy_Hacks. Vi bruger bugzilla, hvor du har brug for at oprette en konto for at holde styr på rapporterede fejl.

Easy hacks er rigtige fejl, men kerne-udviklerne har tilføjet kode-pointere og sommetider tekst-hjælp, i stedet for bare at rette dem for at gøre det lettere for dig at rette fejlen. Vælg en fejl fra dit foretrukne programmeringssprog (se ovenfor), som interesserer dig EasyHacks efter sprog og færdighed. Som du ser, er der mange at vælge imellem. Vi anbefaler kategorien "Færdighedsniveau: Begynder" for at lade dig koncentrere dig om alle "hvordan gør jeg ....".

Når du først har valgt en fejl at rette, glem så venligst ikke at tildele den i bugzilla til dig selv, så andre kan se, at du arbejder på den. Hvis du vil arbejde på en af de generelle fejl (såsom at konvertere foo til xyz), lad venligst være med at tildele til dig selv, da mange kan arbejde på det parallelt. EasyHack bliver overvåget, så hvis der ikke er noget fremskridt efter en tid, fjerner vi tildelingen.

Selvfølgelig er der også andre udfordringer til senere:

Rette en fejl

Nogle praktiske råd, som vi pga. erfaring anbefaler, at du følger, er:

Foretag aldrig ændringer på din kopi af masterfilen - opret en gren i stedet.
Behold en særlig gren til hver fejl, og slet ikke grenen, før rettelsen er flettet ind.
Følg Kodetypografien (som fx plan for variabelnavne, osv.)
Hvis du opretter nye filer, brug venligst vores License-politik.
Undgå venligst større omformatering af koden i øjeblikket (ud over til nedenstående opgaver) - vi overvejer auto/magiske måder at gøre dette på på mellem til langt sigt
Opdater masterfilen, før du starter på en ny fejl (og kør make check for at bekræfte, at den kompilerer rent, før du foretager nogen ændringer).
Indsend inden rettelser, der er afhængige af hinanden, med mindre du bliver bedt om det. Ellers bliver dine rettelser umulige at flette ind.
Hvis din rettelse ikke er klar til at blive flettet ind, tildel den -2, så ved revisorerne, at der er arbejde undervejs.
Tålmodighed er en nøglen, korrekturlæsning tager tid og vi er alle frivillige, så forvent, at der går et par dage.

Foreslået arbejdsgang

1. Opdater master

Sørg for, at din masterfil er opdateret og virker. Hvis din masterfil er for gammel, løber du den risiko, at du ikke er stand til flette din ændring ind.

Som en tommelfingerregel skal du bruge kommandoerne herunder, hvis

din masterfil er mere end en uge gammel.
din nye fejlrettelse er afhængig af arbejder, som netop er blevet flettet ind.

./g pull -r
make
make check

!! make skal være 3.8.1 eller højere

Brug venligst kontakten-r, som er meget mere effektiv end simpelt træk. Masterfilen går ofte i stykker, men normalt kun i kort tid (indsendere reagerer normalt hurtigt, hvis de har lavet en forkert rettelse).

Når make afsluttes, ved du, at du har en fungerende masterfil, så hvis make går ned under kompileringen af din rettelse, skyldes det et problem et-eller-andet sted i din kode. make check kører alle testtilfælde og sikrer, at du har en fungerende version af LibreOffice. Kørsel af en simpel make før make check koster dig ikke byggetid og i tilfælde af fejl, sikrer den dig at du har et build, som kører.

2. Arbejd på en gren

Du kan blive bedt om at ændre din rettelse, og hvis du har oprettet og arbejdet på en særlig gren, vil det være meget let. Brug venligst en ny gren (fra oprindelse/masterfilen) til hver fejl, du arbejder på. Så snart rettelsen er blevet flettet ind, kan du slette grenen.

git checkout -b test1 origin/master

Giv test1 det navn, du foretrækker.

3. Ret fejlen

Identificer problemet, ret koden, generer og afprøv en version. Husk at levere en enheds-test, når det er muligt for at verificere at problemet er løst.

Der findes et antal praktiske og hjælpsomme værktøjer

OpenGrok - brug det til søge i og gennemse kodebasen
Konverter java enheds-test til python
cgit commit log
gerrit-oversigt til LibreOffice

Husk nu at køre en git commit -a jævnligt. Det giver dig mulighed for let at opgive en del af din udvikling, hvis det skulle vise sig at være en forkert vej.

4. Indsend rettelsen

Det anbefales, at dine indsendelsebeskeder ligner denne:

   tdf#12345 <short developer description of change, not just the bug title>
   <empty line>
   <description of what the patch does, the more words the better others understand it later>

hvis der er en fejlrapport med forbindelse til indsendelsen, er det obligatorisk at starte første linje med en fejlhenvisning såsom tdf#12345 (se detaljer nedenfor)
brug resten af den første linje som en kortfattet sammendrag af dine ændringer. Maximumlængden på denne linje er 72 tegn.
brug nutid. fortæl, hvad ændringen gør. Vær skarp. Undgå "pynt" som streger og parenteser, som spilder plads.
Hvis du vil skrive mere tekst end det, der passer i den første linjer, er det obligatorisk at lade anden linje være blank
fra 3. linje forklarer du, hvad rettelsen gør og hvorfor, og hvis det ikke klart, også hvordan. Disse linjer skal højst være på 80 tegn, del i flere linjer, hvis din kommentar er længere. Her kan du også beskrive, hvordan koden virkede ukorrekt før ændringen.

Hvis din rettelse ordner en fejl, som allerede er registreret i Bugzilla, kan du drage fordel af automatiske fejl-beskeder, som udløses af indsendelsesmeddelelser. Når den første linje af indsendelsesmeddelelsen indeholder en henvisning til en fejl på formen tdf#12345, vil en tilsvarende kommentar automatisk blive tilføjet fejlrapporten, når ændringen sendes til depotet. Find flere oplysninger på annoncerings-tråden på mail-archive.com eller på fdo-listarchive.

Kontrollér, at dine ændringer ikke ødelægger automatisk testning.

make check

Nu kan du indsende ændringen til gerrit (se Forbered indsendelse af rettelser):

./logerrit submit master

Revision af din ændring

I tilfælde af easy hacks, tilføjer den person som indsatte kodepegerne som korrekturlæser på din rettelse. du vil modtage en e-mail, hver gang der er en ændring i din rettelse.

Generelt kan der ske 3 ting i revisonen:

Indsenderen reviderede og testede ændringen med succes, og flettede den til masterfilen (tillykke)
Indsenderen har nogle kommentarer, som du er nødt til se på
Sommetider ødelægger ændringen en anden funktionalitet og er mærket som “Cannot merge” (kan ikke flettes)

I de sidste 2 tilfælde, skal du opdatere din ændring.

For mere om processens patchgennemgang, se Development/gerrit/PatchReview.

Opdater en rettelse

Tjek din gren

git checkout test1

foretag de nødvendige ændringer og test dem. Det er høfligt at kommentere de kodelinjer, du ikke vil ændre eller hvor du ikke er enig med indsenderen, dette gøres direkte i gerrit.

Når du er parat til at indsende igen, er det vigtigt, at du bruger —amend

git commit --amend -a

Vigtigt Brug ikke parameteren -m, da det vil slette gerrits rettelses-id. Lad git åbne en tekstbehandler, der lader dig redigere indsendelsesmeddelelsen (eller lad den være uændret). Mens du redigerer, skal du passe på ikke at fjerne/ændre den sidste linje med rettelses-id-et.

Dette vil sikre, at du opdaterer rettelsen i stedet for at genere en ny (med et nyt Change-id:)

Upload det nye rettelsessæt til gerrit

./logerrit submit master

Licenserklæring

Vi vil holde kildekoden fri til brug for enhver. Derfor er det vigtigt at du sender (brug venligst Emnet: <dit navn> license statement) en licenserklæring til libreoffice@lists.freedesktop.org med teksten:

   All of my past & future contributions to LibreOffice may be
   licensed under the MPLv2/LGPLv3+ dual license.

Det er vigtigt at sikre sig, at mailen tillader at forbinde erklæringen med bidragene, så send erklæringen fra den samme e-mail, som bruges i dine commits.

En mindre variation for at passe til din personlige smag er fint, så længe intention er klar. Vi vedligeholder en liste over udviklere på vorwiki.

Send venligst ikke erklæringen før du sender dit første bidrag til gerrit. Hvis du er mindreårig, skal du bede dine forældre eller værger (alle personer, der har værgemål) om at sende e-mailen.

Hvis du vil bidrage med kunstnerisk arbejde, som bliver anvendt i softwaren (som fx ikoner), tilføjer du dette til din licens-erklæring i e-mailen:

   Additionally, to the extent possible under law, I waive all
   copyright and related or neighboring rights to my past & future
   Artwork and Design contributions to the LibreOffice project, and
   similarly to The Document Foundation, placing such contributions
   under CC0: https://creativecommons.org/publicdomain/zero/1.0

Tillykke

Du har lavet en vellykket ændring til en af de mest populære open-source-pakker i verden.

Forsæt med at lave rettelser og du vil snart selv være committer.

Vejviser til personlig vækst

En udvikler er nødsaget til at bestemte evner/erfaringer for at kunne arbejde med LibreOffice-kode. Denne foreslås til enhver, der vil engagere sig i udvikling af LibreOffice.

Forstå C++ på mellemniveau: Det meste LibreOffice-kode er i C++, så du bør være flydende i C++ for at være i stand til at arbejde med koden.
Forstå git og gerrit: git er den versionskontrol- software, der bruges i LibreOffice. Du skal forstå git og gerrit for at være i stand til at bidrage
Være i stand til at bygge LibreOffice: For at være i stand til at ændre koden, skal du være i stand til at bygge LibreOffice fra kilderne.
Foretag mindst 10 fejltriager: Udviklere skal forstå Bugzilla og arbejdsgangen i forbindelse med fejl og funktionaliteter. Det er væsentligt for at være i stand til at forsætte.
Foretag mindst 5 EasyHacks på begynderniveau (C++): Det første trin til at være i stand til at forstå og ændre koden.
Foretag mindst 5 EasyHacks på mellemniveau (C++): Efter

at have udført nogle lettere opgager, er det vigtigt at være i stand til at gøre noget mere alvor After doing some easier tasks, it is important to be able to do some more omfattende arbejde.

Foretag mindst 1 EasyHack på niveauet interessant
Klar mindst 5 regressioner: Regressioner er normalt lette at reproducere og kan fikses på en fornuftig tid, så de er egnede til nybegyndere
Nå et vist antal indsendelser (~60)
Foretag mindst 1 CoreHack

Begynderetikette

Erfarne bidragsydere vil hjælpe dig med at finde løsninger på dine problemer, men der er forventninger og begrænsninger. Fjern-mentor og -fejlfinding er en større kognitiv belastning end at være fysisk til stede. Når du viser dig velforberedt, vil folk være mere motiverede for at hjælpe dig.

Generelle retningslinjer:

Når du bruger chatten: beskriv straks dit problem og bliv på kanalen i mindst en time.
Til at dele tekst med flere linjer på chatten bruger du en indsæt-tjeneste som den, der nævnes i kanalens emne.
Hvis du har problemer med netværksforbindelsen, fungerer postlisten bedre end chatten.
Hvis du arbejder med em kompleks flertrins opgave, er det en god ide tage personlige notater. De bliver meget nyttige, når du bliver spurgt om, hvad du foreløbig har lavet.
Når du har fået et svar, kvittér på en eller anden måde. Hvis du forsvinder uden et spor, bliver dine hjælpere chokerede.

Hvis du står over for et problem med git, indsendelse af rettelser eller opsætning af udviklingsmiljøet, er det bedst af følge disse trin:

Prøv selv at finde vejledningen eller løsningen selv. Sommetider vil dine hjælpere også være nødt til at lede selv.
Hvis din søgning lykkes, gør et forsøg på at følge instrukserne.
Hvis du ikke fandt nogen instruktion eller blev hængende i anvendelse af dem, bed om hjælp.

Med disse slags vanskeligheder vil hjælperne med glæde prøve at løse hele dit problem for dig.

Hvis du løser et eassy hack, er det godt at huske på disse kendsgerninger og tips:

Der findes ikke noget enkelt dokument, der forklarer koden i klart sprog. Undervisningsmateriale er spredt over dias fra konferencepræsentationer, blogposter og wiki-sider.
Hyppigheden af kommentarer er mindre end ideel (du kan hjælpe!), så du må være forberedt på at læse kode.
Brug git grep, en IDE og OpenGrok til at finde de definitioner og klasser, du løber på.
Undersøg også indsendelseshistorien for lignende emner andetsteds i kodebasen. OpenGrok's Annotate-kommando kan være oplysende i denne slags detektivarbejde.
Kør en debugger, mens du bruger LibreOffice, for at finde ud af, hvad der sker under motorhjelmen.
Gennemgå readme-filerne.

Hvis du beder nogen om at sige, hvordan man implementerer noget, vil du sandsynligvis blive mødt med tavshed. Easy hacks regnes for at være en læringsøvelse og mentorer ønsker ikke at ødelægge den. En foreslået implementering vil blive kommenteret i korrektursystemet.