@@ -31,7 +31,7 @@ Release cycle
31
31
-------------
32
32
33
33
The major version releases are time-based and follow the cycle of the linux
34
- kernel releases. The cycle usually takes 2 months. A minor version releases may
34
+ kernel releases. The cycle usually takes 2 months. A minor version release may
35
35
happen in the meantime if there are bug fixes or minor useful improvements
36
36
queued.
37
37
@@ -49,7 +49,7 @@ architecture (with maximum backward compatibility), inside the [Github Actions
49
49
workflow] ( https://github.com/kdave/btrfs-progs/actions/workflows/artifacts-static-build.yml ) .
50
50
The ` btrfs.box ` is an all-in-one tool in the [ busybox] ( https://www.busybox.net )
51
51
style, the functionality is determined by the binary names (either symlink,
52
- hradlink or a file copy).
52
+ hardlink or a file copy).
53
53
54
54
### Feature compatibility
55
55
@@ -106,7 +106,7 @@ The development model of btrfs-progs shares a lot with the kernel model. The
106
106
change, you can read more about the
107
107
[ The Developer's Certificate of Origin (chapter 11)] ( https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin )
108
108
* if you are not used to the signed-off style, your contributions won't be
109
- rejected just because of it's missing, the _ Author:_ tag will be added as a
109
+ rejected just because of it missing, the _ Author:_ tag will be added as a
110
110
substitute in order to allow contributions without much bothering with
111
111
formalities
112
112
0 commit comments