From 474c95219267725079e7f2f826e26705fd539054 Mon Sep 17 00:00:00 2001 From: Leah Rowe Date: Sun, 12 May 2024 01:27:09 +0100 Subject: [PATCH] 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 --- site/docs/maintain/index.md | 43 ------------------------------------- site/git.de.md | 19 ++-------------- site/git.md | 33 ++-------------------------- site/git.uk.md | 33 ++-------------------------- 4 files changed, 6 insertions(+), 122 deletions(-) diff --git a/site/docs/maintain/index.md b/site/docs/maintain/index.md index 88ef36a..06b8043 100644 --- a/site/docs/maintain/index.md +++ b/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 diff --git a/site/git.de.md b/site/git.de.md index bfeaeaf..cff8b91 100644 --- a/site/git.de.md +++ b/site/git.de.md @@ -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 =================== diff --git a/site/git.md b/site/git.md index 96cdee1..1834ae4 100644 --- a/site/git.md +++ b/site/git.md @@ -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 =================== diff --git a/site/git.uk.md b/site/git.uk.md index 55d83dc..cbea16d 100644 --- a/site/git.uk.md +++ b/site/git.uk.md @@ -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 ===================