openEuler社区开源贡献实践笔记

第1章开源与开源社区

自由软件–开源软件的源头

Richard Matthew Stallman,1983年9月推出GNU项目，并发起自由软件运动(free software movement或free/opensource software movement，简称FSM或FOSSM)，推广用户有使用、复制、研究、修改和分发软件等权利。

同时开创了Copyleft的概念，它使用著作权法的原则来保护使用、修改和分发自由软件的权利，并且是描述这些术语的自由软件许可证的主要作者。最为人所称道的是GPL(最广泛使用的自由软件协议)

1985年10月成立自由软件基金会(Free Software Foundation,FSF)，致力于推广自由软件。

开源软件–概念

开放源代码促进会(Open Source Initiative，缩写:OSI)于1998年2月创建，旨在推动开源软件发展，首次正式提出开源软件(open source software)的概念:

一种源代码可以任意获取的计算机软件，这种软件的著作权持有人在软件协议的规定之下保留一部分权利并允许用户学习、修改以及以任何目的向任何人分发该软件。开源协议通常符合开放源代码的定义的要求。

https://opensource.org/

开源软件-License

License是游戏规则，是开源软件许可证。在开源软件代码仓/包中，通常在COPYING,LICENSE, NOTICE，COPYRIGHT，AUTHOR，README说明其采用的开源许可证。

·开源软件使用遵从义务:按照开源软件软件许可证规定开源软件使用者需要覆行的义务·开源使用声明义务:在产品发布时，随产品附上一份文档Open Source Software Note在该文档中写明产品所有使用的开源软件及其版权和许可证信息，并附上免责声明。

·代码对外开源义务:按照开源许可证要求，将一定范围内的代码对外开源，开源范围视具体许可证的要求和使用方式而定。

·修改声明义务:做出对修改的开源软件就修改时间，修改的代码以及修改过的文件做出

具体的声明。

开源软件一License

.Apache License 2.0

. BSD 3-Clause "New" or "Revised" license

· BSD 2-Clause "Simplified" or "FreeBSD" license. GNU General Public License (GPL)

. GNU Library or "Lesser" General Public License (LGPL). MIT license

. Mozilla Public License 2.0

. Common Development and Distribution License. Eclipse Public License version 2.0

. Mulan Permissive Software License v2 (MulanPSL - 2.0)

https://opensource.org/licenses

GPL(Gnu Public License)

GPL许可证的核心含义是，允许任何人观看、修改，并散播程序软件里的原始程序码，条件是如果你要发布修改后的版本就要连源代码一起公布。

GPL V2:

·许可说明

·允许各种链接，但被链接的整个产品需要开源·允许修改，但被修改的部分及整个产品均需要开源

·通过pipes, sockets的命令行参数与GPL软件进行通讯，不会导致私有软件被传染·仅原则性声明专利应免费许可，无详细规定

LGPL V2:

·许可说明

·允许各种链接，动态链接无开源义务，静态链接需要开放与之链接私有软件的.o文件与makefile·允许修改再链接到私有软件，但是个性增加的功能实现不能依赖私有软件的数据功能

·允许不受限制的使用头文件中数值参数，数据结构布局，存取，小宏，内联参数，十行以内的模板·仅原则性声明专利应免费许可，无详细规定

木兰宽松许可证(MulanPSL v2)

https://license.coscl.org.cn/MulanPSL2/index.html

2020年2月14日，“木兰宽松许可证”第2版(MulanPSL v2)经过严格审批，正式通过开源促进会(OSI)认证，被批准为国际类别开源许可证(International licenses)。意味着其正式具有国际通用性，可被任一国际开源基金会或开源社区支持采用，并为任一开源项目提供服务。

与众多开源协议相比，Mulan PSL在其它协议的基础上进行了以下优化:

·许可证内容以中英文双语表述，中英文版本具有同等法律效力，方便更多的开源参与者阅读使用，简化了中国使用者进行法律解释时的复杂度。

明确授予用户永久性、全球性、免费的、非独占的、不可撤销的版权和专利许可，并针对目前专利联盟存在的互诉漏洞问题，明确规定禁止“贡献者”或“关联实体”直接或间接地(通过代理、专利被许可人或受让人)进行专利诉讼或其它维权行动，否则终止专利授权。

·明确不提供对“贡献者”的商品名称、商标、服务标志等的商标许可，保护“贡献者”的切身利益。

·木兰协议经技术专家和法律专家共同修订，在明确合同双方行为约束的前提下尽可能地精简条款、优化表述，降低产生法律纠纷的风险。

开源软件–著名开源软件

1991年芬兰大学生Linus Torvalds在GNU通用公共许可证下发布了最初是为自己创作的Linux操作系统内核，最初这只是他的一项兴趣爱好。随后，这项兴趣爱好便逐步演变成了拥有最大用户群的操作系统。

