p62978453
/
docs
forked from openkylin/docs
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

删除文件 en/Community-Developer-Guides/ OpenKylin-source-code.md

This commit is contained in:
jlspcdd1227dd 2023-03-22 06:54:33 +00:00 committed by Gitee
parent 2eee1d091d
commit 5f2b795363
No known key found for this signature in database
GPG Key ID: 173E9B9CA92EEF8F
1 changed files with 0 additions and 828 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

828
en/Community-Developer-Guides/ OpenKylin-source-code.md
View File

@ -1,828 +0,0 @@
# OpenKylin source code independent selection and construction process
# 1. Selection of software package version number
## 1. Selection strategy
### 1.1 Software project selection strategy
![输入图片说明](media/rId21.png){width="5.833333333333333in"
height="2.7753904199475063in"}- Continued active introduction of full
\"A\" software (versions)
- Encourage the introduction of only \"A\" and \"B\" software
(version)tory-view-113483.html
- Cautiously introduce \"C\" software (version)
- Refuse to introduce/delete software (version) containing \"D\" or
\"C \>= 3\" in time
### 1.2 Software version selection strategy
- Long-term support version (temporarily openKylin has not yet
determined a long-term support version, 1.0 is currently not a
long-term support version)
- Taking into account both quality and stability, give priority to
the widely used version of the mainstream OS.
- Compatibility lists are not affected after the upgrade.
- During the life cycle of the same version, no major version
changes are made, and only features and patch rounds are used to
solve quality problems.
- Community-developed version
- To meet the basic compliance issues, integrate as much software
as possible, and give priority to the latest version of the
current stable branch of the open source component.
- Follow up the dynamics of the upstream community in a timely
manner, and merge new feature versions of open source software.
### 1.3 Software classification and compatibility principles
-----------------------------------------------------------------------------
**level** **scope** **in principle**
----------- ------------------------- ---------------------------------------
level one kernel, glibc, gcc, zlib API and ABI are stable for the lifetime
and other system core of a major version, and try to be
components stable for the next major version
Secondary Basic software such as The API and ABI remain stable during
dbus, oepnssl, bzip2, the life cycle of a single major
systemd, etc. version, and dependent applications do
not require major modifications in
principle during the life cycle of a
single major version
Level three other application API and ABI are not forced to remain
software etc. stable during the life cycle of a
single major version, and applications
with dependencies are kept linked to
upgrade
-----------------------------------------------------------------------------
## 2. Specific process
1. Select new projects to be introduced according to the \"software
project selection strategy\"
2. According to the \"software version selection strategy\", select a
version that needs to be introduced in the project
3. Output the \"project selection report\", including the compliance,
compatibility, importance, activity, quality, and security details
of the new project, as well as the new features, compatibility,
impact domain, and versions in other releases of the selected
version Situation comparison etc.;
4. After the approval of the technical committee, the specific work
will be carried out according to the following procedures
### 2.1 Get the project address of the software package
Obtaining the project address is used to view the current project
details, development status, compilation and installation, usage
instructions and other related content of the software package
You can get the project address of the software package in the following
ways:
#### 2.1.1 The package tracking platform of the debian community
Basically most of the packages can be found on the debian community\'s
package tracking platform (
[tracker.debian.org](https://tracker.debian.org/) )
Example: Find `libnftnl `package
![输入图片说明](media/rId29.png){width="5.833333333333333in"
height="5.719400699912511in"}
Enter a picture description
As shown above, you can get the project address of the software package
through the homepage information in the upper right corner;
#### 2.1.2 dsc file
view the dsc file of the software package on platforms such as the
debian community ( [tracker.debian.org ) and ubuntu
(https://launchpad.net). The dsc file may contain project address
information describing the current software
package.](https://tracker.debian.org/)
For example: `libnftnl `Check the package [dsc file in the debian
community](https://deb.debian.org/debian/pool/main/libn/libnftnl) (the
following uses [version
1.1.2-2](https://deb.debian.org/debian/pool/main/libn/libnftnl/libnftnl_1.1.2-2.dsc)
as an example):
# Remove gpg signature information for easy viewing
Format: 3.0 ( quilt )
Source: libnftnl
Binary: libnftnl11, libnftnl-dev
Architecture: linux-any
Version: 1.1.2-2
Maintainer: Debian Netfilter Packaging Team < pkg-netfilter-team@lists .alioth.debian.org >
Uploaders: Arturo Borrero Gonzalez < arturo@debian.org >
Homepage: https://git.netfilter.org/libnftnl
Standards-Version: 4.2.1
Vcs-Browser: https://salsa.debian .org/pkg-netfilter-team/pkg-libnftnl
Vcs-Git: https://salsa.debian.org/pkg-netfilter-team/pkg-libnftnl
Build-Depends: debhelper ( > = 11 ) , libmnl-dev, libtool, pkg-config
Package-List:
libnftnl-dev deb libdevel optional arch=linux-any
libnftnl11 deb libs optional arch=linux-any
Checksums-Sha1:
c0f880588fabaa845a88fb5a2bdad0dea7481857 366014 libnftnl_1.1.2.orig.tar.bz2
0a9063e79191955fbf59482d75c7bfb62aded816 912 libnftnl_1.1.2.orig.tar.bz2.asc
505f8b44e3adb574dc3cf657580e9d73f0b0a853 8772 libnftnl_1.1.2-2.debian.tar.xz
Checksums-Sha256:
a5c7b7a6c13c9c5898b13fcb1126fefce2015d5a96d7c354b19aaa40b6aece5d 366014 libnftnl_1.1.2.orig.tar.bz2
4178552d7ad210e9f17df3c079ac6de032f62c72774d59bfac404a023d48950b 912 libnftnl_1.1.2.orig.tar.bz2.asc
4ef80a0c344b23624d24b7dd4be1b73a7b96d86089813c545705f8093067ce13 8772 libnftnl_1.1.2-2.debian.tar.xz
Files:
14093a238d5025d4a452e6d1cef88c58 366014 libnftnl_1.1.2.orig.tar.bz2
e10dcb9138261d92e7569bd72b809a28 912 libnftnl_1.1.2.orig.tar.bz2.asc
518ff0360f67c8031a31792a257a5c3b 8772 libnftnl_1.1.2-2.debian.tar.xz
As highlighted:
- **Homepage** : project address
- **Vcs-Browser** : version control system browsing platform (similar
to github, gitee, gitlab and other platforms)
- **Vcs-Git** : git warehouse address
#### 2.1.3 debian/control file
First, download any source package from the debian community and ubuntu
community (launchpad.net) and decompress it.
#Download the source code package from the ubuntu community (launchpad.net) platform
# You can also use apt-source to download the source code by adding the deb-src source
# To use dget, you need to install devscripts
dget -x https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/libnftnl/1.2.3-1/libnftnl_1.2.3-1.dsc
# Enter the decompression directory
cd libnftnl-1.2.3
Check `the debian/control `file to find out whether there are related
fields such as `Homepage `, `Vcs-Git `, `Vcs-Browser , etc.`
like:
$ grep -E "^(Homepage|Vcs-*)" debian/control
Homepage: https://git.netfilter.org/libnftnl
Vcs-Git: https://salsa.debian.org/pkg-netfilter-team/pkg-libnftnl. git
Vcs-Browser: https://salsa.debian.org/pkg-netfilter-team/pkg-libnftnl
The descriptions of the fields highlighted above are consistent with
those in Section 2.1.2
#### 2.1.4 debian/watch file
As in Section 2.1.3, you need to download the source code first. This
time I checked `the debian/watch `file
**The debian/watch** file is mainly used to record the download address
of the upstream source code (this file is not necessary, so it may not
exist in some source code packages)
$ cat debian/watch
version = 3
opts = pgpsigurlmangle=s/$/.sig/ http://ftp.netfilter.org/pub/libnftnl/libnftnl- ( \S+ ) .tar.bz2
Through the upstream source code download address recorded in this file,
you can find the corresponding project address
like:
# Its download address is generally ftp or git release download address
# If its download address is hosted by another platform, it may not be possible to know its project address
http://ftp.netfilter.org/pub/libnftnl
# Guess from the above address A possible project address is
http://netfilter.org/pub/libnftnl
### 2.2 Get the version of the software package
Get a list of the latest stable versions of the current project by
viewing the project address.
It can be viewed in the following ways:
- debian/watch file
In section 2.1.4, if the software package has a debian/watch file, you
can check the download address of the upstream software package
compressed package of the project.
! There may be a beta version in its download address, and its name is similar to xxxx-beta.tar.gz. Generally, the source code of this kind of beta version should not be selected.
- git repository
If it is a git warehouse, you can check whether its corresponding git
release has been released:
1. If so, you can get its version list on the git release page
2. If not, check whether the corresponding `branch (branch) `and
`tag (tag) `have relevant version list information
# 2. Build the source code package
Select the version of the software package to be built and the download
address from the first chapter.
If there is an existing project in the remote warehouse and the upstream
version needs to be changed, please refer to Section 4.
## 1. Download the source code and modify the format of the source code directory
Download the source package to local and unzip it
# Download source code
wget https://www.netfilter.org/pub/libnftnl/libnftnl-1.2.3.tar.bz2
# Unzip
tar -xaf libnftnl-1.2.3.tar.bz2
Modify the source directory to conform to the **-** format. like:
$ ls -al
drwxr -x ---@ - luzp 10 Aug 02:24 libnftnl-1.2.3.rw-rw----@395k
luzp 10 Aug 02:24 libnftnl-1.2.3.tar.bz2
## 2. Build the debian packaging directory
### 2.1 The upstream source code contains the debian directory
! Note: If the upstream source code directory contains the debian directory, we need to manually rename the upstream debian directory to avoid other problems when we regenerate the debian directory
- Backup the original debian directory
```{=html}
<!-- -->
```
mv debian debian-orig
- Rebuild the debian directory
```{=html}
<!-- -->
```
debmake -u < upstream version number > -r < revision number > -t
At this time, a new directory will be created in the same level
directory of the source code, and its format is -
if:
The source code package is `amdgcn-tools-13.tar.gz`
# Decompression source code
# The source code directory after decompression is amdgcn-tools-13
tar -xaf amdgcn-tools-13.tar.gz
# Enter the source directory, and back up the original debian directory
cd amdgcn-tools-13
mv debian debian-orig
# Rebuild the debian directory
debmake -u13 -rok1 -t
# After the execution is completed, a new directory will be generated in the amdgcn-tools-13 same-level directory
# <original source directory>-<upstream version number>, which is the following directory
ls amdgcn-tools-13-13
### 2.2 Build the debian directory directly
If the upstream source code is pure source code, then just build the
debian directory directly.
# Build the debian directory
debmake -z tar.bz2
- -z specifies the compressed package format of the source code
- libnftnl-1.2.3.tar.bz2 is specified as -z tar.bz2
- The default source compression format is tar.gz
- -b If it is a perl or python source package, you can specify this
parameter to create more files for debmake corresponding to the
corresponding programming language
```{=html}
<!-- -->
```
# If it is python
debmake -b ":python3"
# perl
debmake -b ":perl"
- -t Regenerate the upstream source package (ie xxx.orig.tar.gz)
More detailed usage of debmake can be found in its man manual
man debmake
## 3. Modify the build rules
Mainly modify the files in the debian directory.
### 3.1 control
`The control `file involves two parts:
#### 3.1.1 Source package part
Describe the brief information of the current source package, and the
compilation dependencies for building the source package, etc.
There are several fields to note:
- **Section**
Describes the type of package and is used for categorization of
packages. For example, `mysql-8 `should belong to `database`
The optional contents are:
admin, cli-mono, comm, database, debug, devel, doc, editors, education,
electronics, embedded, fonts, games, gnome, gnu-r, gnustep, graphics,
hamradio, haskell, httpd, interpreters, introspection, java, javascript,
kde, kernel, libdevel, libs, lisp, localization, mail, math,
metapackages, misc, net, news, ocaml, oldlibs, otherosfs, perl, php,
python, ruby, rust, science, shells, sound, tasks, tex, text, utils,
vcs, video, web, x11, xfce, zope
- **priority**
- Priority of packages
- required Packages required by the system
- important Important software packages, non-essential packages
for the system, but hopefully pre-installed in the system
- standard Standard relatively independent software package
- optional This is the default priority option and should be used
unless the package is required by the system
- **Maintainer**
It needs to be written as the current openkylin responsible for the sig
group of the software package, such as `the packaging sig `group written
as `Openkylin Developers <packaging@lists.openkylin.top>`
- **Vcs-Browser** :
Write it as the corresponding gitee warehouse address, such as
https://gitee.com/openkylin/autoconf
- **Vcs-Git**
Write it as the corresponding gitee warehouse git address, such as
https://gitee.com/openkylin/autoconf.git
- **Build-Depends and**
Compilation dependencies required to compile architecture-dependent code
- **Build-Depends-Indep**
Compilation dependencies required to compile architecture-independent
code
For **Build-Depends** and **Build-Depends-Indep,** you can find whether
there are related compilation dependency instructions from the project
address.
**Note:** If the control file refers to the rules of other OS releases,
you need to remove or replace the version number rules in other OS
versions, for example:
Build-Depends:
pkg1 (>= 1.0.0-0ubuntu1),
pkg1 (< 1.2.0-1debian2),
pkg2 (> 1.0.0.build),
pkg3 (> 2.0ubuntu19)
First of all, it needs to be clear that the version number in quilt
format generally has \"-\", the format is
`<upstream_version>-<revision> `, and the source package in native
format generally does not contain \"-\"
The modification process can be carried out in two steps
**first step:**
For versions in quilt format, the version numbers 1.0.0-0ubuntu1 and
1.2.0-1debian2 in pkg1 contain version numbers for specific OS
distributions, so modify them. It also becomes:
pkg1 (>= 1.0.0),
pkg1 (< 1.2.0),
For the version number in native format, you first need to determine its
upstream version, for pkg2 and pkg3:
\(1\) Try to find the 1.0.0 version of pkg2. If you can find it, then
1.0.0 is the upstream version, and its compilation dependency is changed
to: pkg2 (\> 1.0.0); similarly to pkg3
\(2\) If the upstream version of pkg2 cannot be found, and the current
version number does not contain other OS distribution names, then it can
be kept (because the source code is repackaged with the source-package
tool, the upstream version number is also the current version number);
But for pkg3, if pkg3 is self-developed by the OS (its source code name
generally also includes the OS name, such as ubuntu-keyring), then this
package can be renamed at this time, re-maintained by openkylin, and the
corresponding source code name is changed to openkylin-keyring , the
version number is also reformulated, for example, it can be formulated
as 1:1.0.0; if it is not an OS self-developed package, it is best that
we also reformulate the version number, maintain it according to our own
version number, and discuss it internally, for example, specify here is
1:1.0.0. **Note here, it is best to use the version number in the :
format, which indicates that the version number with: will always be
higher than the version number without it.**
Then, for pkg2, pkg3, its modification is:
pkg2 (> 1.0.0.build),
pkg3 (> 1:1.0.0)
**The second step (native format does not need to be processed):**
The second step is to improve on the basis of the first step. In
general, we need to clarify the content of the revision after the - dash
in other OS distributions.
For -, generally speaking, each revision fixes a certain bug, security
vulnerability, etc. For ubuntu, each revision consists of several
patches.
Therefore, for pkg1 (\>= 1.0.0-0ubuntu1), it is clearly stipulated that
it can only be used after the 0ubuntu1 revision, which means that there
is a risk in using pkg1 version 1.0.0. The most direct phenomenon is
that the compilation fails.
Therefore, this needs to be combined with our actual pkg1 version:
\(1\) If pkg1 exists in the warehouse, its version is 1.0.0-ok1. In
order to ensure that the above compilation can pass, the patch in ubuntu
1.0.0-0ubuntu1 needs to be integrated. If the relevant patch has been
integrated, then the compilation dependency becomes:
pkg1 (>= 1.0.0-ok1),
pkg1 (< 1.2.0),
After the patch is integrated, the pkg1 version in the warehouse becomes
1.0.0-ok2. Then where the compile dependency becomes:
pkg1 (>= 1.0.0-ok2),
pkg1 (< 1.2.0),
\(2\) If pkg1 does not exist in the warehouse, then when we choose and
build independently for the first time, it is best to choose a version
between 1.0.0\~1.2.0 to ensure that the compilation dependencies of each
dependent package can be satisfied.
The above are all processed based on compilation dependencies.
Similarly, if the version number is also specified in the installation
dependency field of the binary package, the processing method is the
same as above.
#### 3.1.2 Binary package part
Describes which binary packages the current source package can be
divided into.
Common types of subcontracting are:
- lib
Shared library, its binary package name is generally `lib-xxx`
- dev
Shared library header files and related development files, the binary
package name is generally `lib-xxx-dev`
- doc
Documentation for the package
If its document corresponds to the document of an executable program,
its binary package name is generally `xxx-doc`
If its document is a document of a development library, its binary
package name is generally `lib-xxx-doc`
- bin
Binary programs of software packages, such as binary programs of
compiled languages (such as c/c++) and executable programs of
interpreted programming languages (such as python and perl), the binary
package name is generally the name of the corresponding binary program
This subpackage can be used together with `debmake `when building the
`debian `packaging directory, such as:
# The package name is foo, which provides binary programs and binary program documentation
debmake -b "foo:bin,foo-doc:doc"
# The name of the package is libfoo, which is a development library source code, which provides the development library and development library documentation
debmake -b "libfoo:lib,libfoo-doc:doc"
# After execution, each binary package information template will be automatically written into the debian/control file
### 3.2 rules
Compilation and build rules for packages
### 3.3 changelog
Modify the version number of the software package in the format:-
Generally speaking, for the openkylin community, use `ok1 `as the first
revisions, such as:
autoconf ( 2.71-ok1 ) yangtze ; urgency = low
* Build for openKylin.
-- Lu zhiping < luzhiping@kylinos.cn > Fri, 26 Aug 2022 15:25:09 +0800
### 3.4 source/format
The format of the source package must be set to `quilt `format
echo "3.0 (quilt)" > debian/source/format
echo "3.0 (quilt)" > debian/source/format
### 3.5 Other documents
xxx.install
xxx.doc
xxx.symbols
xxx.manpages
### 3.6 Apply patches for other OS distributions
If other OS distributions have patches for this package, then we need to
analyze and consider whether to apply their patches.
You can first consider whether to apply patches of other OS releases
from the following aspects:
- What does the patch fix? Is the reason why the patch is not absorbed
by the upstream community, is it an irrelevant patch?
- Is it a patch only available in the old version, has the new version
been integrated?
- Is it a major bug fix?
- Is the patch required only for a specific OS distribution?
- If the patch is not applied, is there any compilation problem, and
is there any problem with the installation?
```{=html}
<!-- -->
```
Moreover, it is best to apply the patches of the upstream community after building the git repository, so that the information of the upstream community patches can be retained in the git commit
The following are the steps to apply patch after building the git
repository in Chapter 5:
If you need to apply patches from the upstream community, it is best to
keep the content and author information of their patch information. You
can directly apply the patch of the upstream community through the git
tool:
- git am apply patch
The git am application patch will automatically retain the patch
information
git am xxxx.patch
- git apply apply patch
However, the information format of some patches is not fully applicable
to git am, then you can use git apply to import the patch, and then
commit to add patch information
# Import patch information
git apply xxx.patch
# Add changes
git add .
# Fill in the relevant information of the patch in the edit box, such as
# the author of the patch, the content of the patch, etc.
git commit
After importing the patch, if you want to compile and test the content
of the newly imported patch, you can use the gbp tool to generate a new
source code (new dsc file)
# Modify the changelog to add a new version number
vim debian/changelog
# Compile the source code and generate a new dsc file
gbp buildpackage -S -sa -nc --git-prisine-tar --git-ignore-branch
## 4. Import upstream source code
If there is an existing project in the remote warehouse, the upstream
version needs to be changed.
\(1\) Download the source code package from the upstream community
\(2\) Recompress the source code package to conform to
`the <package-name>_<pacakge-version>.orig.tar.[gz|xz|bz2] `format
#For example:
# The source code compression package obtained from the upstream source code community is requests-2.27.1.tar.gz
# First decompress the source code
tar -xaf requests-2.27.1.tar.gz
# Modify the source directory to <package-name>-<package-version>
# If the directory decompressed from the source compression package of the upstream community is requests
mv requests requests-2.27.1
# Recompress to conform to <package-name>_<pacakge-version>.orig.tar.[gz|xz|bz2]
tar -czf requests-2.27.1 requests-2.27.1.orig.tar.gz
\(3\) Clone the source code of the gitee remote warehouse to the local,
and enter the source code directory
# Clone the remote warehouse
git clone git@gitee.com:openkylin/requests.git
# Enter the source directory
cd requests
\(4\) Change the upstream source code
Refer to Chapter 6 \"Update the upstream version\" of [the git workflow
of the openKylin source package](openKylin源码包git工作流.md)
- a. Import the upstream upstream version (compressed package
generated in the second step)
- - `Bash gbp import-orig requests-2.27.1.orig.tar.gz --no-merge --pristine-tar --upstream-branch=upstream git checkout upstream git push git push --tags`
- b. Filter old version patches (combined with [openKylin source
package git workflow](openKylin源码包git工作流.md) section
6.3.3)
- - If the patch is a developed patch, you need to confirm with the
relevant research and development whether the patch is still
needed in the new upstream source code
- If the patch is a patch of another OS distribution, then it
needs to be combined with the latest source code of the OS
distribution to confirm whether the patch is still needed
- c. Introduce patches for other OS distributions
- - You can refer to Section 3.6 \"Applying Patches for Other OS
Releases\".
- Use git am or git apply or other methods to import patches from
other OS distributions
- d. Modify other compiled and built files in the debian directory
- - debian/control
- debian/changelog needs to keep the original changelog
information
- debian/rules
- deiban/other files
After the modification is completed, you can compile and test locally
according to Section 5, and then push it to the remote warehouse after
the test has no problems.
## 5. Compile the source package
After completing the construction rules of the debian directory, compile
a round of source packages based on this. dsc file will be generated
# Cut to the development branch
git checkout openkylin/yangtze # Execute
dpkg-source in the source code directory
-b .
# 3. Compile
After building the source code package according to the content of the
previous chapter, compile it.
You can download an openkylin chroot environment and compile and debug
in the chroot environment.
chroot for x86:
http://files.build.openkylin.top/51159/chroot-openkylin-yangtze-amd64.tar.gz
chroot of riscv:
http://files.build.openkylin.top/51197/chroot-openkylin-yangtze-riscv64.tar.gz
At this stage, the packaging and building rules in the debian packaging
directory will be continuously modified and optimized until a complete
binary package that can be installed is packaged.
# 4. Installation test
Simply test whether the compiled binary program can be installed,
whether the system is normal after installation, etc.
# 5. Build a git repository
## 1. Create a gitee warehouse
Fork openkylin\'s community repository
# After fork to the personal warehouse, clone the personal warehouse to the local
git clone git@gitee.com: < username > /community.git
# Then add the source code package name in the corresponding sig group sig.yaml file
# For example, add a new one for packaging sig Software package, source-name needs to write the actual package name
echo "-<source-name>" >> sig/packaging/sig.yaml
# Then submit the changes and push them to the personal warehouse
git add sig/packaging/sig.yaml
git commit -m "Add xxx package"
git push origin master
Create a PR on the gitee web page, and then review it by the community
project leader. After the review is passed, the CI platform will
automatically create the corresponding git warehouse
## 2. Build the git repository
Build the git repository for the source package built in the second
chapter.
- download tool
Download the tool and install related dependencies according to the
usage method of the [source-packaging
tool](https://gitee.com/openkylin/packaging-tools#源码反向构建工具-source-packing)
- build git repository
```{=html}
<!-- -->
```
./source-packing import-to-git --dsc-file sqlite3_3.31.1-ok1.dsc --packaging-branch openkylin/yangtze
For more detailed git workflow, please refer to [the openKylin source
package git workflow](openKylin源码包git工作流.md)
## 3. Associate the remote warehouse and push it to gitee
It is necessary to push the package to the gitee warehouse after the
third chapter is compiled and the fourth chapter is installed and
tested.
# Enter the source code warehouse built in the second step
cd sqlite3
# Associate the remote warehouse and push it to the remote warehouse
git remote add origin git@gitee.com:openkylin/sqlte3.git
git push --all && git push --tags
# 6. Other content
1. A brief description of gitee\'s ci process:
```{=html}
<!-- -->
```
1. The first push of the software package:
The maintainer pushes the package to the gitee warehouse for the first time. At this time, the ci platform will package it and send it to the okbs compilation platform for compilation. The current compilation address is (https:// build.openkylin.top/~cibot/+archive/openkylin/citest/+packages)
2. Subsequent modification contributions:
developers need to fork the warehouse to their personal warehouse, and then make development and modification on the personal warehouse, after the source code modification is completed Modify the changelog to add a new version number, and then submit the PR to the original warehouse.
The maintainer reviews the PR. After the PR review is passed, the CI platform will automatically package the current PR and send it to the OKBS compilation platform for compilation. The compilation result will be added to the corresponding PR in the form of comments. The maintainer will use the compilation result and the access control of the CI platform Check the results to consider accepting the PR
2. The source address of each release version, taking gvfs as an
example:
Debian 11: https://tracker.debian.org/pkg/gvfs
Ubuntu 22.04: https://launchpad.net/ubuntu/+source/gvfs
Fedora 36: https://src.fedoraproject.org/rpms/gvfs
Arch: https://archlinux.org/packages/extra/x86_64/gvfs/
Deepin: https://ftp.sjtu.edu.cn/deepin/pool/
openEuler: https://gitee.com/src-openeuler/gvfs