Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
openeuler
libvirt
提交
2a13ecc9
L
libvirt
项目概览
openeuler
/
libvirt
通知
3
Star
0
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
L
libvirt
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
提交
Issue看板
提交
2a13ecc9
编写于
3月 09, 2010
作者:
J
Jim Meyering
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
doc: fix more typos in HACKING
* HACKING: More spelling/typo fixes.
上级
e839e33a
变更
1
隐藏空白更改
内联
并排
Showing
1 changed file
with
10 addition
and
10 deletion
+10
-10
HACKING
HACKING
+10
-10
未找到文件。
HACKING
浏览文件 @
2a13ecc9
...
...
@@ -96,7 +96,7 @@ around operators and keywords:
--no-tabs "$@"
}
Note that sometimes you'll have to postprocess that output further, by
Note that sometimes you'll have to post
-
process that output further, by
piping it through "expand -i", since some leading TABs can get through.
Usually they're in macro definitions or strings, and should be converted
anyhow.
...
...
@@ -342,7 +342,7 @@ complexity it's best to stick to the following general plan for all
#include <limits.h>
#if HAVE_NUMACTL Some system includes aren't supported
#
include <numa.h> everywhere so need these #if defence
s.
#
include <numa.h> everywhere so need these #if guard
s.
#endif
#include "internal.h" Include this first, after system includes.
...
...
@@ -377,18 +377,18 @@ of arguments.
Libvirt commit
ers
guidelines
Libvirt commit
ter
guidelines
============================
The AUTHORS files indicates the list of people with commit acces right
The AUTHORS files indicates the list of people with commit acces
s
right
who can actually merge the patches.
The general rule for commiting a patch is to make sure it has been reviewed
The general rule for commit
t
ing a patch is to make sure it has been reviewed
properly in the mailing-list first, usually if a couple of people gave an
ACK or +1 to a patch and nobody raised an objection on the list it should
be good to go. If the patch touches a part of the code where you're not the
main maintainer or not have a very clear idea of how things work, it's better
to wait for a more authoritative feedback though. Before commiting please
to wait for a more authoritative feedback though. Before commit
t
ing please
also rebuild locally and run 'make check syntax-check' and make sure they
don't raise error. Try to look for warnings too for example configure with
--enable-compile-warnings=error
...
...
@@ -396,13 +396,13 @@ which adds -Werror to compile flags, so no warnings get missed
Exceptions to that 'review and approval on the list first' is fixing failures
to build:
- if a recently commited patch breaks compilation on a platform
- if a recently commit
t
ed patch breaks compilation on a platform
or for a given driver then it's fine to commit a minimal fix
directly without getting the review feedback first
- similar
y
if make check or make syntax-check breaks, if there is
- similar
ly,
if make check or make syntax-check breaks, if there is
an obvious fix, it's fine to commit immediately
The patch should still be sent to the list (or tell what the fix was if
trivial) and 'make check syntax-check' should pass too before commiting
trivial) and 'make check syntax-check' should pass too before commit
t
ing
anything
Similar
y
fixes for documentation and code comments can be managed
Similar fixes for documentation and code comments can be managed
in the same way, but still make sure they get reviewed if non-trivial.
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录