有几种方法可以为ReactOS的发展作出贡献。 最常遇到的问题是不知道从哪里开始或做什么。 如果你能计划或理解与这个项目相关的技术信息,帮助发展可以很容易。

文档

有一些重要的点如果你想帮助文档ReactOS:

  1. 确保文档不存在(如果是,帮助改善)。

  2. 尊重洁净室逆向工程实践。

  3. 增加你的知识,其他开发人员可以找到它的地方。

测试ReactOS

定位错误

添加代码、改变或删除,有可能出现意想不到的结果。 这些意想不到的结果被称为bug。 通过本地化的缺陷,开发人员可以确定什么导致了错误和它的影响。 有各种各样的方法调试ReactOS同时测试。 识别一个错误后,检查是否已经知道通过搜索JIRA和添加任何额外的信息。 如果你认为这是一个不知名的虫子,考虑提交缺陷报告

修正错误

而不是寻找bug,您还可以尝试修复几个已经在JIRA上市。 修复bug需要更多的技能不仅仅是寻找他们,并且可以耗费时间。

编写测试

测试是用来检查api的功能和正确性ReactOS相比Windows实现。 还有一些你可以帮助ReactOS通过单元测试,可以发现在这里

补丁

一个补丁是一组改变现有的源代码。 变化的一个补丁可以被合并到现有的源代码。 这个过程被称为应用补丁(源代码)。 改变一个补丁包含和补丁结构可以显著影响应用补丁可能发生的后果。 下面是一些建议如何创建和使用补丁。

创建小片

回顾已经被证明是一种有效的方法发现bug,所以每个人都应该努力创建补丁容易复习。 不幸的是,人类是可怕的在跟踪大量的信息。 因此保持尽可能小的补丁,使复习更容易。

把只有一个补丁的变化有关

只把相关的一个补丁的变化将使复习更容易审查员需要记得少信息改变了现有的源代码。

注意到风险与应用相关的补丁

引 入一个错误的风险比其他人更高的某些类型的变化。 格式化语义变化是一个相对安全的改变而复杂的代码是一个高度危险的变化。 这意味着审查formatting-only补丁并不是评估一个补丁一样重要语义变化复杂的代码(因此它不会伤害那么多如果一块格式很大)。 当混合安全和不安全的变化,引入一个错误的整体风险在一个给定的补丁是一样的,如果变化分布在几个补丁。 然而,个人的风险补丁等于风险最危险的补丁的变化。 如果1线高度危险的变化是隐藏在2000线否则安全补丁,然后整体风险对整个补丁是高度危险的。 因此努力向变化相似的风险到相同的补丁。

为你的下一个补丁设立目标

帮 助防止你的补丁变得太大,设立一个或多个目标为你的下个补丁之前做任何修改。 一个目标可能是重构的一部分源代码难以理解。 它可以实现部分或全部的新特性,或者修复缺陷存在于现有的源代码。 如果实现目标需要太多的变化,将使补丁成为大型和/或包含许多不相关的变化,然后定义新的目标,到达时,将确保最初的目标部分实现。

保持专注在开发补丁

在开发一个补丁,它可以容易解决现有问题你遇到他们在阅读源代码。 这可以迅速导致补丁变得很大,包含几个不相关的变化与实现目标为块定义。 抵制诱惑在一份报告中,将在源代码中相反,或(甚至更好)把问题在问题跟踪系统。

回顾补丁

Drupal有一些小贴士回顾补丁。

实现新事物

考虑ReactOSα质量的软件,有很多缺失的功能Windows 操作系统。 开始前一个项目来实现一些东西,看看另一个人正在同一件事。 如果你发现有人已经工作的,问具体是什么工作需要任何协助或相关项目。 很多次一个人将开始实施,从未完成搬到别的东西。 确保你坚持你要实现什么,,不要害怕寻求帮助如果你需要帮助。





Development Introduction

There  are several ways to contribute to the development of ReactOS. The most  often encountered problem is not knowing where to begin or what to do.  If you are able to program or understand the technical information that  is pertinent to this project, helping the development can be easy.

Contents