如今，它不仅是服务器上最常用的操作系统，也广泛应用在嵌入式系统上，如手机、平板电脑、路由器、电视、电子游戏机等。只要遵循GNU通用公共许可证(GPL) ，任何个人和机构都可以自由地使用Linux的所有底层源代码，也可以自由地修改和再发布。

并逐渐发展成为世界上最为活跃的开源基金会Linux Foundation,吸引了来自世界各地的超过500家公司的超过235k开发者参与。

第2章openEuler社区概述

openEuler社区概述

openEuler脱胎于EulerOS，EulerOS是华为公司自2010年起研发使用的服务器操作系统，Linux发行版之一，名字来源于著名数学家莱昂哈德·欧拉(Leonhard Euler);

2019年9月，EulerOS正式开源，命名为openEuler。

2021年9月25日，openEuler全新发布，升级为统一的面向数字基础设施的开源操作系统，通过一套操作系统架构，南向支持多样性设备，北向覆盖全场景应用，横向对接鸿蒙通过能力共享实现生态互通。

2021年11月openEuler正式捐献至开放原子开源基金会

数字基础设施开源操作系统

Information Technology + Communication Technology + operational Technology

操作系统碎片化导致数字基础设施产生大量“软烟囱”︰生态割裂;重复开发;协同繁琐

从服务器，到云、到边缘计算，到CT和OT的嵌入式场景，成为面向数字基础设施统一的开源操作系统

全栈原子化解耦，支持版本灵活构建、服务自由组合，这样通过一套架构，来灵活支持南向多样性设备，北向全场景应用

数字基础设施开源操作系统

商业发行版

1. 商业支持/服务

2. 聚焦稳定和生产价值客户/厂商模式

3. 厂商主导的开发

社区发行版

1. 社区支持/服务

2. 创新版、稳定版兼顾

3. 开发者模式

4. 社区开发者主导的开发

openEuler版本生命周期

社区版本号按照交付年份月份命名。

长期支持版本:发布周期为2年，提供4年社区支持。

社区创新版本:每隔6个月发布一个社区创新版本，提供6个月社区支持。

高性能、高安全、易运维

• 全场景协同：分布式软总线和KubeEdge，支撑构筑全场景协同领先优势

• 服务器：主流多样性算力覆盖全面，生态完善的数字基础设施底座

• 云原生/边缘：打造降本增效、敏捷易用云原生/边缘基础设施体验

• 嵌入式场景：软、硬实时解决方案，满足工控领域多层次时延诉求

• 高性能：内核架构优化、用户态协议栈和内存分级架构，使能最优性能

• 高安全：机密计算框架和国密全栈.软硬协同持续构建自主可控安全优势

• 易运维：A-OPS智能运维. A-tune智能调优效率倍级提升

openEuler开源共建，已经成为国计民生行业首选开源操作系统

社区发行、伙伴发行、商业落地、社区运营

第3章 参与openEuler社区贡献

openEuler社区贡献―加入SIG组

行业解决方案/应用、工具链/语言运行、通用中间组件、架构/处理器/内核驱动、云原生基础设施、基础功能特性工具、桌面/图形系统

SIG是Special lnterest Group的缩写openEuler社区的开发活动按照不同的siG来组织，以便于更好的管理和改善工作流程。SIG组均是开放的，欢迎任何人来参与。

https://www.openeuler.org/zh/sig/sig-list/

openEuler社区贡献-开发者角色

Contributor——项目的贡献者——签署CLA并产生社区贡献

Committer——审核其他成员的贡献——SIG的积极贡献者，经验丰富，愿意投入精力参与到审核工作

Maintainer——项目Owner——经验丰富，富有责任心、出色的技术能力和管理能力

技术委员会(Technical Committee)——负责社区技术决策和技术资源的协调。当期TC委员(含主席）经过扩选，为19人，任期一年。

安全委员会(Security Committee)——接收和响应openEuler产品安全问题报告、提供社区安全指导，开展安全治理等活动提升社区产品的安全性,为openEuler用户提供最安全的产品和开发环境。

Release Management——社区协调各SIG的Maintainer、QA等各个团队，完成openEuler社区版本的发布工作。

openEuler社区贡献–签署CLA

CLA (Contribution License Agreement)为贡献许可协议。

开源社区一般都会要求贡献者签署CLA，只有签署了CLA的贡献者提供的内容才能被接受。

CLA签署后贡献者提供的贡献（包括捐款、源代码)将授权给社区使用。

openEuler社区贡献-提交你的第一个PR(Pull Request)

1．贡献者从社区官方代码库中fork—份代码到自己的库;

2．将自己社区库中的代码clone到本地开发环境上;

3.修改代码，解决bug或开发新feature;

4.提交修改;

5.将本地提交push到自己的社区库中;

6.向社区官方代码库提交PR;

7．待Maintainer review后合入社区官方代码库。

