개발/참여하기

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

Outdated translations are marked like this.

TDF LibreOffice Document Liberation Project 커뮤니티 블로그 온라인 번역 도구(Weblate) Nextcloud Redmine 질문 후원

Other languages:

개발자와 사용자는 다양한 방법으로 LibreOffice 개발에 기여할 수 있으며 이 프로젝트는 모든 분들을 환영합니다.

Users can, for instance, help the development by testing beta releases of the software, reporting and testing of bugs, writing documentation, contributing to templates, update thesaurus, dictionaries, translate to your native language, add art work, spreading the word and promote LibreOffice.

이 페이지에서는 "개발자" 에 초점을 맞추고 있습니다. 모든 레벨의 개발자에 대응하고 있습니다. LibreOffice는 가장 크고 가장 오래되고 가장 잘 알려진 프리 소프트웨어 패키지 중 하나입니다. (Open Office로서) 학생분들이나개발직장을찾고계신분들은이력서에'LibreOffice에서 일한 적이있습니다.'라고 쓸 수 있다는 것이 큰 장점입니다. 개발자는 Libre Office 코드 기반 개선을 지원합니다.처음에는 방대한 코드 베이스가 두려울지도 모르지만 문서는 개선되고 있으며 기존의 개발자 팀의 지원을 받게 됩니다. 이 페이지는 첫 번째 패치 전송에 도움이 됩니다. 개요를 보려면 다음 절차에 따르세요:

새로운 개발자들을 위한 단계별 가이드

Libre Office의 크기와 복잡함에 압도되기 쉽습니다. 소스는 다양한 언어와 형식으로 기술되었습니다. — C, C++, Java, Bash, JavaScript, Python, Perl, SQL, XML — and consists of roughly 102,000 files (excluding all localizations) with 36,000,000 lines of text (7,000,000 lines of source code).

모든 코드를 자세히 이해하는 사람은 아무도 없지만, 코드의 부분을 자세히 아는 핵심 개발자는 많습니다. 이 단계별 가이드는 첫 번째 패치를 마스터에 성공적으로 병합하기 위해 "기여하기를 원함"에서 시작하는 쉬운 방법을 보여줍니다.

Connect to our communication channels

Our mailing list is libreoffice@lists.freedesktop.org; we recommend you subscribe to it. You can also follow the list online.

For real-time chat we use IRC at the Libera Chat network #libreoffice-dev ^IRC://

LibreOffice 빌드하기

개발을 하기 위해서는 소스 코드의 로컬 복사본이 필요합니다. 모든 코드는 git에 저장되어 있습니다.

Windows

Windows 에서 개발을 하는 경우, Cygwin 등의 유틸리티를 따로 설치해야 합니다. 가장 쉬운 방법은 LibreOffice 개발 환경(LibreOffice Development Environment, LODE)을 이용하는 것입니다. Windows에서 빌드하는 상세 과정에 같은 정보도 존재합니다.

macOS

LibreOffice 개발 환경(LODE)를 이용하는 가이드를 따라해 보세요. Xcode에 대한 자세한 정보와 세부 사항은 macOS에서 LibreOffice 빌드하기에서 확인할 수 있습니다.

리눅스

대부분의 Linux 배포판에서는 패키지 설치 도구를 이용해 빌드 환경을 구성할 수 있습니다.리눅스에서 빌드하기를 따라해 보시기를 추천합니다.

패치 제출 전 준비 사항

LibreOffice 컴파일에 성공했다면, 패치를 제출할 준비가 된 것입니다. LibreOffice는 Gerrit을 이용해 패치를 추적하기 때문에 Gerrit 계정을 먼저 만들어야 합니다. Gerrit 구성 가이드를 따라해 보세요.

패치를 처리하거나 제출하기 위해서는 기본적으로 두 가지 방법이 있습니다. Git review 에 익숙한 경우 Git review를 사용해도 됩니다. 하지만, 더 단순한 도구인 logerrit 사용을 추천합니다.

help (및 help 만 복제(clone)하는 경우) 와 같은 서브모듈에 변경 사항을 커밋하는 경우 주의하세요. 관련 logerrit 스크립트가 존재하지 않을 수도 있고, Gerrit 후크가 설치되어 있지 않을 수도 있기 때문입니다. 구성 과정은 Development/Submodules를 참조하세요.

