Changes

Jump to navigation Jump to search
3,381 bytes added ,  18:31, 4 January 2019
→‎Make a patch: Fix git send-email example to use "criu-dev" instead of "master" branch
Line 1: Line 1: −
How to submit patches into the CRIU
+
== Set up working environment ==
===================================
      +
Although criu could be run as non-root (see [[Security]]), development is better to be done as root. For example, some tests require root. So, it would be a good idea to set up some recent Linux distro on a virtual machine.
   −
Obtaining the source code
+
== Get the source code ==
-------------------------
     −
The CRIU sources are tracked by Git SCM at http://git.criu.org
+
The CRIU sources are tracked by Git. Official CRIU repo is at [https://github.com/checkpoint-restore/criu https://github.com/checkpoint-restore/criu].
repository. You either could download packed sources or use git
  −
tool itself.
     −
For example to clone crtools one need to type
+
The repository may contain multiple branches. Development happens in the '''criu-dev''' branch.
   −
        git clone git://git.criu.org/crtools.git
+
To clone CRIU repo and switch to the proper branch, run:
    +
<pre><nowiki>
 +
        git clone https://github.com/checkpoint-restore/criu criu
 +
        cd criu
 +
        git checkout criu-dev
 +
</nowiki></pre>
   −
Changing the source code
+
== Compile ==
------------------------
     −
When you change the source code keep in mind -- we prefer tabs and
+
First, you need to install compile-time dependencies. Check [[Installation#Dependencies]] for more info.
indentations to be 8 characters width.
     −
Other "rules" could be learned from the source code -- just make your code
+
To compile CRIU, run:
to look similar.
      +
        make
   −
Producing a patch
+
This should create the <code>./criu/criu</code> executable.
-----------------
     −
There are at least two ways to make it right.
+
== Edit the source code ==
   −
1) git format-patch
+
If you use ctags, you can generate the ctags file by running
   −
    You might need to read documentation on Git SCM how to prepare patch
+
        make tags
    for mail submission. Take a look on http://book.git-scm.com/ and/or
  −
    http://git-scm.com/documentation for details. It should not be hard
  −
    at all.
     −
2) Use "diff -up"
+
When you change the source code, please keep in mind the following code conventions:
   −
    Use "diff -up" or "diff -uprN" to create patches.
+
* we prefer tabs and indentations to be 8 characters width
 +
* consider reading [https://www.kernel.org/doc/Documentation/process/coding-style.rst Linux kernel coding style].
    +
Other conventions can be learned from the source code itself. In short, make sure your new code
 +
looks similar to what is already there.
   −
Signing your work
+
== Test your changes ==
-----------------
     −
To improve tracking of who did what we've introduced a "sign-off" procedure
+
CRIU comes with an extensive test suite. To check whether your changes introduce any regressions, run
on patches that are being emailed around.
     −
The sign-off is a simple line at the end of the explanation for the
+
        make test
patch, which certifies that you wrote it or otherwise have the right to
+
 
pass it on as a open-source patch. The rules are pretty simple: if you
+
The command runs [[ZDTM Test Suite]]. Check for any error messages produced by it.
can certify the below:
+
 
 +
In case you'd rather have someone else run the tests, you can use travis-ci for your
 +
own github fork of CRIU. It will check the compilation for various supported platforms,
 +
as well as run most of the tests from the suite. See https://travis-ci.org/checkpoint-restore/criu
 +
for more details.
 +
 
 +
== Make a patch ==
 +
 
 +
To create a patch, run
 +
 
 +
    git format-patch --signoff origin/criu-dev
 +
 
 +
You might need to read GIT documentation on how to prepare patches
 +
for mail submission. Take a look at http://book.git-scm.com/ and/or
 +
http://git-scm.com/documentation for details. It should not be hard
 +
at all.
 +
 
 +
We recommend to post patches using <code>git send-email</code>
 +
   
 +
  git send-email --cover-letter --no-chain-reply-to --annotate \
 +
                --confirm=always --to=criu@openvz.org criu-dev
 +
 
 +
Note that the <code>git send-email</code> subcommand may not be in
 +
the main git package and using it may require installation of a
 +
separate package, for example the "git-email" package in Fedora and
 +
Debian.
 +
 
 +
If this is your first time using git send-email, you might need to
 +
configure it to point it to your SMTP server with something like:
   −
        Developer's Certificate of Origin 1.1
+
    git config --global sendemail.smtpServer stmp.example.net
   −
        By making a contribution to this project, I certify that:
+
If you get tired of typing <code>--to=criu@openvz.org</code> all the time,
 +
you can configure that to be automatically handled as well:
   −
        (a) The contribution was created in whole or in part by me and I
+
    git config sendemail.to criu@openvz.org
            have the right to submit it under the open source license
  −
            indicated in the file; or
     −
        (b) The contribution is based upon previous work that, to the best
+
If a developer is sending another version of the patch (e.g. to address
            of my knowledge, is covered under an appropriate open source
+
review comments), they are advised to note differences to previous versions
            license and I have the right under that license to submit that
+
after the <code>---</code> line in the patch so that it helps reviewers but
            work with modifications, whether created in whole or in part
+
doesn't become part of git history. Moreover, such patch needs to be prefixed
            by me, under the same open source license (unless I am
+
correctly with <code>--subject-prefix=PATCHv2</code> appended to
            permitted to submit under a different license), as indicated
+
<code>git send-email</code> (substitute <code>v2</code> with the correct
            in the file; or
+
version if needed though).
   −
        (c) The contribution was provided directly to me by some other
+
== Sign your work ==
            person who certified (a), (b) or (c) and I have not modified
  −
            it.
     −
(d) I understand and agree that this project and the contribution
+
To improve tracking of who did what, we ask you to sign off the patches
    are public and that a record of the contribution (including all
+
that are to be emailed.
    personal information I submit with it, including my sign-off) is
  −
    maintained indefinitely and may be redistributed consistent with
  −
    this project or the open source license(s) involved.
      +
The sign-off is a simple line at the end of the explanation for the
 +
patch, which certifies that you wrote it or otherwise have the right to
 +
pass it on as an open-source patch.  The rules are pretty simple: if you
 +
can certify the below:
 +
 +
<div class="toccolours mw-collapsible mw-collapsed" style="width: 46em;">
 +
'''Developer's Certificate of Origin 1.1'''
 +
<div class="mw-collapsible-content">
 +
    By making a contribution to this project, I certify that:
 +
   
 +
    (a) The contribution was created in whole or in part by me and I
 +
        have the right to submit it under the open source license
 +
        indicated in the file; or
 +
   
 +
    (b) The contribution is based upon previous work that, to the best
 +
        of my knowledge, is covered under an appropriate open source
 +
        license and I have the right under that license to submit that
 +
        work with modifications, whether created in whole or in part
 +
        by me, under the same open source license (unless I am
 +
        permitted to submit under a different license), as indicated
 +
        in the file; or
 +
   
 +
    (c) The contribution was provided directly to me by some other
 +
        person who certified (a), (b) or (c) and I have not modified
 +
        it.
 +
   
 +
    (d) I understand and agree that this project and the contribution
 +
        are public and that a record of the contribution (including all
 +
        personal information I submit with it, including my sign-off) is
 +
        maintained indefinitely and may be redistributed consistent with
 +
        this project or the open source license(s) involved.
 +
</div></div>
 
then you just add a line saying
 
then you just add a line saying
   Line 84: Line 135:     
using your real name (please, no pseudonyms or anonymous contributions if
 
using your real name (please, no pseudonyms or anonymous contributions if
it possible)
+
it possible).
    +
Hint: you can use <code>git commit -s</code> to add Signed-off-by line to your
 +
commit message. To append such line to a commit you already made, use
 +
<code>git commit --amend -s</code>.
   −
An example of patch message
+
<div class="toccolours mw-collapsible mw-collapsed" style="width: 46em;">
---------------------------
+
'''Example patch message'''
 +
<div class="mw-collapsible-content">
   −
From: Random J Developer <random at developer.example.org>
+
From: Random J Developer <random at developer.example.org>
Subject: [PATCH] Short patch description
+
Subject: [PATCH] Short patch description
 +
 +
Long patch description (could be skipped if patch
 +
is trivial enough)
 +
 +
Signed-off-by: Random J Developer <random at developer.example.org>
 +
---
 +
Patch body here
 +
</div></div>
   −
Long patch description (could be skipped if patch
+
== Mail patches ==
is trivial enough)
     −
Signed-off-by: Random J Developer <random at developer.example.org>
+
The patches should be sent to CRIU development mailing list, <code>criu AT openvz.org</code>. Note that you need to be subscribed first in order to post. The list web interface is available at https://openvz.org/mailman/listinfo/criu; you can also use standard mailman aliases to work with it.
---
  −
Patch body here
      +
Please make sure the email client you're using doesn't screw your patch (line wrapping and so on).
   −
Mailing patches
+
== Wait for response ==
---------------
     −
The patches should be sent to CRIU development mailing list
+
Be patient. Most CRIU developers are pretty busy people so if
which is located at https://openvz.org/mailman/listinfo/criu
+
there is no immediate response on your patch — don't be surprised,
 +
sometimes a patch may fly around a week before it gets reviewed.
   −
Please make sure the email client you're using doesn't screw
+
== Continuous integration ==
your patch (line wrapping and so on).
      +
''Main article: [[Continuous integration]]''
   −
Wait for response
+
CRIU tests are run for each series sent to the mailing list. If you get a message from our patchwork that patches failed to pass the tests, you have to investigate what is wrong.
-----------------
     −
Be patient. Most CRIU developers are pretty busy people so if
+
We also recommend you to [[Continuous integration#Enable Travis CI for your repo|enable Travis CI for your repo]] to check patches in your git branch, before sending them to the mailing list.
there is no immediate response on your patch -- don't be surprised,
  −
sometimes a patch may fly around a week(s) before it get reviewed.
  −
But definitely the patches will not go to /dev/null.
     −
    ---
+
[[Category:Development]]
    With best regards,
  −
    CRIU-team
 
277

edits

Navigation menu