vendor: update everything

* If possible, update each dependency to the latest available version.

* Use releases over commit IDs and avoid vendoring branches.

Signed-off-by: Valentin Rothberg <rothberg@redhat.com>

1 files changed, 32 insertions, 1 deletions

diff --git a/vendor/github.com/checkpoint-restore/go-criu/README.md b/vendor/github.com/checkpoint-restore/go-criu/README.md
index a79b4d7fb..610756dbd 100644
--- a/vendor/github.com/checkpoint-restore/go-criu/README.md
+++ b/vendor/github.com/checkpoint-restore/go-criu/README.md
@@ -21,7 +21,38 @@ or to just check if at least a certain CRIU version is installed:
 	result, err := c.IsCriuAtLeast(31100)
 ```
 
+## How to contribute
+
+While bug fixes can first be identified via an "issue", that is not required.
+It's ok to just open up a PR with the fix, but make sure you include the same
+information you would have included in an issue - like how to reproduce it.
+
+PRs for new features should include some background on what use cases the
+new code is trying to address. When possible and when it makes sense, try to
+break-up larger PRs into smaller ones - it's easier to review smaller
+code changes. But only if those smaller ones make sense as stand-alone PRs.
+
+Regardless of the type of PR, all PRs should include:
+* well documented code changes
+* additional testcases. Ideally, they should fail w/o your code change applied
+* documentation changes
+
+Squash your commits into logical pieces of work that might want to be reviewed
+separate from the rest of the PRs. Ideally, each commit should implement a
+single idea, and the PR branch should pass the tests at every commit. GitHub
+makes it easy to review the cumulative effect of many commits; so, when in
+doubt, use smaller commits.
+
+PRs that fix issues should include a reference like `Closes #XXXX` in the
+commit message so that github will automatically close the referenced issue
+when the PR is merged.
+
+Contributors must assert that they are in compliance with the [Developer
+Certificate of Origin 1.1](http://developercertificate.org/). This is achieved
+by adding a "Signed-off-by" line containing the contributor's name and e-mail
+to every commit message. Your signature certifies that you wrote the patch or
+otherwise have the right to pass it on as an open-source patch.
+
 ### License
 
 The license of go-criu is the Apache 2.0 license.
-