openEuler社区贡献-Git基础

Git是一个开源的分布式版本控制系统，用于敏捷高效地处理任何或小或大的项目。

是Linus Torvalds为了帮助管理Linux内核开发而开发的一个开放源码的版本控制软件。https://git-scm.com/

Git使用教程:

https://moocstudio.openeuler.org/#/home

https://www.openeuler.org/zh/community/contribution/

第4章 openEuler软件包开发

如何构建一个Linux发行版?

应用软件开发、软件构建系统、软件管理&软件仓库、发布计划

Linux软件管理–源码编译

Tarball文件:将软件的所有源码文件以tar打包，然后再压缩（通常是gzip)，所以tarball文件一般的扩展名为*.tar.gz或是简写为*tgz。不过，近来由于bzip2与xz的压缩率较佳，因此它对应的后缀名为*.tar.bz2 .*.tar.xz。

所以，tarball是一个软件包，将它解压之后，里面的文件通常会有:·源代码文件

·检测程序(可能是configure或config)

·本软件的简易说明与安装说明(INSTALL或 README)

·其中最重要的是 INSTALL或 README文件，通常只要能参考这两个文件,Tarball 软件的安装是很简单的

Linux软件管理-RPM/YUM/DNF

虽然使用源码进行软件编译可以具有定制化的设置，但是对于Linux distribution 的发布商来说，则有软件管理不易的问题，毕竟不是每个人都会进行源码编译

如果能预先在相同的硬件与操作系统上编译好才发布的话，就可以让相同的distribution具有完全一致的软件版本了，再加上简易的安装、移除、管理等机制的话，对于软件管理就容易多了。

RPM 与 YUM/DNF就是实现这样的目标

Linux软件管理-RPM Basics

Fedora,CentOs, openSUSEOracle Linux, openEuler, etc.

·简单易用

·以软件包为中心:RPM以软件包为单位进行操作，而不是操作单个文件。

·软件包的可升级性:—旦软件包使用rpm安装后，可以使用rpm对该软件包进行升级。

·解析软件包依赖:RPM软件包中保存了所有该软件包需要的依赖。

·查询功能: RPM软件管理器可以用来查询所有本机已通过RPM进行安装的软件包。

·验证:RPM可以对RPM软件包进行验证，确保软件包可信

name-version-release.architecture.rpm

kernel-smp-2.6.32.9-3.x86_64.rpm

rootfiles-7.2-1.noarch.rpm

$rpmdev-setuptree

$tree ~/rpmbuild// home/user/rpmbuild/

l – BUILD ：RPM软件Build过程中的工作目录，在定位问题时十分重要

l – RPMS ：生成的二进制RPM软件包的输出目录，会自动创建软件包架构所在的子目录:x86_64、aarch64、noarch等.

l—SOURCES：存放用于制作RPM软件包的所有源文件，包括项目源代码、Patch等。Rpmbuild工具会根据Spec指示在本目录下进行检索。

l—SPECS：用于存放Specs的目录

|-- SRPMS：如果指定生成source rpm，则在此处保存

Name pkg的名称，需要与Spec文件名一致

Version 软件源代码的版本

Release 这个软件包被制作成rpm的次数，从1开始递增

Summary 软件包的简要描述

License 软件所使用的(开源)协议

URL 软件的项目网站，方便用户获得更多内容

SourceO~xx 项目源代码压缩包的存储路径耽RL，可以依次指定多个Source，如source0,lsource1, source2 .

PatchO~xx 构建过程中需要用到的patch文件，可依次指定多个patch，如patch1, patch2,lpatch3 ...

BuildArch 构建架构:x86_64,aarch64, power64等，若采用跨平台语言(e.g.纯python)则可以指定noarch

BuildRequires 软件构建过程中所需要的依赖

Requires 软件运行过程中所需要的依赖

ExcludeArch 软件不能运行的平台

%description

软件包的简要描述

%prep

执行软件build之前的准备工作，如解压Source文件，打patch等操作

%build

Build软件包的执行步骤

%install

安装软件包的执行步骤

%check

检查步骤，主要用于测试

%files

软件包所产生的文件列表

%changelog

Spec的修改记录

基本格式: rpmbuild [options] [spec文档|tarball包(或者压缩包—以.gz或.xz或.bz2结尾的)|源码包]

options有下面的几种选择:

1.-bp :只执行spec的%pre段(解开源码包并打补丁,即只做准备)

2.-bc :执行spec的%pre和%build 段(准备并编译)

3.-bi∶执行spec中%pre,%build与%install(准备,编译并安装)

4.-bl∶检查spec中的%file段(查看文件是否齐全)

5.-ba :建立源码与二进制包(常用):即编译后做成*.rpm和*.src.rpm

6.-bb :只建立二进制包(常用):即编译后做成*.rpm

7.-bs :只建立源码包:即只做成*.src.rpm