1 Documentation

2 Test ReactOS

2.1 Localize bugs

2.2 Fix bugs

2.3 Write tests

3 Patches

3.1 Create small patches

3.2 Put only related changes in a patch

3.3 Notice the risks which are associated with applying the patch

3.4 Set goals for your next patch

3.5 Keep focus when developing the patch

3.6 Review Patches

4 Implement new things

5 See also

6 Places to find information

Documentation

There are some important points if you'd like to help document ReactOS:

Make sure the documentation doesn't exist yet (if it does, help improve it).

Respect clean room reverse engineering practices.

Add your knowledge to a place where the other developers can find it.

Test ReactOS

Localize bugs

As code is added, changed, or removed, it is possible for unintended  results to occur. These unintended results are known as bugs. By  localizing bugs, developers can identify what causes the bug and what it  affects. There are a variety of methods to debug ReactOS while testing it. After identifying a bug, check if it is already known about by searching JIRA and adding any additional information to the report. If you think that it is an unidentified bug, consider filing a bug report.

Fix bugs

Instead of looking for bugs, you can also try to fix a few that are  already listed in JIRA. Fixing bugs requires a lot more skill than  simply searching for them, and can be time consuming.

Write tests

Tests are used to check the functionality and correctness of APIs on  ReactOS compared to Windows implementations. There are also some unit  tests that you could help ReactOS pass, which can be found here.

Patches

A patch is a set of changes to existing source code. The changes in a  patch can be merged into existing source code. This process is referred  to as applying a patch (to source code). Which changes a patch contains  and the way the patch is structured can have significant impact on the  consequences that can happen from applying the patch. Below are a few  recommendations on how to create and use patches.

Create small patches

Reviewing has proven to be an effective method of discovering bugs,  so one should strive towards creating patches that are easy to review.  Unfortunately, humans are terrible at tracking large amount of information. Therefore keep the patches as small as possible to make reviewing easier.

Put only related changes in a patch

Putting only related changes in a patch will make reviewing easier as  the reviewer needs to recall less information about the existing source  code that is changed.

Notice the risks which are associated with applying the patch

The risk of introducing a bug is higher with some types of changes  than others. Formatting is a relatively safe change while semantic  changes to complex code is a highly risky change. This means that  reviewing a formatting-only patch is not as important as reviewing a  patch with semantic changes to complex code (and thus it doesn't hurt so  much if a formatting patch is large). When mixing safe and unsafe  changes, the overall risk of introducing a bug in a given patch is the  same as if the changes were spread over several patches. However, the  risk of the individual patch is equal to risk of the most risky change  in the patch. So if a 1 line highly risky change is hidden in a 2000  line otherwise safe patch, then the overall risk for the whole patch is  highly risky. Therefore strive towards putting changes of similar risk  into the same patch.

Set goals for your next patch

To help prevent your patches from becoming too large, set one or more  goals for your next patch before you start making any changes. A goal  could be to refactor a part of the source code which is hard to  understand. It could be to implement part or all of a new feature, or  fix a bug that exists in the existing source code. If achieving the  goals requires too many changes and would make the patch become large  and/or contain many unrelated changes, then define new goals which, when  reached, would ensure that the original goals would be partially  achieved.

Keep focus when developing the patch

While developing a patch, it can be tempting to fix existing issues  as you come across them while reading the source code. This can however  quickly cause the patch to become large and contain several unrelated  changes which have nothing to do with achieving the goals which were  defined for the patch. Resist the temptation and put in a note in the  source code instead, or (even better) put the issue in the issue  tracking system.

Review Patches

Drupal has some tips for reviewing patches.

Tips for reviewing patches

Implement new things

Considering ReactOS is alpha quality software, there is a lot of missing functionality  that Windows operating systems have. Before starting a project to  implement something, find out if another person is working on the same  thing. If you find that someone is already working on it, ask if any  assistance is needed for what specifically is being worked on or a  related project. Plenty of times a person will start to implement  something and never finish before moving to something else. Make sure  you stay committed to what you are going to implement, and do not be  afraid to ask for assistance if you need help with something.