Become a Contributor in 30 minutes | How to participate in OpenHarmony's open source contributions in multiple ways?

How to gracefully participate in open source contributions and submit PRs (Pull Requests) to top-level open source projects. The eighth phase of the "Code" Pioneer Live Room focused on the topic of "OpenAtom OpenHarmony (hereinafter referred to as "OpenHarmony") open source contribution", and invited a senior OS framework development engineer from Shenzhen Kaihong Digital Industry Development Co., Ltd. (hereinafter referred to as "Shen Kaihong"). Ba Yanxing brings you the theme of "How to Participate in Open Harmony Open Source Contribution in Multiple Ways".
This sharing mainly introduces Ba Yanxing's experience in leading/co-building 16 SIGs and contributing more than 500,000 lines of code to OpenHarmony's "battle code" experience under the leadership of the Shenzhen Kaihong open source co-construction team. Participate in the practice and thinking of open source contribution in multiple directions, as well as the contribution methods, values and uses of the two major sections of the auxiliary tools SIG and the kernel SIG, and hope that more developers will participate in open source co-construction.
Participate in the battle "code" pioneer, PR solicitation order! Interested developers can submit PRs in Gitee's OpenHarmony code warehouse to participate in activities, compete with global developers, compete skills, and contribute to OpenHarmony's ecological construction.

How to make open source contributions through the SIG

What is a SIG?
The full name of SIG is Special Interest Group, which is a special interest group. It focuses on a specific technical field and is responsible for technical competitiveness analysis and key technology identification and decision-making in this field, leading the direction of technology evolution. basic unit.
Two ways to participate in open source co-construction through SIG groups
1. Participate in the co-construction of an existing SIG <br>Participants need to register their official accounts and sign an agreement before they can undertake the co-construction task by claiming the requirements published by the SIG leader. After receiving the requirements, it is a standard development process, including requirements analysis, functional design, code development, functional testing, and functional delivery. contribute.
2. Leading the SIG group
1. Establish SIG
Select the co-construction technology field and give a plan → submit the topic to the PMC regular meeting and pass the review → establish a new code warehouse after passing the evaluation of the structure SIG regular meeting.
2. Incubation SIG
Start the process of requirement clarification, feature sorting scheme design, code development, unit testing, functional testing, etc., complete the SIG project development → comparison Check List, and complete the self-inspection of legal affairs, access control, OAT and other issues.
3. Graduation SIG
Apply to the Architecture SIG for a new SIG graduation → apply to the QA SIG for a new SIG approval → the warehouse owner moves the warehouse.

Auxiliary Tools SIG Practical Experience Sharing

The purpose of establishing the Auxiliary Tools SIG group is to "reduce duplication of work, improve work efficiency, and let professional people do professional things". NAPI framework code generation tools, IDL conversion tools and boot animation tools are developed around this purpose.
1. NAPI framework code generation tool
NAPI is the implementation of JS API on standard devices, which implements the call from JS language to the C++ layer of the framework. In the OpenHarmony system, the APP call is to call the interface function of the JS language, and the final specific function is implemented in the C++ language.
NAPI has three development pain points that need to be solved:
1. The repetition rate of NAPI framework code is high: In the face of different JS interfaces, developers need to implement framework codes with high similarity.
2. The learning cost of the NAPI framework is high: the framework mechanism involves JavaScript, C++ language, and compilation script tools.
3. Large demand for NAPI: The functions of the OpenHarmony system are all reflected through the NAPI interface, and currently supports more than 10,000 NAPI interfaces.
In response to the above three pain points, the NAPI framework code generation tool extracts common modules from code such as C++ and JavaScript interface type conversion, and automatically generates compilation scripts. Developers use tools to automatically generate NAPI framework code, and only need to implement business code calls, avoiding a lot of repetitive work.

2. IDL conversion tool
OpenHarmony uses the HDF driver framework, and the corresponding hardware information of the driver needs to be described by an IDL file.
There are two major development pain points in IDL that need to be solved:
1. HDI development is difficult: HDI developers are familiar with the C language and are used to defining HDI interfaces in .h files, but they are not very familiar with the structure and syntax of IDL files, and the learning curve is relatively long.
2. The HDI workload is large: the HDI interface is a necessary condition for the driver to provide external services, and each subsystem is involved, so the HDI workload is large.
In response to the above pain points, the IDL conversion tool designed by Shenzhen Kaihong automatically converts the .h file familiar to the developer into an idl file. The developer only needs to define his own interface in the header file, and the tool automatically implements the .h header file to IDL. For file conversion, developers do not need to care about the IDL syntax, which greatly reduces the workload.

3. Boot animation tool <br>Boot animation tool is an auxiliary tool that we made for the problems of OpenHarmony 2.0 in the early days.
The OpenHarmony 2.0 version has two problems with the boot animation:
1. The boot animation of OpenHarmony 2.0 only supports raw files, which is not conducive to developers' direct display in the release version and customized version.
2. Because of the different forms of products, for different products, the requirements for the boot animation are also different.
The above two problems are better solved by the boot animation assistant tool:
1. The boot animation tool supports image collection or mp4 and other files to generate boot animation, and supports operations such as setting the resolution of the boot animation, which is more convenient for the production of boot animation.
2. It can generate a boot animation file with one key, and support viewing its effect on the windows platform, without needing to burn it to the development board every time, which greatly reduces the workload of the demonstration.

