Fork us on GitHub Follow us on Facebook Follow us on Twitter

Changes between Version 25 and Version 26 of HowToContribute


Ignore:
Timestamp:
2017-11-13T17:16:39Z (19 months ago)
Author:
Jakub Jermář
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • HowToContribute

    v25 v26  
    2222== Working on your branch ==
    2323
    24 Now that you know what to do, you should go and create your private [wiki:BazaarWorkflow Bazaar branch] of HelenOS. This is essential so that we can later merge your changes together with your initials in the development history of the branch. During the coding phase, keep in mind that we will require your changes to meet our [wiki:CStyle coding style standards]. It will happen to you from time to time that you will need to consult something with the other people from the project. Don't be shy and feel free to discuss things with us either in the mailing list or on IRC. For example, you can create a merge directive in Bazaar and send it to the mailing list for code review. Make smaller, logically related changesets rather than one huge changeset. Make sure that each changeset is accompanied by a clear commit message in English.
     24Now that you know what to do, you should go and create your private [https://www.atlassian.com/git/tutorials Git clone] of HelenOS. The easiest way is to [https://github.com/HelenOS/helenos#fork-destination-box fork HelenOS on GitHub]. This is essential so that we can later merge your changes together with your initials in the development history of the branch. During the coding phase, keep in mind that we will require your changes to meet our [wiki:CStyle coding style standards]. It will happen to you from time to time that you will need to consult something with the other people from the project. Don't be shy and feel free to discuss things with us either in the mailing list or on IRC. For example, you can create a patch and send it to the mailing list for code review. Alternatively, you can open a [https://github.com/HelenOS/helenos/compare PR on GitHub]. Make smaller, logically related changesets rather than one huge changeset. Make sure that each changeset is accompanied by a clear commit message in English.
    2525
    2626== Submitting patches ==
    2727
    28 If you have a simple change that you would like us to push to the mainline, you can submit it in the form of a ''patch''. To submit your work as a patch, please follow these rules:
     28If you have a change that you would like us to merge into HelenOS, the easiest way is to [https://github.com/HelenOS/helenos/compare create a PR] (pull request) at [https://github.com/ GitHub]. Alternatively, you can point us to a public Git branch of yours by sending an e-mail to [http://lists.modry.cz/cgi-bin/listinfo/helenos-devel HelenOS-devel].
     29
     30You can also send us a traditional patch. To submit your work as a patch, please follow these rules:
    2931 * Please avoid describing the patch manually (e.g. "this piece of code is to be inserted at line XYZ of file ABC") and use proper tools and formats as explained below.
    30  * Always use unified diff format, as produced by running either `bzr diff` or `diff -u`.
     32 * Always use unified diff format, as produced by running either `git diff` or `diff -u`.
    3133 * Test the patch before submitting and run `make check -j 6` to see if the patch didn't break the build.
    3234 * Review the patch prior to submitting. Make sure it stays focused and does not introduce unrelated changes, including whitespace changes.
     
    3436 * Specifically, do not just attach the patch to a ticket as most developers won't be made aware of it
    3537 * Send the patch as an attachment. Inline patches will get broken by the MTAs.
    36  * Choose a [http://trac.helenos.org/wiki/BazaarWorkflow#Youridentity Bazaar identity] and include it in the message so we can correctly attribute you with `--author`. This is important as not everybody wants their real e-mail address to appear in the commit log.
    37 
    38 Alternatively you can provide us with a pointer to a public Bazaar branch (e.g. on [https://launchpad.net/ Launchpad]) from where we can pick the changes. In case you maintain a local branch with your changes and don't want to publish it, we can still merge from it using a Bazaar merge directive. A merge directive can be viewed as a better text patch which carries all the history and change information of your local branch while still being human readable. Once your local branch is ready to be merged, the merge directive can be created as follows:
    39 
    40 {{{
    41 $ bzr send -o my_merge.directive
    42 }}}
    43 
    44 Then send a brief message describing the change to our mailing list and attach ```my_merge.directive``` to it.
     38 * You must let your identity be known to us so that we know who contributed to HelenOS and who to give credit to.
    4539
    4640== Compiling the system ==
    4741
    48 Once you have your Bazaar branch ready you will want to compile the system so that you can test your changes. There are some common mistakes people make when trying to compile HelenOS so please read the [wiki:UsersGuide/CompilingFromSource compiling instructions] carefully before running to us claiming that HelenOS does not build or does not work.
     42Once you have your Git branch ready you will want to compile the system so that you can test your changes. There are some common mistakes people make when trying to compile HelenOS so please read the [wiki:UsersGuide/CompilingFromSource compiling instructions] carefully before running to us claiming that HelenOS does not build or does not work.
    4943
    5044== Integrating your changes ==
    5145
    52 When you have tested your changes carefully and are confident enough that there are no bugs, you can ask one of us to merge your changes to our official repository. For that, you need to do one of two things. Either send us your final Bazaar merge directive or publish your branch in a publicly accessible location (e.g. Launchpad) so that we can merge from there. Note that publishing your branch is a good idea anyway because others can see your progress and your changes are backed up.
     46When you have tested your changes carefully and are confident enough that there are no bugs, you can ask one of us to merge your changes to our official repository. For that, you need to do one of two things. Either create a PR at GitHub or publish your branch in a publicly accessible location (e.g. GitHub) so that we can merge from there. Note that publishing your branch is a good idea anyway because others can see your progress and your changes are backed up.
    5347
    5448Eventually, if your changes look good to us, we will merge them and you will become part of the history. However, this final step might require some patience. We never merge any code only because we want the functionality. The overall design, the quality and the readability of the code has the same importance for us as the functionality. Properly and thoroughly reviewing the code takes time and time is something nobody has in abundance.