Development/GetInvolved/da

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.


 * Grafisk kodeoverblik
 * Dokumentation om specifikke moduler
 * Hvordan oprettes en brugerdefineret kontrol?
 * DrawingLayer: hvad skal du vide om det?
 * FAQ = OSS (Ofte stillede spørgsmål)

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 [mailto:libreoffice@lists.freedesktop.org libreoffice@lists.freedesktop.org]; vi anbefaler dig at abonnere. Du kan også følge listen online på [mailto:libreoffic e@lists.freedesktop.org libreoffice@lists.freedesktop.org].

Til chat i realtid bruger vi IRC på freenode-netværket

Byg LibreOffice
For at udvikle har du brug for en lokal kopi af kildekoden. Hele koden findes i git

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.

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:


 * Alle bekræftede fejl, der for tiden ikke er tildelt
 * Åbne problemer
 * Mest irriterende fejl

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.

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 !! make skal være 3.8.1 eller højere
 * din masterfil er mere end en uge gammel.
 * din nye fejlrettelse er afhængig af arbejder, som netop er blevet flettet ind.

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.

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 masterfilen) til hver fejl, du arbejder på. Så snart rettelsen er blevet flettet ind, kan du slette grenen.

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  


 * hvis der er en fejlrapport med forbindelse til indsendelsen, er det obligatorisk at starte første linje med en fejlhenvisning såsom (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, 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.

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

Revision af din ændring
Din ændring vil typisk blive revideret i løbet af 1-2 dage. Du kan følge status på gerrit og du vil også modtage post, når der sker ændringer. (Bliv ikke bekymret, hvis Jenkins rapporter, at kun Windows-konstruktionen ikke ikke klarede den automatiske kompilering.)

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”


 * The committer reviewed and tested the patch successfully, then merged it (congratulations)
 * The committer had some comments, which you need to look at
 * Sometimes the patch breaks some other functionality and is marked as “Cannot merge”

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

Brug af og
Hvis du kigger på din ændring på Gerrit, vil du se to statuskoder.


 * Code-Review
 * Verified

Korrekturlæserne, vort CI-system (jenkins) og muligvis dig selv, vil bruge disse to felter til at kvalificere ændringen.

kan markeres som -2, -1, 0, +1, +2
 * Code-Review

-2 skal anvendes af forfatteren for at signalere "igangværende arbejde". -2 forhindrer ændringen i at blive flettet og kun den, der har lavet markeringen -2, kan fjerne den.

Hvis du arbejder på en større ændring, er du meget velkommen til at uploade en ændring og markere den -2, for at se om den kompileres med succes på alle platforme

-1 bruges af korrekturlæseren, hvis der er ting i rettelsen, der skal ændres

0 bruges, når der skrives kommentarer, der ikke påvirker, om ændringen skal flettes eller ej.

+1 bruges af korrekturlæseren til at signalere, at rettelsen er OK, men korrekturlæseren ønsker en ekstra vurdering

+2 bruges af forfatteren til at signalere, at der ikke er brug for korrektur (dette kan kun gøres af kerneudviklerne, og skal bruges med forsigtighed) Den person, der fletter din rettelse, vil bruge +2 lige før fletningen, eftersom kun +2 kan flettes. Evnen til sætte markeringen +2 afhænger af korrekturlæserens push-rettigheder. Disse rettigheder tildels individuelt.

Bemærk, at din rettelse IKKE vil blive flettet, så længe der er ubesvarede -1 eller -2.

Kan markeres som -1, 0, +1
 * Verified

-1 bruges af CI-systemet, hvis konstruktionen fejler (bemærk, at der ikke altid er et problem med din rettelse, men kan skyldes en ødelagt masterfil).

-1 bruges af korrekturlæseren, hvis det ventede resultat ikke kan ses.

0 bruges, når der skrives kommentarer, der ikke påvirker, om ændringen skal flettes eller ej.

+1 bruges af CI-systemet, hvis konstruktionen sker med succes

+1 bruges af korrekturlæseren, når det ventede resultat er bekræftet.

Bemærk, at en rettelse IKKE bliver flettet, medmindre CI-systemet viser en vellykket konstruktion.

Opdater en rettelse
Tjek din gren

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

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

Licenserklæring
Vi vil holde kildekoden fri til brug for enhver. Derfor er det vigtigt at du sender (brug venligst Emnet: license statement) en licenserklæring til [mailto:libreoffice@lists.freedesktop.org libreoffice@lists.freedesktop.org] med teksten: All of my past & future contributions to LibreOffice may be   licensed under the MPLv2/LGPLv3+ dual license. En mindre variation for at passe til din personlige smag er fint, så længe intention er klar. Du vil modtage en velkomstbesked som svar. 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.

Roadmap for personal growth
A developer needs to have specific skills/experience in order to be able to work on LibreOffice Code. This is the path suggested for anyone who wants to get involved in LibreOffice development:


 * 1) Understand intermediate level C++: Most of the LibreOffice code is in C++, so one should be fluent with C++ in order to be able to work with the code.
 * 2) Understand git and gerrit: git is the version control software that is used in LibreOffice. One should understand git and gerrit in order to be able to contribute
 * 3) Be able to build LibreOffice: To be able to change the code, one should be able to build LibreOffice from the sources.
 * 4) Do at least 10 bug triages: Developers should understand Bugzilla and the workflow associated with bugs and features. This is essential in order to be able to proceed.
 * 5) Do at least 5 EasyHacks with difficulty beginner (C++): The first step towards being able to understand and change the code.
 * 6) Do at least 5 EasyHacks with difficulty medium (C++): After doing some easier tasks, it is important to be able to do some more serious work.
 * 7) Do at least 1 EasyHacks with difficulty interesting
 * 8) Fix at least 5 regressions: Regressions are usually easy to reproduce, and can be fixed in a reasonable amount of time, so they are suitable for the newcomers
 * 9) Reach certain number of commits (~60)
 * 10) Do at least 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:


 * 1) Prøv selv at finde vejledningen eller løsningen selv. Sommetider vil dine hjælpere også være nødt til at lede selv.
 * 2) Hvis din søgning lykkes, gør et forsøg på at følge instrukserne.
 * 3) 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 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.