해결할 첫 버그 찾기

축하합니다. 이제부터가 흥미로운 부분입니다.

첫 번째 버그를 해결하려면 새로운 도구와 방법을 배워야 하기 때문에, 초심자를 위한 쉬운 버그는 Easy_Hacks에서 관리하고 있습니다. Bugzilla 에서 보고된 버그들을 관리하고 있으며, 이용을 위해서는 계정을 만들어야 합니다.

Easy hacks are real bugs, but the core developers have added source code pointers and sometimes textual help instead of simply solving them, to make it easier for you to solve the bug. Select a bug from your favorite programming language (see above) that interest you EasyHacks by language and skill, as you see there are plenty to choose from. We recommend you choose one from the category "Skill level: beginner", to allow you to concentrate on all the "how do I ....".

Once you have selected a bug to solve, please do not forget to assign it in bugzilla to yourself, so others can see you are working on it. If you want to work on one of the general bugs (like converting foo to xyz), then please do not assign it to you, since many can work on that in parallel. The EasyHacks are monitored so if there are no progress after a time we will unassign it.

Of course there are also other challenges for later:

버그 해결하기

Some practical advice, based on experience, which we recommend that you follow is:

Never make changes to your copy of master - create a branch instead.
Keep a separate branch for each bug, and do not delete the branch until the bug-fix is merged.
follow the Code Style (such as variable naming schemes, etc.).
If you create new files, please use our License Header.
Please avoid larger reformatting of the code for the time being (except for the tasks listed below) - we're pondering auto/magic ways to do that mid- to long-term.

Update master before starting on a new bug (and run make check to confirm it compiles cleanly before you make any changes).
Do not submit patches that depend on each other, unless being told to do so. Doing so will make your patch incapable of being merged.
If your patch is not ready to be merged, assign -2 to it, that way reviewers know it is Work In Progress.
Patience is a key, reviewing takes time and we are all volunteers, so expect a couple of days to pass.

Suggested workflow

1. Update master

Make sure your master is updated and works. If your master is too outdated, you run the risk of not being able to merge your patch.

As a rule of thumb, use the commands below if:

your master is more than a week old.
your new bug-fix depends on work that just got merged.

./g pull -r
make
make check

!! make must be 3.8.1 or higher.

Please use the -r switch, which is far more effective than simply pulling. Master is frequently broken, but normally only for a short time (committers normally react fast if they make a wrong commit).

When make completes you know you have a working master, so if make breaks while compiling your patch it is due to a problem somewhere in your code. make check runs all test cases and ensures you have a working version of LibreOffice. Running plain make before make check does not cost you build time and in the case of test failures, it ensures you have a build that runs.

2. Work in a branch

You might be asked later to make changes to your patch, and if you have created and worked in a separate branch that will be very easy. Please use a new branch (from origin/master) for every bug you work on, once the patch has been merged you can delete the branch.

git checkout -b test1 origin/master

Replace test1 with your preferred name.

3. Solve the bug

Identify the problem, correct the code, generate and test a version. Remember to supply a unit-test whenever possible to verify that the problem is solved.

There are a number of handy tools to help you

OpenGrok - use it to search and browse the code base
Convert java unit-test to python
cgit commit log
gerrit overview for LibreOffice

Do remember to do git commit -a regularly. This gives you the possibility to easily abandon part of your development, should it turn out to be a wrong path.

4. Submit the patch

It is recommended that your commit messages look like:

   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>

if there is a bugreport related to the commit, it's mandatory to start the first line with a bug reference like tdf#12345 (see details below)
use the rest of the first line as a concise summary of your changes. The maximum length for this line is 72 characters.
use present tense. tell what the change does. be terse. avoid "decorations" like dashes and brackets that waste space.
if you want to provide more text than what fits the 1st line, it's mandatory to leave the 2nd line empty
starting from the 3rd line explain what the patch does and why, and if it not obvious also how. These lines should have 80 characters length at most; split into several lines, if your comment is longer. Here you can also describe how the code used to work incorrectly before the change.

