Merge pull request #17 from MarceloRobert/docs/fix-typos

Docs: correct license and fix typos

Author: knurd

README.md

@@ -18,9 +18,7 @@ To install or develop for regzbot, see the [installation documentation](docs/ins
 
 ## Licensing
 
-Rezbot is available under the APGL 3.0; see the file COPYING for details. If
-you think a more liberal license should be used, let regzbot's author know what
-you'd prefer, as for now it's still quite easy to change the license.
+Rezbot is available under the LGPL 2.1; see the file COPYING for details.
 
 Regzbot was started by Thorsten Leemhuis as part of a project that has received
 funding from the European Union’s Horizon 2020 research and innovation

docs/getting_started.md

@@ -52,9 +52,9 @@ You want to make regzbot track a regression you or someone else reported already
 
    The caret ("^") at the end of the line tells regzbot to treat the parent mail (the one you reply to) as the report.
 
- * If the regression was reported to some bug tracker, sent a mail to the regression list that roughly outlines the regression and includes a paragraph that contains something like this:
+ * If the regression was reported to some bug tracker, send a mail to the regression list that roughly outlines the regression and includes a paragraph that contains something like this:
 
-   `#regzbot introduced: v5.13..v5.14-rc1 https://example.com/somewhere/someplace.html`s
+   `#regzbot introduced: v5.13..v5.14-rc1 https://example.com/somewhere/someplace.html`
 
 ### Update properties of a tracked regression
 
@@ -77,9 +77,9 @@ Simply write a reply to the report that uses the 'introduced' command again. Jus
 
 `#regzbot introduced: next-20211006..next-20211008`
 
-Note: to associate the regression to a tree, regzbot will look version tags and commits up in the Git trees for the Linux mainline, stable and next; if it can't a proper match, it might miss-file the regression. Thus stick to the format used in the examples and do not put any spaces before or after the `..`.
+Note: to associate the regression to a tree, regzbot will look version tags and commits up in the Git trees for the Linux mainline, stable and next; if it can't find a proper match, it might miss-file the regression. Thus stick to the format used in the examples and do not put any spaces before or after the `..`.
 
-Reminder: Linux distributors often modify or enhance their Linux based kernels, hence any problems you face with such kernels might be caused by these changes. That's why the Linux kernel developers [mainly care about regression happening with unmodified kernels, which are often called 'upstream kernel', 'official kernel', or 'vanilla'](https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html#make-sure-you-re-using-the-upstream-linux-kernel). Regzbot thus focuses on these, too. It thus only understand version tags used by the upstream Linux kernel developers and doesn't handle version numbers like `5.13.12-200.fc34.x86_64` (Fedora) or `5.4.0-12.15-generic` (Ubuntu). If you face a regression with these kernels you should report them to your distributor; alternatively, you can recheck if they occur with a upstream kernel and them report to the Linux kernel developers.
+Reminder: Linux distributors often modify or enhance their Linux based kernels, hence any problems you face with such kernels might be caused by these changes. That's why the Linux kernel developers [mainly care about regression happening with unmodified kernels, which are often called 'upstream kernel', 'official kernel', or 'vanilla'](https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html#make-sure-you-re-using-the-upstream-linux-kernel). Regzbot thus focuses on these, too. It thus only understand version tags used by the upstream Linux kernel developers and doesn't handle version numbers like `5.13.12-200.fc34.x86_64` (Fedora) or `5.4.0-12.15-generic` (Ubuntu). If you face a regression with these kernels you should report them to your distributor; alternatively, you can recheck if they occur with a upstream kernel and then report to the Linux kernel developers.
 
 Also remember to read the [Reporting Issues](https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html) document carefully, as some ranges are possible to encounter, but might be too vague and thus not be handled appropriately by the developers. One such range would be `v5.13.8..v5.14.4`, as such a regression might be caused by a change in mainline between v5.13 and v5.14, or due to a modification performed between 5.14 and 5.14.4. You thus ideally should rule out which of the two it is.
 
@@ -134,17 +134,17 @@ Both approaches work even if the fix hasn't reached the tree yet where this regr
 
 #### Duplicates
 
-Sometimes multiple people will report the same regressions without knowing about each other. When you notice that, check which of the two seems to be the one which is closer to the root of the problem or even a solution. Let's assume we have two reports already tracked by regzbot we call A and B; A is older, but B is more informative, as crucial developers replied there and discussed a solution. Then it's a good idea to mark A as duplicate of B. You have to options to do that:
+Sometimes multiple people will report the same regressions without knowing about each other. When you notice that, check which of the two seems to be the one which is closer to the root of the problem or even a solution. Let's assume we have two reports already tracked by regzbot we call A and B; A is older, but B is more informative, as crucial developers replied there and discussed a solution. Then it's a good idea to mark A as duplicate of B. You have two options to do that:
 
- * Send this rezbot command to the thread with the report A, where you replace `url` with a link to the B in the [mailing list archives on lore.kernel.org](https://lore.kernel.org/all/):
+ * Send this regzbot command to the thread with the report A, where you replace `url` with a link to the B in the [mailing list archives on lore.kernel.org](https://lore.kernel.org/all/):
 
    `#regzbot dup-of: url`
 
    It thus might look like this:
 
    `#regzbot dup-of: https://lore.kernel.org/all/30th.anniversary.repost@klaava.Helsinki.FI/`
 
- * Send this rezbot command to the thread with the report B, where you replace `url` with a link to the A in the [mailing list archives on lore.kernel.org](https://lore.kernel.org/all/):
+ * Send this regzbot command to the thread with the report B, where you replace `url` with a link to the A in the [mailing list archives on lore.kernel.org](https://lore.kernel.org/all/):
 
    `#regzbot dup: url`
 

docs/reference.md

@@ -17,13 +17,13 @@ But yes, the first task creates a small burden on reporters. This simply can't b
 
 #regzbot introduced: v5.13..v5.14
 
-Regzbot then considers he mail as a report for a regression that was introduced between Linux 5.13 and 5.14. Instead of a version range it's possible to specify a commit-id here, too, if the change causing the regression is known.
+Regzbot then considers the mail as a report for a regression that was introduced between Linux 5.13 and 5.14. Instead of a version range it's possible to specify a commit-id here, too, if the change causing the regression is known.
 
 ### What regzbot does once it's aware of a regression
 
 After regzbot was told about the regression, it will try to keep track of the fixing progress. To do so, it will record all direct and indirect replies to this mail.
 
-In addition, regzbot will look for mails and commits that link to the report using the mail's 'Message-ID'. Say someone reported a regression in a mail with the ID '4970a940-211b-25d6-edab-21a815313954@example.com', then regzbot will look out for mails and commits with a string like this and consider them realted:
+In addition, regzbot will look for mails and commits that link to the report using the mail's 'Message-ID'. Say someone reported a regression in a mail with the ID '4970a940-211b-25d6-edab-21a815313954@example.com', then regzbot will look out for mails and commits with a string like this and consider them related:
 
 Link: https://lore.kernel.org/r/4970a940-211b-25d6-edab-21a815313954@example.com/
 
@@ -37,7 +37,7 @@ Regzbot is also able to compile a report as pure text and sent them to the Linux
 
 ## Interacting with regzbot
 
-Above outlines the core concept of regzbot. Obviously that's not enough, as users will sometimes forgot to get regzbot involved when reporting a regression; and they might want to update the version range initially specified, for example after they found the change causing the regression using a bisection. Other times the report might turn out to be a duplicate of another report or not a regression at all. And developers might forget linking to the report in the fixes commit message, hence there needs to be another way to tell regzbot a tracked regression got resolved.
+Above outlines the core concept of regzbot. Obviously that's not enough, as users will sometimes forget to get regzbot involved when reporting a regression; and they might want to update the version range initially specified, for example after they found the change causing the regression using a bisection. Other times the report might turn out to be a duplicate of another report or not a regression at all. And developers might forget linking to the report in the fixes commit message, hence there needs to be another way to tell regzbot a tracked regression got resolved.
 
 To cover these and other use-cases it's possible to interact with regzbot via mail, as explained below.
 
@@ -149,7 +149,7 @@ The following 'regzbot commands' are intended mainly for people helping with reg
 
  * `#regzbot poke`
 
-   Regzbot will consider the mail with this command as a 'poke' asking for a progress update from someone involved. It's meant to be used in inquires when a regression seems to become stale, e.g., where there was no mail from a user or developer for a while. Regzbot in its reports and the web UI will show if someone sent a poke to get things rolling again. Apart from this the mail will be handled like it had contained `#regzbot ignore-activity`. It thus won't be counted as an activity and in regzbot web-interface continue to look state until someone replies.
+   Regzbot will consider the mail with this command as a 'poke' asking for a progress update from someone involved. It's meant to be used in inquires when a regression seems to become stale, e.g., where there was no mail from a user or developer for a while. Regzbot in its reports and the web UI will show if someone sent a poke to get things rolling again. Apart from this the mail will be handled like it had contained `#regzbot ignore-activity`. It thus won't be counted as an activity and in regzbot web-interface continue to look stale until someone replies.
 
 ### Commands regzbot accepts everywhere it looks
 
@@ -167,4 +167,4 @@ Regzbot ignores all '#regzbot commands' in threads that are not associated with
 
  * `#regzbot ^backmonitor: https://lore.kernel.org/r/30th.anniversary.repost@klaava.Helsinki.FI/`
 
-   Makes regzbot start monitoring the parent mail for the linked regressions and ignore the mail that contains this, as it it would contain a '#regzbot ignore-activity'. Useful for mails in the style of 'hey, next time when writing the commit message for a tracked regression fix, please add the link to the report of said regression'. For all other cases better reply to the report with a `#regzbot monitor` command pointing to the related discussion.
+   Makes regzbot start monitoring the parent mail for the linked regressions and ignore the mail that contains this, as it would contain a '#regzbot ignore-activity'. Useful for mails in the style of 'hey, next time when writing the commit message for a tracked regression fix, please add the link to the report of said regression'. For all other cases better reply to the report with a `#regzbot monitor` command pointing to the related discussion.