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>
master
Leah Rowe 2024-05-12 01:27:09 +01:00
parent a4358430eb
commit 474c952192
4 changed files with 6 additions and 122 deletions

View File

@ -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

View File

@ -3,23 +3,8 @@ title: Code review
x-toc-enable: true
...
NOTE FOR CONTRIBUTORS:
======================
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).
If you wish to submit patches, you can. Submit them, using the instructions
provided in the following sections:
Canoeboot Repositories
===================

View File

@ -3,37 +3,8 @@ title: Code review
x-toc-enable: true
...
NOTE FOR CONTRIBUTORS:
======================
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).
If you wish to submit patches, you can. Submit them, using the instructions
provided in the following sections:
Canoeboot repositories
===================

View File

@ -3,37 +3,8 @@ title: Огляд коду
x-toc-enable: true
...
NOTE FOR CONTRIBUTORS:
======================
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).
If you wish to submit patches, you can. Submit them, using the instructions
provided in the following sections:
репозиторії Canoeboot
===================