Osallistu

Apu Jamille on aina tervetullutta ja sitä arvostetaan suuresti. On monia tapoja osallistua Jamin kehitykseen, mukaan lukien:

  • Bugeista ja ongelmista ilmoittaminen,

  • Kehittää koodia,

  • Auttamalla Jamin paketoinnissa ja ylläpidossa sinun GNU/Linux-jakeluun tai muille käyttöjärjestelmille,

  • Kehittämällä Jami dokumentaatiota.

Katso alta, kuinka voit aloittaa osallistumisen Jamiin!

Bugeista ja ongelmista ilmoittaminen

Katso Bug report guide ohjeita miten voit ilmoittaa Jamin kanssa mahdollisesti kohtaamistasi ongelmista.

Kehittää koodia

Aloita Jamin kehitystyö tutustumalla hyvin ilmoitettuihin ongelmiin: https://git.jami.net/groups/savoirfairelinux/-/issues/?sort=created_date&state=opened&label_name[]=good first issue .

Ota yhteyttä suoraan muihin kehittäjiin lisäämällä kommentti tikettiin. Näin he voivat opastaa sinua koko prosessin läpi.

Koodin lisäämiseksi Jamiin tarvitaan push-korjaus osoitteessa https://review.jami.net.

Katso myös

Lisää tietoja miten push-korjaus siirretään, katso Working with Gerrit oppaasta.

Kommentointiviestin ohjeet

Kun lähetät ”patch” korjaustiedoston Jamille, noudata seuraavia kommentointiviestiin liittyviä ohjeita:

  1. Ensimmäisellä rivillä tulee olla muutoksen kuvaus otsikkona, jota seuraa lyhyt yhteenveto muutoksesta mitä se tekee (esim. ”add new function”, ”fix bug”, ”update documentation”).

  2. Otsikon aiheessa voi käyttää isoja kirjaimia, mutta muun otsikon tulee olla pienillä kirjaimilla.

  3. Toisen rivin tulee olla tyhjä.

  4. Kolmannella rivillä tarvittaessa koko lauseen mittainen kuvaus muutoksesta.

  5. 50/72-sääntö: Ensimmäinen rivi ei saa olla pidempi kuin 50 merkkiä (ihannetapaus), ja loput viestistä tulee rivittää 72 merkin pituiseksi riviä kohden. Voit tehdä tämän tekstieditorissasi etukäteen.

  6. Jos muutos liittyy tiettyyn ongelmaan Jami GitLab:ssa, lisää ongelman numero viestiin esim. ”GitLab: #123”. Jos muutos liittyy useisiin ongelmiin, luettele ne kaikki. Jos muutos liittyy ongelmaan, joka ei ole osa projektia, käytä numeron sijaan linkkiä missä ongelma mainitaan.

Malli commit-viestistä:

<Component/Scope>: <short Summary (imperative, max 50 characters)>

<Detailed description (in present tense) of what was changed and why
it was necessary, wrapped at 72 characters per line to maintain
readability. Include any important details that help others understand
the context of the change. Use this space to explain complex changes
or provide background information.>

