don't require sending patches to libreboot first

i now wish for canoeboot to be its own project, entirely
isolated from libreboot. i myself will still use my own
preferred method: submit to libreboot and patch canoeboot
accordingly.

however, some users may wish to send to work on canoeboot
exclusively. this is permitted, as of now. i will simply
cherry-pick those patches into libreboot, where indicated.

Signed-off-by: Leah Rowe <info@minifree.org>

site/docs/maintain/index.md

@@ -38,35 +38,6 @@ check itself when running *any* command; if another command had to be executed
 first, it will do so automatically. Therefore, you can run any part of cbmk
 on its own, and the entire design is modular.
 
-A note about Canoeboot vs Libreboot
------------------------------------
-
-This manual is provided for reference, although most actual development will
-be done in Libreboot first, and ported over to Canoeboot after each new
-Libreboot release. More information is available in the [about
-page](../../about.md).
-
-Occasional hotfix patches could be submitted to Canoeboot, if it's a patch that
-only affects a Canoeboot release, otherwise you should submit patches
-to [Libreboot](https://libreboot.org/) if the change can also benefit Libreboot;
-Canoeboot would then receive the same change automatically, adapted after the
-next Libreboot release. It is *preferred* that you send patches to Libreboot
-first, because this will reduce the amount of duplicated code review.
-
-You could also use this manual, the Canoeboot documentation, and the Canoeboot
-build system itself, to make your own private modifications or even release
-your own coreboot distro (based upon Canoeboot - and you have this freedom
-with Libreboot too). Many choices are available!
-
-Some of the more seasoned FSF fanatics may not like this, but it's simply
-more efficient to work on Libreboot first and port to Canoeboot afterward. It
-is essentially no different to the Trisquel development model, where development
-from each new Ubuntu releases is adapted for new Trisquel releases; and Trisquel
-has a policy of providing its own builds for everything, rather than directly
-using Ubuntu's own builds - so too does Canoeboot provide its own builds, without
-using any of the builds provided in Libreboot releases. Same sh\*\*, different
-smell. Just plug your nose or something.
-
 Environmental variables
 =======================
 
@@ -104,20 +75,6 @@ behaves running it in release mode. Do this if you want to:
 Best practises for learning cbmk
 ================================
 
-In addition to *cbmk* (CanoeBoot MaKe), you could also learn lbmk (LibreBoot
-MaKe); lbmk is the Libreboot build system. A very similar document to the one
-you're reading now, is available as the [lbmk maintenance
-manual](https://libreboot.org/docs/maintain/); since Canoeboot is based on
-Libreboot, you may find it useful to know *Libreboot*. This and the lbmk manual,
-in addition to Canoeboot vs Libreboot generally, are two sides of the same coin,
-and both projects are lead by the same developer (Leah Rowe). Libreboot and
-Canoeboot are light and dark, but which is which depends on your perspective.
-
-As stated elsewhere, the preference is for most/all development to go in
-Libreboot first, because Canoeboot simply re-bases patches from Libreboot.
-This is done, to reduce duplication of labour, since both projects are
-maintained by the same developer.
-
 The follow sections will cover subdirectories, within cbmk. Contrary to what
 some may otherwise assume, it's best to learn about everything *except* scripts
 or code within Canoeboot, first. No, you should first learn about config files

site/git.de.md

@@ -3,23 +3,8 @@ title: Code review
 x-toc-enable: true
 ...
 
-NOTE FOR CONTRIBUTORS:
+If you wish to submit patches, you can. Submit them, using the instructions
-======================
+provided in the following sections:
-
-The preferred development style is: work on Libreboot, and port changes from
-each Libreboot release into Canoeboot, but do it all at once. Whenever a new
-Libreboot release comes out, a Canoeboot release will happen either
-simultaneously or a few days later, porting all suitable changes over from
-the Libreboot release. More information about this is available
-in the [about page](about.md).
-
-In other words: please only send patches directly to Canoeboot, if they are
-patches that only Canoeboot can benefit from; use your best judgement. The
-same rule applies for bug reports and testing; do Libreboot first.
-
-Leah Rowe is the founder and lead developer of both Canoeboot *and* Libreboot.
-Please see: [Libreboot git page](https://libreboot.org/git.html)
-and [Libreboot testers page](https://libreboot.org/docs/maintain/testing.html).
 
 Canoeboot Repositories
 ===================

site/git.md

@@ -3,37 +3,8 @@ title: Code review
 x-toc-enable: true
 ...
 
-NOTE FOR CONTRIBUTORS:
+If you wish to submit patches, you can. Submit them, using the instructions
-======================
+provided in the following sections:
-
-The preferred development style is: work on Libreboot, and port changes from
-each Libreboot release into Canoeboot, but do it all at once. Whenever a new
-Libreboot release comes out, a Canoeboot release will happen either
-simultaneously or a few days later, porting all suitable changes over
-from the Libreboot release. More information about this is available
-in the [about page](about.md).
-
-Exceptions are often made. Since only a subset of Libreboot changes are suitable
-for Canoeboot at any given time, the result is that a given Libreboot release
-may be *skipped* if the remaining Canoeboot-friendly changes are of low quantity.
-
-In other words: please only send patches directly to Canoeboot, if they are
-patches that only Canoeboot can benefit from; use your best judgement. The
-same rule applies for bug reports and testing; do Libreboot first.
-
-Leah Rowe is the founder and lead developer of both Canoeboot *and* Libreboot.
-Please see: [Libreboot git page](https://libreboot.org/git.html)
-and [Libreboot testers page](https://libreboot.org/docs/maintain/testing.html).
-
-While not everyone(especially the more hardened FSF fanatics) may approve of it,
-this is how Canoeboot is officially developed. It is essentially no different
-to how *Trisquel* is maintained, re-basing upon each new Ubuntu release! It is
-simply more efficient, enabling a general reduction in the duplication of labour.
-
-Leah Rowe is the BDFL for both Libreboot and Canoeboot, so this arrangement
-enables a tight grip on both projects, ensuring that they are always in
-absolutely perfect sync with each other (with the exception that Canoeboot
-will only include those changes which comply with GNU FSDG criteria).
 
 Canoeboot repositories
 ===================

site/git.uk.md

@@ -3,37 +3,8 @@ title: Огляд коду
 x-toc-enable: true
 ...
 
-NOTE FOR CONTRIBUTORS:
+If you wish to submit patches, you can. Submit them, using the instructions
-======================
+provided in the following sections:
-
-The preferred development style is: work on Libreboot, and port changes from
-each Libreboot release into Canoeboot, but do it all at once. Whenever a new
-Libreboot release comes out, a Canoeboot release will happen either
-simultaneously or a few days later, porting all suitable changes over
-from the Libreboot release. More information about this is available
-in the [about page](about.md).
-
-Exceptions are often made. Since only a subset of Libreboot changes are suitable
-for Canoeboot at any given time, the result is that a given Libreboot release
-may be *skipped* if the remaining Canoeboot-friendly changes are of low quantity.
-
-In other words: please only send patches directly to Canoeboot, if they are
-patches that only Canoeboot can benefit from; use your best judgement. The
-same rule applies for bug reports and testing; do Libreboot first.
-
-Leah Rowe is the founder and lead developer of both Canoeboot *and* Libreboot.
-Please see: [Libreboot git page](https://libreboot.org/git.html)
-and [Libreboot testers page](https://libreboot.org/docs/maintain/testing.html).
-
-While not everyone(especially the more hardened FSF fanatics) may approve of it,
-this is how Canoeboot is officially developed. It is essentially no different
-to how *Trisquel* is maintained, re-basing upon each new Ubuntu release! It is
-simply more efficient, enabling a general reduction in the duplication of labour.
-
-Leah Rowe is the BDFL for both Libreboot and Canoeboot, so this arrangement
-enables a tight grip on both projects, ensuring that they are always in
-absolutely perfect sync with each other (with the exception that Canoeboot
-will only include those changes which comply with GNU FSDG criteria).
 
 репозиторії Canoeboot
 ===================