Difference between revisions of "Development Introduction"

From ReactOS Wiki
Jump to: navigation, search
(Patches)
(See also: add Retired modules)
 
(19 intermediate revisions by 6 users not shown)
Line 1: Line 1:
Existem várias formas de contribuir para o desenvolvimento do ReactOS. O problema mais frequentemente encontrado é não saber por onde começar ou o que fazer. Se você é capaz de programar ou entender as informações técnicas que são pertinentes a este projecto, ajudando o desenvolvimento pode ser fácil.
+
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.
  
== Documentação ==
+
== Documentation ==
  
Existem alguns pontos importantes se você quiser ajudar a ReactOS documentos:  
+
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 [[Wikipedia:Clean room design|clean room reverse engineering]] practices.
 +
# Add your knowledge to a place where the other developers can find it.
  
# Certifique-se que a documentação ainda não existe (se isso acontecer, ajude melhorá-la).
+
== Test ReactOS ==
  
# Respeite práticas de [[Wikipedia:Clean room design|engenharia reversa sala limpa]].
+
=== Localize bugs ===
  
# Adicione o seu conhecimento para um lugar onde os outros desenvolvedores possam encontrá-lo.
+
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 [[Debugging|debug]] ReactOS while testing it. After identifying a bug, check if it is already known about by searching [https://jira.reactos.org/ JIRA] and adding any additional information to the report. If you think that it is an unidentified bug, consider [[File Bugs|filing a bug report]].
  
== Teste ReactOS ==
+
=== Fix bugs ===
  
=== Localize erros ===
+
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.
  
Como o código é adicionado, alterado ou removido, é possível que os resultados não intencionais ocorram. Estes resultados não intencionais são conhecidos como bugs. Ao localizarem os erros, os desenvolvedores podem identificar o que causa o erro e o que ela afecta. Há uma variedade de métodos para [[Debugging|depuração]] ReactOS enquanto o testa. Depois de identificar um erro, verifique se já é conhecido pesquisando [http://jira.reactos.org/ JIRA] e adicione qualquer informação adicional com o relatório. Se você acha que isso é um erro não identificado, considere [[File Bugs|apresentação de um relatório de erro]].
+
=== Write tests ===
  
=== Corrigir bugs ===
+
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 [https://reactos.org/testman/ here].
 
 
Em vez de olhar para os erros, também pode tentar corrigir alguns que já estão listados no Bugzilla. Corrigindo erros exige muito mais habilidade do que simplesmente procurar por eles, e pode ser demorado.
 
 
 
=== Escrever testes ===
 
 
 
Os testes são usados ​​para verificar a funcionalidade e correção de APIs no ReactOS em comparação com implementações do Windows. Existem também alguns testes de unidade que poderia ajudar o ReactOS a ultrapassar e que podem ser encontrados [http://www.reactos.org/testman/ aqui].
 
  
 
== Patches ==
 
== Patches ==
  
Um patch é um conjunto de alterações no código fonte existente. As mudanças em um patch podem ser misturadas em código-fonte existente. Este processo é referido como aplicar um patch (para código fonte). O que altera um conteudo patch e a forma como o patch está estruturado pode ter um impacto significativo sobre as consequências que podem acontecer com a aplicação do patch. Abaixo estão algumas recomendações sobre como criar e usar 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.
  
=== Criar pequenos patches ===
+
=== Create small patches ===
  
A revisão provou ser um método eficaz de descobrir erros, por isso deve-se esforçar para criar patches que sejam fáceis de rever. Infelizmente, os [http://www.eurekalert.org/pub_releases/2005-03/aps-hmc030805.php humanos são terríveis no rastreamento de grande quantidade de informações]. Portanto, mantenha os patches tão pequenos quanto possível para fazer a revisão mais fácil.
+
Reviewing has proven to be an effective method of discovering bugs, so one should strive towards creating patches that are easy to review. Unfortunately, [https://www.eurekalert.org/pub_releases/2005-03/aps-hmc030805.php humans are terrible at tracking large amount of information]. Therefore keep the patches as small as possible to make reviewing easier.
  
=== Coloque apenas as alterações relacionadas em um patch ===
+
=== Put only related changes in a patch ===
 
 
Colocar apenas mudanças relacionadas em um patch vai tornar a revisão mais fácil com o revisor precisar de lembrar menos informações sobre o código fonte existente que é alterado.
 
  
 +
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 ===
 
=== Notice the risks which are associated with applying the patch ===
Line 44: Line 40:
 
=== Set goals for your next 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 require 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.
+
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 ===
 
=== Keep focus when developing the patch ===
Line 54: Line 50:
 
Drupal has some tips for reviewing patches.
 
Drupal has some tips for reviewing patches.
  
[http://drupal.org/patch/review Tips for reviewing patches]
+
[https://www.drupal.org/patch/review Tips for reviewing patches]
  
 
== Implement new things ==
 
== Implement new things ==
  
 
Considering ReactOS is alpha quality software, there is a lot of [[Missing ReactOS Functionality|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.
 
Considering ReactOS is alpha quality software, there is a lot of [[Missing ReactOS Functionality|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.
 +
 +
 +
== Finding a good project to start ==
 +
 +
Finding a good project to start with can be a challenge, because when starting out you are (usually) not aware of all the possibilities.
 +
To help you find a project, here are some ideas to try:
 +
* Find a test that fails, and try to make it succeed: https://reactos.org/testman/
 +
* Look around in jira, and if you have problems finding nice projects to start with, there is a label for this: https://jira.reactos.org/issues/?jql=labels%20%3D%20starter-project
 +
* Ask for help in [[Connect_to_the_ReactOS_IRC_Channels|IRC]]
 +
* Additionally, there are some tests that cause crashes / hangs, but these might be slightly harder: https://jira.reactos.org/browse/ROSTESTS-125
  
 
== See also ==
 
== See also ==
 
* [[Create a keyboard layout]]
 
* [[Create a keyboard layout]]
 
* [[Building ReactOS]]
 
* [[Building ReactOS]]
 +
* [[Retired modules]]
  
 
== Places to find information ==
 
== Places to find information ==

Latest revision as of 14:10, 6 November 2019

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.

Documentation

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

  1. Make sure the documentation doesn't exist yet (if it does, help improve it).
  2. Respect clean room reverse engineering practices.
  3. 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.


Finding a good project to start

Finding a good project to start with can be a challenge, because when starting out you are (usually) not aware of all the possibilities. To help you find a project, here are some ideas to try:

See also

Places to find information