|
@ -0,0 +1,145 @@
|
||||||
|
# CCBS软件包编译平台使用说明
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## 访问地址
|
||||||
|
|
||||||
|
build.cckylin.com 新用户请注册个人账户,请注意邮箱前缀会成为用户个人ID
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## 开发前准备
|
||||||
|
|
||||||
|
### 登录和创建ppa
|
||||||
|
|
||||||
|
操作与launchpad相同,默认创建的为cckylin发行版的ppa。
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
### 添加ssh公钥
|
||||||
|
|
||||||
|
使用命令
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
> $ ssh-keygen -t rsa
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
创建ssh密钥,并视情况使用命令
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
> $ cat ~/.ssh/id_rsa.pub
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
将输出复制至图片所在位置
|
||||||
|
|
||||||
|
![添加SSH密钥](./img/添加ssh密钥位置.png)
|
||||||
|
|
||||||
|
点击 <span style="background-color:#448cff; padding:5px;border-radius:4px;color:white">Import Public Key</span> 上传即可
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
### 添加PGP公钥
|
||||||
|
|
||||||
|
创建公钥命令
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
> $ gpg --full-gen-key
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
根据提示补充相关信息,默认将会选择RSA类型,3072位长度且永不过期
|
||||||
|
|
||||||
|
并请填写姓名和常用邮箱
|
||||||
|
|
||||||
|
创建完成后使用命令
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
> $ gpg --fingerprint
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
可以查看当前系统中密钥
|
||||||
|
|
||||||
|
将密钥上传到 hkp://keyserver.build.cckylin.com:11371 执行命令
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
> $ gpg --keyserver hkp://keyserver.build.cckylin.com:11371 --send-keys <keyid 后8位即可>
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
上传后将创建密钥拷贝到图片所在位置
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
![添加PGP密钥](./img/添加gpg密钥位置.png)
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
点击 <span style="background-color:#448cff; padding:5px;border-radius:4px;color:white">import key</span> 即可
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
### 配置dput工具
|
||||||
|
|
||||||
|
修改本地 ~/.dput.cf 或 /etc/dput.cf ,添加如下内容:
|
||||||
|
|
||||||
|
LOGIN改为自己的ccbs帐号对应ID
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
> [ccbs]
|
||||||
|
|
||||||
|
> fqdn=build.cckylin.com:2121
|
||||||
|
|
||||||
|
> method=sftp
|
||||||
|
|
||||||
|
> incoming=%(ccbs)s
|
||||||
|
|
||||||
|
> login=LOGIN
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## 上传源码包到 ppa
|
||||||
|
|
||||||
|
源码包 changelog 中,系列代号设置为 yangtze
|
||||||
|
|
||||||
|
在执行 dput 前请保证系统环境中安装了 paramiko
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
> $ sudo pip3 install paramiko
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
使用该命令安装依赖
|
||||||
|
|
||||||
|
生成source.changes后,按照ppa页面的提示执行dput命令
|
||||||
|
|
||||||
|
例如:
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
> $ dput ccbs:~xiewei/ppa <source.changes>
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
dput执行成功后,需要等待服务器处理上传的文件,可在 http://archive.build.cckylin.com/dput-logs/ 查看处理结果。
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## 上传源码包到CCKylin
|
||||||
|
|
||||||
|
新源码包请先向技术委员会发出申请 ,具体请看[SIG组的成员与维护包变更流程](https://docs.cckylin.com/zh/SIG%E4%BD%BF%E7%94%A8%E6%89%8B%E5%86%8C/SIG%E7%BB%84%E7%9A%84%E6%88%90%E5%91%98%E4%B8%8E%E7%BB%B4%E6%8A%A4%E5%8C%85%E5%8F%98%E6%9B%B4%E6%B5%81%E7%A8%8B)
|
||||||
|
|
||||||
|
在确认获取相应权限后再上传cckylin相关ppa
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
> $ dput ccbs:cckylin <source.changes>
|
|
@ -0,0 +1,64 @@
|
||||||
|
# Gitee使用指南
|
||||||
|
|
||||||
|
优麒麟社区的参与者可以使用Gitee来参与到优麒麟社区项目中,通过提交BUG/Issue、获取项目、提交推送这几个角度来简单介绍如何使用Gitee。
|
||||||
|
|
||||||
|
## 通过GItee提交BUG/Issue
|
||||||
|
|
||||||
|
在优麒麟社区项目使用过程中有体验不佳、使用存在BUG的情况时,通过Gitee的Issue功能向相关的项目提交你的问题。
|
||||||
|
|
||||||
|
![ Gitee使用指南-新建Issue ](./img/新建issue.png)
|
||||||
|
|
||||||
|
点击新建Issue并在描述里添加该问题的详细描述,包括ISO版本、复现手法、复现步骤等信息,提交Issue请遵守《Issue报告规范》,完成相关信息填写后点击创建。完成这一过程即向优麒麟社区项目提交一次Issue。
|
||||||
|
|
||||||
|
## 通过Gitee获取项目
|
||||||
|
|
||||||
|
在Gitee上注册账号并登录后,用户可以选择先上传自己的SSH公钥,和仓库"只读"权限的 SSH Key 相比,账户的 SSH Key 同时具备推送/拉取的权限,对用户创建/参与的仓库均能使用,使用起来更加方便。
|
||||||
|
通过选择用户头像 -> 菜单“修改资料”,然后选择“SSH公钥”,填写一个便于识别的标题,然后输入用户的SSH公钥,没有SSH公钥的用户可以通过以下步骤添加公钥。
|
||||||
|
Linux操作系统或Mac操作系统用户可以打开终端输入:
|
||||||
|
|
||||||
|
> $ ssh-keygen -t rsa -C “*youremail@youremail.com*”
|
||||||
|
|
||||||
|
生成属于你的密钥,再使用命令:
|
||||||
|
|
||||||
|
> $ cat ~/.ssh/id_rsa.pub
|
||||||
|
|
||||||
|
在终端输出你的密钥,将其复制到:
|
||||||
|
|
||||||
|
![ Gitee使用指南-设置SSH ](./img/设置ssh.png)
|
||||||
|
|
||||||
|
即可。Windows操作系统用户打开Git Bash,在控制台中输入以下命令:
|
||||||
|
|
||||||
|
> $ ssh-keygen -t rsa -C “*youremail@youremail.com*”
|
||||||
|
|
||||||
|
在完成密码输入后 [c盘>用户>自己的用户名>.ssh] 目录下公钥已经生成,将id_rsa.pub文件输出后拷贝到指定位置即可。
|
||||||
|
在设置完SSH后可以直接使用,进入想要参与的优麒麟项目页面中,点击克隆,并在选中SSH后点击复制:
|
||||||
|
|
||||||
|
|
||||||
|
![ Gitee使用指南-clone项目 ](./img/clone项目.png)
|
||||||
|
|
||||||
|
进入系统后视用户操作系统情况打开终端或控制台,输入:
|
||||||
|
|
||||||
|
> $ git clone <粘贴内容>
|
||||||
|
|
||||||
|
回车即可获取项目源码。
|
||||||
|
没有添加SSH密钥的用户可以直接使用HTTPS链接进行复制:
|
||||||
|
进入系统后视用户操作系统情况打开终端或控制台,输入:
|
||||||
|
|
||||||
|
> $git clone <粘贴内容>
|
||||||
|
|
||||||
|
即可获取项目源码。
|
||||||
|
|
||||||
|
## 通过Gitee向项目提交推送
|
||||||
|
|
||||||
|
优麒麟社区项目的参与者众多,提交代码请参考遵守《代码合并与提交》。
|
||||||
|
如果需要向优麒麟社区项目提供代码,首先应当fork该项目,建立自己的Gitee仓库。
|
||||||
|
|
||||||
|
在合理的修改代码并上传到自己的的仓库后,点击 <span style="background: #fe7300; padding:5px;border-radius:4px;color:white;">+ Pull Requests</span> 开始提交你的修改pr。
|
||||||
|
|
||||||
|
|
||||||
|
![ Gitee使用指南-提交pr ](./img/提交pr.png)
|
||||||
|
|
||||||
|
请注意提交时的分支是否正确,确认无误后进入提交界面。补充好这次提交的相关信息后,点击创建,恭喜你,完成了一次向优麒麟的贡献。
|
||||||
|
|
||||||
|
|
||||||
|
以上就是Gitee基本使用,欢迎各位向优麒麟贡献力量,本指南也在持续更新中...
|
After Width: | Height: | Size: 279 KiB |
After Width: | Height: | Size: 193 KiB |
After Width: | Height: | Size: 172 KiB |
After Width: | Height: | Size: 98 KiB |
After Width: | Height: | Size: 43 KiB |
After Width: | Height: | Size: 29 KiB |
After Width: | Height: | Size: 94 KiB |
|
@ -8,4 +8,133 @@ editor: markdown
|
||||||
dateCreated: 2021-11-09T07:28:24.199Z
|
dateCreated: 2021-11-09T07:28:24.199Z
|
||||||
---
|
---
|
||||||
|
|
||||||
# issue报告规范
|
# issue报告规范
|
||||||
|
|
||||||
|
|
||||||
|
## 角色定义
|
||||||
|
为了更好的管理 issue,我们将参与者划分为以下角色
|
||||||
|
|
||||||
|
| 角色 | 职能 |
|
||||||
|
| :---: | :---: |
|
||||||
|
| 测试人员 | 对 UKUI 各项目进行测试 |
|
||||||
|
| 开发人员 | UKUI 各项目的实际开发与维护者 |
|
||||||
|
| 社区参与人员 | 社区爱好者、参与者 |
|
||||||
|
|
||||||
|
<br>
|
||||||
|
|
||||||
|
## Issue 分类标签
|
||||||
|
在中大型项目中,不同的参与者对项目参与程度不同。为了便于每位参与者发现并解决 issue,我们需要对 issue 进行分类。UKUI 项目默认有 9 个约定俗成的分类标签。
|
||||||
|
|
||||||
|
| 标签名 | 描述 |
|
||||||
|
| :---: | :---: |
|
||||||
|
| kind/bug | 该 issue 是参与者提出的未知 bug |
|
||||||
|
| kind/documentation | 该 issue 文档相关的问题 |
|
||||||
|
| kind/duplicate | 该 issue 是参与者提出的已知 bug |
|
||||||
|
| kind/enhancement | 该 issue 请求添加新功能特性或者优化已有功能 |
|
||||||
|
| kind/good-first-issue | 该 issue 对新接触项目的开发人员或者测试人员有帮助 |
|
||||||
|
| kind/help-wanted | 该 issue 需要寻求其他人员的帮助,或者项目新参与人员提的帮助问题 |
|
||||||
|
| kind/invalid | 该 issue 是错误的或不可用的 |
|
||||||
|
| kind/question | 该 issue 是存疑的或需要提供更多信息|
|
||||||
|
| kind/wontfix | 该 issue 在可见的项目排期内是不计划实现的功能需求或者修复 |
|
||||||
|
|
||||||
|
<br>
|
||||||
|
|
||||||
|
## Issue 状态标签
|
||||||
|
事实上,不同的 issue 对项目的影响程度或者说需要解决的急迫程度大有不同。为了对 issue 的优先级以及当前状态进行追踪, UKUI 约定了许多有用的标签。
|
||||||
|
|
||||||
|
<br>
|
||||||
|
|
||||||
|
### 优先级标签
|
||||||
|
| 标签名 | 描述 |
|
||||||
|
| :---: | :---: |
|
||||||
|
| priority/high | 高优先级的,重要紧急需要尽快处理的 issue |
|
||||||
|
| priority/medium | 中等优先级的,重要不紧急的 issue |
|
||||||
|
| priority/low | 低优先级的,不重要不紧急,一般用于小问题,或者需要确认排期计划的 issue |
|
||||||
|
|
||||||
|
<br>
|
||||||
|
|
||||||
|
### 优先级标签的颜色值:
|
||||||
|
- priority/high: <span style="padding:5px; border-radius:4px; background-color: #ff0000;color:white;">#ff0000</span>
|
||||||
|
- priority/medium: <span style="padding:5px; border-radius:4px; background-color: #ff3366;color:white;">#ff3366</span>
|
||||||
|
- priority/low: <span style="padding:5px; border-radius:4px; background-color: #aa8899;color:white;">#aa8899</span>
|
||||||
|
|
||||||
|
<br>
|
||||||
|
|
||||||
|
### Issue 状态标签
|
||||||
|
| 标签名 | 描述 |
|
||||||
|
| :---: | :---: |
|
||||||
|
| status/confirmed | 项目维护者已确认 issue 描述的问题存在 |
|
||||||
|
| status/resloved | 项目维护者已处理 issue 描述的问题,审阅无误后 close issue |
|
||||||
|
| status/reopen | 标记为 reslove 的 issue 再次出现问题 |
|
||||||
|
| status/need-assign | 该 issue 需要指定参与者负责 |
|
||||||
|
|
||||||
|
<br>
|
||||||
|
|
||||||
|
### issue 状态标签的颜色:
|
||||||
|
- status/need-assign: <span style="padding:5px; border-radius:4px; background-color: #ffff00;">#ffff00</span>
|
||||||
|
- status/confirmed: <span style="padding:5px; border-radius:4px; background-color: #00ffff;">#00ffff</span>
|
||||||
|
- status/resolved: <span style="padding:5px; border-radius:4px; background-color: #00ff00;">#00ff00</span>
|
||||||
|
- status/reopen: <span style="padding:5px; border-radius:4px; background-color: #ff6666;">#ff6666</span>
|
||||||
|
|
||||||
|
<br>
|
||||||
|
|
||||||
|
## 标签扩展
|
||||||
|
如果因为项目需要,而另外添加新标签,新标签不应该与已有的标签产生歧义,且应该说明该标签的用法以及规范,并更新到本文档,以保证项目参与人员的统一认知。
|
||||||
|
|
||||||
|
<br>
|
||||||
|
|
||||||
|
## Issue 工作流
|
||||||
|
|
||||||
|
### 测试人员 issue 工作流
|
||||||
|
1. 对于内测发现的 bug ,提交之后打上 kind/bug 标签,同时标明优先级 ( priority/high / priority/medium / priority/low )
|
||||||
|
2. 对于其他人提交的 issue ,根据提交内容,打上 kind/bug / kind/enhancement / kind/invalid / kind/documentation,并对 bug 进行验证,验证通过则评估其优先级,添加或者修改优先级标签;
|
||||||
|
3. 如果能明确责任人可直接在 issue 内分配到人,否则等待开发者自己领取或者项目负责人去分配;
|
||||||
|
4. 对于标注为 status/resolved 标签的 issue ,进行回归测试,如果验收通过则关闭该 issue ,不通过则将 status/resolved 标签替换为 status/reopen;
|
||||||
|
5. 对于验收通过的 issue 再次出现,需要将该 issue 重新打开,并打上 status/reopen 标签;
|
||||||
|
|
||||||
|
### 开发人员 issue 工作流
|
||||||
|
1. 对标注为 kind/bug 的 issue 进行自我验证,验证通过,打上 status/confirmed 标签;
|
||||||
|
2. 对于 status/confirmed 的 bug 进行领取(分配给自己);
|
||||||
|
3. 对于分配到自己名下的 issue ,如果不能复现或者有疑问,则打上 kind/question 标签让 issue 提交者提供更多信息;
|
||||||
|
4. 如果分配的 bug 已经修复,则改为 status/resolved 标签,让测试人员回归测试。如果自己名下有 status/reopen 的 issue , 请及时处理。
|
||||||
|
5. 对于暂时没时间处理需要别人帮助的 issue ,打上 kind/help-wanted 标签。
|
||||||
|
6. 对于可见的项目排期内不会去实现的功能需求或者修复的问题,打上 kind/wontfix。
|
||||||
|
|
||||||
|
### 社区参与人员 issue 工作流
|
||||||
|
1. 所有人发现问题或需求可提交 issue;
|
||||||
|
2. 可协助确认bug(在issue下回复);
|
||||||
|
3. 可对未分配到人的 issue 进行认领(不在 ukui 项目内的人员,在 issue 下进行回复即可),优先认领 kind/help-wanted 的 issue.
|
||||||
|
|
||||||
|
### Bug Issue
|
||||||
|
测试或者使用UKUI过程中遇到了已有功能问题,提出的Issue归属于该类型。 Issue模版如下:
|
||||||
|
|
||||||
|
> ISO版本: ISO 的版本号
|
||||||
|
>
|
||||||
|
> 测试环境: 描述测试的基础环境,cpu架构、机型等
|
||||||
|
>
|
||||||
|
> 测试步骤: 复现问题的步骤
|
||||||
|
>
|
||||||
|
> 1. xxx
|
||||||
|
> 2. xxx
|
||||||
|
> 3. xxxx
|
||||||
|
>
|
||||||
|
> 预期结果: 测试步骤正常应该出现的结果.
|
||||||
|
>
|
||||||
|
> 实际结果: 描述测试过程中出现的问题
|
||||||
|
>
|
||||||
|
> 重现概率: 必现 or 偶发
|
||||||
|
>
|
||||||
|
> 截图: 辅助问题说明的截图
|
||||||
|
>
|
||||||
|
> 补充说明: 需要补充说明的内容.
|
||||||
|
|
||||||
|
|
||||||
|
### Feature Issue
|
||||||
|
UKUI持续发开过程中提出的新的功能需求,或者用户在使用UKUI过程中希望添加功能,提出的Issue归属于该类型。 Issue模版如下:
|
||||||
|
> 功能需求: 描述需求功能点。
|
||||||
|
>
|
||||||
|
> 设计方案: 描述该需求的设计方案。
|
||||||
|
>
|
||||||
|
> 补充说明: 需要补充说明的内容。
|
||||||
|
|
||||||
|
以上就是BUG和Issue的提交规范,欢迎各位向优麒麟贡献力量,本规范也在持续更新中...
|
||||||
|
|