کمک به جمی

مشارکت به Jami همیشه خوش آمدید و بسیار قدردانی می شود. راه های زیادی برای کمک به Jami وجود دارد، از جمله گزارش اشکال و مسائل، کمک به کد، کمک به بسته بندی و نگهداری Jami برای توزیع GNU / Linux یا سیستم عامل دیگر، و همچنین کمک به خود این اسناد.

لطفاً در زیر ببینید که چگونه شروع به کمک به Jami کنید!

گزارش خطاها و مسائل

لطفا در راهنمای گزارش حشرات برای دستورالعمل های مرحله به مرحله در مورد چگونگی گزارش اشکال و مشکلات شما در Jami را ببینید.

کد کمک

If you want to start to contribute to Jami, you can start by looking good first issues at: https://git.jami.net/groups/savoirfairelinux/-/issues/?sort=created_date&state=opened&label_name%5B%5D=good%20first%20issue

You can contact developers directly by adding a comment on the ticket you want to start with. They will be able to guide you through the process.

At some point, you will need to push a patch on https://review.jami.net. For more information on how to do this, please refer to the developer/working-with-gerrit guide.

Commit message guidelines

When you submit a patch to Jami, please follow these guidelines for your commit messages:

  • The first line should include the component or scope of the change, followed by a short summary of the change in the imperative mood (e.g. "add new function", "fix bug", "update documentation").

  • The subject can use the capitalization of the component or scope, but the rest of the title should be lowercase.

  • The second line should be blank.

  • The third line should be the beginning of a longer description of the change in complete sentences, if necessary.

  • 50/72 rule: The first line should be no longer than 50 characters (ideally), and the rest of the message should be wrapped at 72 characters per line. This can be configured in your text editor.

  • If the change is related to a specific issue in the Jami GitLab, include the issue number in the commit message. For example: GitLab: #123. If the change is related to multiple issues, list them all. If the change is related to an issue that is not part of the project, use a link to the issue instead.

Template for a commit message:

<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]

مثلاً:

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

There is two possible ways to package Jami: + Via our internal process to create packages available on the Snap Store or https://dl.jami.net + Via the packaging process of your favorite GNU/Linux distribution

توجه

Jami is a quite complex project with a lot of dependencies. This isn't a quick and easy task and ask for some maintenance.

If you choose the second option, here are some useful notes: + For our official release, we stick to a certain Qt version, because Qt is a big dependency and we need to ensure that Jami works with the version we use. Every slight change in the Qt version can break Jami or bring some small unwanted changes (e.g. 6.2->6.4 broke the video pipeline) + We also fork pjproject due to ICE over TCP that is not planned upstream + libupnp got some patches to be sure that it's build with the non-blocking API. + FFMpeg got some patches for screen sharing. + You can check how dependencies are built in daemon/contrib/src

For internal packaging, everything is located in extras/packaging/gnu-linux. You can follow previous patches to understand your needs. e.g.: https://review.jami.net/c/jami-client-qt/+/28036

We use 3 channels: + Internal for testing purposes + Nightly/Beta/Edge for public beta + Stable for public releases

We generally use internal when we test new distribution or when we package a new Qt version Then we try to generate a nightly per week and one stable per month (if unit tests are green).

Packages are pushed to: + dl.jami.net (2 machines, with a rsync every 15 min) + Ubuntu store (snapcraft.io/jami)

If you want to add a new distribution, you will need to: + Add Dockerfile + Change Makefile + Update packaging script + Cross fingers + Test the package in a VM

توجه

Chromium is a hard part to build. Three common problems encountered are:

  • GCC is too recent:

    • Generally the fix consist of importing patches from Chromium's gerrit to fix GCC issues

  • Python is too recent:

    • Generally the fix consist of using PyEnv to get a virtual environment with the correct Python's version

  • Missing dependencies:

    • During the configuration step of Qt, the list of built components is listed and the missing dependencies are listed. Generally installing a package or updating node.js fix the issue

    • Note that if Qt is generated without chromium, we must remove the package in the cache of the build machines to regenerate a new one (/var/cache/jami)

If you want to remove a distribution: + If a distribution is EOL OR if there is 2 more recent LTS, we can remove the distribution (e.g. ubuntu 20, 22, 24 - remove ubuntu 20) by removing related files and checks

توجه

For the next big changes we want to:

  • Use CMake instead autotools for jami-daemon

  • Use core22 instead core20 in snap

  • Flatpak/AppImage support? This may simplify custom packaging for RPMs/Debs

  • Only generate one deb instead one per distribution. Same for RPMs

  • Use Jenkinsfile to generate package for Linux/Windows/MacOs at the same time if possible

For internal information (such as how to publish to stores, cf internal wiki).

کمک به این اسناد

مشارکت در این اسناد همیشه از نظر کوچک تا فصل های جدید مورد استقبال و قدردانی قرار می گیرد.