If your patch fixes a bug that is already filed in Bugzilla, then you can take advantage of automatic bug-notifications that are triggered by commit-messages: When the first line of the commit message includes a reference to a bug in the form tdf#12345, then a corresponding comment will automatically be added to the bugreport, when the change is pushed to the repository. See the announcement-thread on mail-archive.com or on fdo-listarchive for more details.

Verify that your changes don't break automated testing:

make check

Now you can submit the patch to gerrit (see Prepare to submit patches):

./logerrit submit master

Review of your patch

In the case of easy hacks, add the person who provided the code pointers as a reviewer for your patch. You will receive an email whenever there is a change in your patch.

In general 3 things can happen in the review:

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”

In the latter two cases, you need to update your patch.

For more on the patch review process, see Development/gerrit/PatchReview.

Updating a patch

Checkout your branch,

git checkout test1

make the needed changes and test them. It is polite to comment the lines of code you do not want to change or where you do not agree with the committer, this is done directly in gerrit.

Once you are ready to commit again it is important you use --amend

git commit --amend -a

Important do not use the -m parameter as it will wipe out the gerrit patch id. Let git open an editor, allowing you to edit the commit message (or leave it unchanged). When editing be careful not to remove/modify the last line with the patch id.

This will ensure you update the patch, instead of generating a new one (with a new Change-Id:).

Upload the new patch set to gerrit

./logerrit submit master

License statement

We want to keep the source code free for use by anybody, therefore it is important that you mail (please use Subject: <your name> license statement) a license statement to libreoffice@lists.freedesktop.org with the text:

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

It is important to make sure that the mail allows connecting the statement to the contributions, so send the statement from the same email that is used in your commits.

A slight variation to suit your personal taste is fine as long as the intention is clear. We keep a list of developers in our wiki.

Please only send the statement no earlier than when you post your first submission to gerrit. If you are underage, ask your parents or legal guardians to send the email (all persons having guardianship).

If you will be contributing artwork that will be included with the software (such as icons), add this to your license statement email:

   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

Congratulations

You have successfully made a change to one of the most popular open-source packages in the world.

Continue to make patches, and you will soon be a committer yourself.

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:

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.
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
Be able to build LibreOffice: To be able to change the code, one should be able to build LibreOffice from the sources.
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.
Do at least 5 EasyHacks with difficulty beginner (C++): The first step towards being able to understand and change the code.
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.
Do at least 1 EasyHacks with difficulty interesting
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
Reach certain number of commits (~60)
Do at least 1 CoreHack

Beginner etiquette

Experienced contributors will help you find solutions to your problems, but there are expectations and limits. Remote mentoring and troubleshooting has a greater cognitive load compared to being physically present. Showing you are well-prepared makes people more motivated to help you.

General guidelines:

When using the chat, immediately describe your problem and stay in the channel for at least an hour.
For sharing text with multiple lines in the chat, use a paste service such as the one mentioned in the channel topic.
If you have network connection issues, the mailing list works better than the chat.
If you are doing a complex multi-step task, it is a good idea to keep personal notes. These will come in handy when you are asked what you did so far.
After receiving a reply, acknowledge it somehow. If you disappear without a trace, your helpers will feel distressed.

If you are facing an issue with git, patch submission or setting up the development environment, it is best to follow these steps:

Try to search for the how-to or solution yourself. Sometimes your helpers have to search as well.
If your search was successful, make an attempt to follow the instructions.
If you did not find any instructions or got stuck applying them, ask for help.

With these types of issues, helpers are quite happy to try and solve your entire problem for you.

If you are solving an easy hack, it is good to keep these facts and tips in mind:

There is no single document explaining the code base in prose. Educational material is scattered across conference presentation slides, blog posts and wiki pages.
The frequency of code comments is less than ideal (you can help!), so you should be prepared to read code.
Use git grep, an IDE and OpenGrok to find the definitions of the functions and classes you run into.

Investigate the commit history, also for similar topics elsewhere in the code base. OpenGrok's Annotate command can be revealing for this type of detective work.
Run a debugger while using LibreOffice to find out what is going on under the hood.
Browse the readme files.

If you ask someone to say how to implement something, you will probably be faced with silence. Easy hacks are supposed to be a learning experience and mentors do not want to ruin it. A proposed implementation will be commented on in the review system.