[GitLab: #<issuenumber>] or [Link to issue]

Esimerkki:

ConversationView: add a new function

Adds a new function to the ConversationView class that allows
the user to sort conversations by date. This function is necessary
to improve the user experience and make it easier to find specific
conversations.

GitLab: #123

Jami paketointi

Jamin voi paketoida kahdella tavalla:

  1. Meidän prosessin kautta joka luo asennuspaketin saataville Snap Store:sta tai https://dl.jami.net.

  2. Sinun GNU/Linux-jakelusi paketointiprosessin kautta.

Tärkeä

Jami on melko monimutkainen projekti, jossa on paljon riippuvuuksia. Tämä ei ole nopea tai helppo tehtävä ja vaatii huoltoa.

Muista

Jos Jami on paketoitu käyttäen toista vaihtoehtoa:

  • Virallisissa julkaisuissa Jami käyttää tiettyjä Qt versioita, koska Qt:llä on riippuvuuksia. Varmistetaan, että Jami toimii käyttämämme version kanssa. Jokainen pieni muutos Qt-versiossa voi rikkoa Jamin tai tuoda ei-toivottuja pieniä muutoksia. Esimerkiksi 6.2 → 6.4 rikkoi video pipeline putken.

  • Jami käyttää pjproject, haaraa koska ICE-TCP:n yli vaaditaan. Tätä emme ole suunnitelleet ylävirtaan.

  • libupnp sai joitain patch-korjauksia varmistaakseen, että se on rakennettu non-blocking API:lla.

  • FFmpeg sisältää joitain patch-korjauksia näytön jakamiseen.

  • Katso riippuvuuksien rakentaminen ”daemon/contrib/src”.

Paketoinnin osalta kaikki löytyy ”extras/packaging/gnu-linux”. Voit seurata aiempia korjaustiedostoja ymmärtääksesi mitä tarvitset. esim.https://review.jami.net/c/jami-client-qt/+/28036

Jamilla on 3 julkaisukanavaa:

  • Sisäinen testausta varten

  • Nightly/Beta/Edge julkiselle betaversiolle

  • Stable julkisia vakaita julkaisuja varten

Käytämme yleensä sisäistä ”internal”, kun testaamme uusia jakeluja tai paketoimme uutta Qt-versiota. Nightly-version luomme kerran viikossa ja vakaan stable-version kerran kuukaudessa (jos kaikki testit ovat vihreitä).

Paketit lähetetään:

Jakelun lisääminen:

  • Lisää Docker-tiedosto

  • Muuta Make-tiedosto

  • Päivitä paketointiskripti

  • Sormet ristiin

  • Testaa pakettia VM:llä

Varoitus

Chromium on vaikea osa rakentaa. Kolme yleistä ongelmaa ovat:

  • GCC on liian tuore:

    • Yleensä korjaus koostuu korjaustiedostojen tuomisesta Chromiumin gerritistä GCC-ongelmien korjaamiseksi

  • Python on liian tuore:

    • Yleensä korjaus koostuu käyttämällä PyEnv virtuaalisen ympäristön saamiseksi oikealla Python-versiolla

  • Puuttuvat riippuvuudet:

    • Qt:n määritysvaiheen aikana listataan rakennettujen komponenttien luettelo ja puuttuvat riippuvuudet. Yleensä paketin asentaminen tai node.js:n päivittäminen korjaa ongelman

    • Huomaa, jos Qt luodaan ilman chromiumia. Paketti tulee poistaa cache-välimuistista kääntävällä koneella, jotta voidaan luoda uusi (/var/cache/jami)

Jakelun poistaminen:

  • Jos jakelu on vanhentunut, eli EOL, TAI 2 uudempaa LTS sukupolvea, jakelu voidaan poistaa (esim. Ubuntu 20, 22, 24 – poistamme Ubuntu 20) ja siihen liittyvät tiedostot ja tarkistukset.

Muista

Seuraavat suuret muutokset ovat:

  • Käytä CMake sijaan autotools jami-daemon:lle.

  • Käytä Ubuntu Core 22 (UC22) sijaan core20 snap:lle.

  • Flatpak/AppImage tuki? Saattaa yksinkertaistaa mukautettua RPM/Debian-paketointia.

  • Luo vain yksi yhteinen Debian-asennustiedosto ja yksi RPM-asennustiedosto.

  • Luo Jenkinsfile paketit GNU/Linuxille, macOS:lle ja Windowsille samanaikaisesti, jos mahdollista.

Kuvauksen tietoja varten (kuten kuinka kuvaus julkaistaan storessa tai ohjemistopuodissa, ks. Wiki:stä).

Kehitä tätä dokumentaatiota

Dokumenttien kehitysapu on aina tervetullutta ja arvostettua apua pienistä korjauksista kokonaan uusiin lukuihin.

Käydään läpi vaiheet, joilla voit luoda uuden sivun tai lähettää korjauksen. Korjauksen tarkistusprosessi on sama kuin muissakin Jami-projekteissa, joten jokaista komentoa emme tässä selitä.

Muista

Osallistumalla dokumentaatioon sitoudut antamaan sen saataville fdl, versiossa 1.3 tai missä tahansa uudemmassa Free Software Foundationin julkaisemassa versiossa; ilman vaatimuksia tekstiin.

Lupaat myös, että olet muutosten tekijä tai että kopioit ne julkisessa käytössä olevasta lähteestä tai teoksesta, joka on julkaistu ilmaisella lisenssillä, joka on yhteensopiva fdl kanssa. ÄLÄ LÄHETÄ TEKIJÄNOIKEUDELLA SUOJATTUA MATERIAALIA ILMAN LUPAA.

Katso myös

Jos haluat auttaa tämän sivun kääntämisessä, voit liittyä projektiin ja aloittaa kääntämisen osoitteessa https://explore.transifex.com/savoirfairelinux/.

Riippuvuudet

Git tarvitaan ja määritetään käyttämään SSH-avainparia ja [Jami Gerrit] tiliä (https://review.jami.net), jonne lähetät korjaukset tarkistettavaksi. Jos tarvitset apua, katso oppaamme korjaustiedoston lähettämisestä (TODO).

Jos haluat katsella muutoksia paikallisesti verkkoselaimessa, seuraavat on asennettava ensin:

$ pip install --upgrade sphinx sphinx_rtd_theme myst_parser

Jos haluat käyttää automaattista auto-build ja auto-refresh ominaisuutta, asenna myös sphinx-autobuild.

$ pip install --upgrade sphinx-autobuild

Arkiston kloonaus

Kloonaa arkisto ja määritä push-asetukset seuraavasti:

$ git clone "ssh://USERNAME@review.jami.net:29420/jami-docs.git"
$ cd jami-docs
$ git config remote.origin.push HEAD:refs/for/master

Sinun kannattaa virkistää aina haara ajan tasalle ennen kuin teet mitään muutoksia tiedostoihin. Jotta kaikki tulevat muutokset ”git pull” ylävirtaan ovat samaan tasoa sinun paikallisen haaran kanssa:

$ git checkout -b my-example-change

Sivun muokkaaminen

Sivut ovat kirjoitettu [Markdown]-kielellä (https://www.markdownguide.org/). Paina Näytä sivun lähdekoodi ”View page source” sivun yläreunassa ja se avaa sivun raakatekstinä ja näet, miten se on kirjoitettu.

Jatka ja tee muutokset .md-tiedostoihin.

Työsi esikatselu

Arkiston pohjalta, suorita:

$ make clean && make html

Sinun pitäisi nyt pystyä katsomaan dokumentaatiota selaimessasi. Kotisivu on ”_build/html/index.html”.

Varoitus

Tätä dokumentaatiota ei tällä hetkellä ole rakennettu uusimmalla Sphinx versiolla. Katso ongelma GitLab:ssa saadaksesi ideoita miten kiertää tämän ongelman.

Rakenna dokumentaatio automaattisesti ja virkistä selaimesi aina kun tallennat muutokset, suorita:

$ make clean && make watch

Pidä käynnissä taustalla ja siirry sitten ”http://127.0.0.1:8000” (ei paikallinen .html-tiedosto).

Tallenna työsi

$ git add source/file/you/edited.md
$ git commit

Katso commit message guidelines miten kirjoitat hyvän commit-kuvauksen.

Muutoksen lähettäminen

Kun yrität siirtää muutoksia ensimmäistä kertaa, Gerrit valittaa, että sinulla ei ole muutosoikeuksia Change-ID-tä ja antaa ”scp”-komennon asentaakseen commit-hook:in. Kun olet suorittanut komennon, sinun tulisi pystyä lähettämään uudelleen ja muutokset siirtyvät:

$ git commit --amend --no-edit
$ git push

Työsi muokkaaminen

Tarkistaja saattaa pyytää sinua tekemään muutoksia ennen muutoksen hyväksymistä. Tämä ei ole ongelma! Tee muutokset, ”git add” ja suorita ”git commit –amend”.

Muista

Vipu ”–amend”, joka tarvitaan käskemään Git amend/tweak olemassa olevaa siirtoa sen sijaan, että tekisit uuden siirron. Tämä on työtapa, jolla päivitetään ehdotettu muutos käytettäessä Gerrit:iä.

Sivun lisääminen

Jos päätät lisätä dokumenttiin kokonaan uuden sivun, sinun on lisättävä se myös kyseisen luvun ”toctree”-ohjaukseen.

Jos esimerkiksi lisäsit uuden sivun nimeltä ”hosting-jams-on-aws-guide.md” Jamin käyttöoppaaseen ”user”-kansioon, sinun tulee lisätä se ”user/index.md”-tiedoston toctree-ohjaukseen ilman tiedostopäätettä:

```{toctree}
:maxdepth: 1

bug-report-guide
hosting-jams-on-aws-guide
```