این صفحه مراحل ایجاد یک صفحه جدید یا ارسال یک تصحیح را طی می کند. روند بررسی پیچ همان عمل است که برای هر پروژه دیگر Jami انجام می شود. بنابراین ما هر دستور را توضیح نخواهیم داد.

توجه

با کمک به این اسناد، شما موافقت می کنید که کمک های خود را تحت نسخه:doc:fdl، نسخه 1.3 یا هر نسخه بعدی منتشر شده توسط بنیاد نرم افزار آزاد، بدون بخش های غیر متغیر، بدون متن های پوشش پیش و بدون متن های پوشش عقب، در دسترس قرار دهید.

شما همچنین قول می دهید که شما نویسنده ی تغییرات خود هستید یا که آنها را از یک اثر در حوزه عمومی یا اثر منتشر شده تحت مجوز رایگان که با GNU Free Documentation License سازگار است کپی کرده اید.

توجه

If you want to help to translate this page, you can join the project and start translating this page on https://explore.transifex.com/savoirfairelinux/jami/

وابستگی ها

شما نیاز به Git نصب و پیکربندی شده برای استفاده از کلید SSH خود را، و یک حساب در Jami Gerrit، که شما می توانید پیچ های خود را برای بررسی ارسال. اگر شما نیاز به کمک با این، ببینید:doc:` آغاز ما پیچ ارسال راهنمای <how-to-submit-a-patch>` (TODO).

اگر می خواهید تغییرات خود را در وب مرورگر خود پیش نمایش کنید، باید Sphinx، Read the Docs Sphinx theme، و MyST Markdown parser را نصب کنید.

$ pip install --upgrade sphinx sphinx_rtd_theme myst_parser

اگر می خواهید از ویژگی ساخت خودکار و تجدید خودکار استفاده کنید، همچنین sphinx-autobuild را نصب کنید.

$ pip install --upgrade sphinx-autobuild

کلون کردن مخزن

کلون مخزن و تنظیم تنظیمات فشار را به این شکل:

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

شما ممکن است بخواهید قبل از اینکه هرگونه تغییر در پرونده ها را انجام دهید، برای هر سهم/تبدیل یک شاخه جدید را چک کنید، تا بتوانید به راحتی git pull هر تغییر آینده را از جریان بالا به شاخه اصلی محلی خود منتقل کنید:

$ git checkout -b my-example-change

ویرایش یک صفحه

صفحات به صورت نشان داده شده یا reStructuredText نوشته می شوند. شما می توانید روی "دید منبع صفحه" در بالای هر صفحه کلیک کنید تا منبع خام صفحه را باز کنید و ببینید که چگونه نوشته شده است.

ادامه دهید و تغییرات خود را به فایل های .rst یا .md انجام دهید.

بررسی کار شما

از پایه مخزن، اجرا کنید:

$ make clean && make html

شما باید اکنون بتوانید اسناد را در مرورگر وب خود مشاهده کنید. صفحه اصلی در ``_build/html/index.html`.

توجه

This documentation does not currently build with the latest version of sphinx. Please see this issue on GitLab for a workaround and updates regarding this problem.

برای ایجاد خودکار اسناد و تازه کردن مرورگر وب شما هر بار که تغییرات را ذخیره کنید، اجرا کنید:

$ make clean && make watch

این را در پس زمینه اجرا کنید، سپس به http://127.0.0.1:8000 بروید (نه فایل.html محلی).

نجات کارتون

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

Refer to the commit message guidelines for how to write a good commit message.

ارسال یک تغییر

اولین بار که سعی می کنید تغییرات خود را فشار دهید، گریت شکایت می کند که شما یک تغییر شناسه در تعهد خود ندارید و یک دستور scp را برای نصب خط تعهد ارائه می دهد. پس از اجرای دستور، شما باید بتوانید تغییر خود را دوباره انجام دهید و فشار دهید:

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

تغییر کاری که انجام می دهید

یک بازرس ممکن است از شما بخواهد قبل از ترکیب آن تغییراتی در پیوند خود ایجاد کنید. این مشکلی نیست! فقط تغییراتی را انجام دهید، git add` آنها را انجام دهید و git commit را اجرا کنید تا پیوند را تغییر دهید. توجه به سوئیچ ``-amend, که برای گفتن به git که amend/tweak جدیدترین تعهد موجود را به جای انجام یک تعهد جدید انجام دهد. این جریان کار برای بروزرسانی تغییر پیشنهادی هنگام استفاده از Gerrit است.

اضافه کردن یک صفحه

اگر تصمیم بگیرید که یک صفحه جدید به اسناد اضافه کنید، باید آن را به دستورالعمل toctree در آن فصل اضافه کنید.

به عنوان مثال، اگر یک صفحه جدید به نام hosting-jams-on-aws-guide.md در دستور کار کاربر Jami در پوشه user اضافه کردید، باید آن را در دستورالعمل toctree از user/index.rst، بدون تمدید فایل اضافه کنید:

.. toctree::

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