4. Co-construction direction of auxiliary tools SIG <br>Currently, the auxiliary tools SIG group led by Shenzhen Kaihong mainly provides developers with three co-construction directions: documentation, test cases and tool development.
If you are good at document writing, you can participate in the document contribution of the community, and writing documents does not require strong development capabilities.
If you are a tester and are good at automated testing, you can also participate in community building through test cases.
In addition, developers are welcome to participate in the construction of various tools. The tools of the SIG group can be independent tools, or can be integrated into IDE development software by means of plug-ins.

V. Specific Ways to Participate in the Contribution of Auxiliary Tools SIG
1. Submit the question sheet. Whether it is a bug in the documentation, a bug in a test case, or a bug in the code, submitting a ticket is a contribution to the community, so how does the Auxiliary Tools SIG group submit a ticket?
First find the corresponding repository and log in, for example https://gitee.com/openharmony/napi_generator/issues .
During the submission process, pay attention to the format requirements. You must clearly write down the conditions of the problem during the bill of lading process, the expected and wrong results, and the location information of the problem. With this information, the development of receiving this problem list is also convenient for locating the problem.

Log in to the page where you can find the questions you want to claim, and express your willingness to take up this demand in the comments. The person in charge of the SIG will regularly track these questions and respond.

2. Carry out the development process after claiming a requirement. After receiving a requirement, normal development must be carried out. The core is divided into the following 6 steps:
①Usually, the developer has already configured the configuration code cloud account, personal mailbox and signed DCO (signing the DCO is mainly to ensure the originality of the contributor). After these pre-work, we can operate the code warehouse to develop the requirements.
②Fork code to private warehouse.
③ Clone the fork out of the warehouse to your own host.
④ Develop code development and functional verification locally.
⑤ After the development is completed, submit a Pull Request to the official original warehouse. After submitting the code, regular inspections such as access control will be triggered.
⑥If the sig group is led by yourself, then as a Committer, you need to review the code submitted by others. If you only participate in the co-construction, you will complete the task after submitting the code and passing the access control.

Kernel SIG participation in co-construction experience

Regarding the experience in the co-construction of Shenzhen Kaihong Kernel SIG, the following will take the optimization of the file system as an example to share the specific contribution process with you.
There are many directions of kernel co-construction. The architecture includes the transplantation of various hardware platforms, and the kernel shell commands related to power management, time management, task scheduling, interrupt management, file system, and tripartite libraries in the kernel module are transplanted. Do community co-construction on file systems and third-party libraries. Shenzhen Kaihong hopes to carry out more optimization work in the future, and provide external kernel system transplantation solutions in specific scenarios.

The co-construction process of the littlefs file system:
1. Understand the needs of the community. The community is currently not satisfied with the random read and write speed of the littlefs file system.
2. Under the premise of understanding the community file system's requirements for random read and write, analyze the performance bottleneck of littlefs random read and write IO, find code points that can be optimized, and adopt the idea of "exchanging space for time".
3. Adopt the idea of gradual optimization, communicate with the community leader after clarifying the plan, and start specific code work after being approved by the community leader.

Since file system optimization is a relatively complex process, a set of community co-construction processes are shared below.
1. After claiming the demand from the community, communicate with the community leader through WeChat group and clarify the demand.
2. Technically analyze the requirements and formulate an optimization plan, communicate with the community leader again, discuss the plan and get approval.
3. Specific task development, including task disassembly, coding implementation, testing, and finally submitting PR.

For the related files involved in the modification of the littlefs file system optimization process, including the littlefs file code, that is, the point c and point h files; there are also compilation-related files, that is, the .gn file gni file. The reason for modifying the compilation-related files is to To test the optimized code of littlefs, our team has added relevant test cases, which will call the API of the kernel file system and involve these compilation-related files.

The process of submitting the littlefs third-party library code to the community after completion
1. Littlefs third-party library repository path, and fork to the user repository.
2. git clone the user warehouse to the local.
3. Submit the changes to the user repository.
4. Click Submit PR.
5. Fill in the PR form. The PR form needs to be filled in according to the established template, and clearly write the original requirements, how to solve this problem, how to solve this problem and the specific modification points.
6. Add "start build" in the comments to light up the PR. There is a special point to pay attention to here. You need to manually fill in the two English words "start build" in the comments, in order to trigger the subsequent access control detection. This is a special point of the OpenHarmony community, which is not found in other open source projects.



Interested developers are welcome to participate in OpenHarmony's open source contributions in various ways and become OpenHarmony Contributors. You are also welcome to put forward your valuable opinions and contribute to OpenHarmony.
Participate in the battle "code" pioneer, PR solicitation order! Submit PR in Gitee's OpenHarmony code warehouse to participate in activities, and build a prosperous OpenHarmony ecosystem with developers around the world!

A summary of the links involved in the article:

NAPI framework code generation tool code warehouse address:
https://gitee.com/openharmony/napi_generator
IDL conversion tool code warehouse address:
https://gitee.com/openharmony/drivers_hdf_core/tree/master/framework/tools/idl-gen
Boot animation tool code warehouse address:
https://gitee.com/openharmony/graphic_graphic_2d/tree/master/frameworks/bootanimation/data/bootanimation_tool

Forward the original text to the circle of friends, private message the official assistant, you can get the lecturer's PPT
Original link: https://mp.weixin.qq.com/s/exyXFfZfPs0XBpwUzPjrKw