sravan/system76-coreboot
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Documentation: Adjust master -> main branch

Browse Source 
Some of our documentation still points to the wrong branches

Change-Id: Idb72e4f44f294f64eb01c588027d300a53d6fb41
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/77875
Reviewed-by: Patrick Georgi <patrick@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit is contained in:
Stefan Reinauer 2023-09-14 12:47:26 -07:00
parent 0476f6aaab
commit b3f5d94f09
7 changed files with 23 additions and 23 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
Documentation/contributing/gerrit_guidelines.md
View File

@ -234,7 +234,7 @@ be set when you push the patches into gerrit. For example, to push a set of
commits with the i915-kernel-x60 set, use the command:
```Bash
git push origin HEAD:refs/for/master%topic=i915-kernel-x60
git push origin HEAD:refs/for/main%topic=i915-kernel-x60
```
* If one of your patches isn't ready to be merged, make sure it's obvious
@ -247,7 +247,7 @@ isn't as obvious as the commit message. These patches can also be pushed with
the wip flag:
```Bash
git push origin HEAD:refs/for/master%wip
git push origin HEAD:refs/for/main%wip
```
* When pushing patches that are not for submission, these should be marked
@ -259,13 +259,13 @@ who knows their commit ID, so don't use this for sensitive changes. To push
a private change, use the command:
```Bash
git push origin HEAD:refs/for/master%private
git push origin HEAD:refs/for/main%private
```
* Multiple push options can be combined:
```Bash
git push origin HEAD:refs/for/master%private,wip,topic=experiment
git push origin HEAD:refs/for/main%private,wip,topic=experiment
```
* Respond to anyone who has taken the time to review your patches, even if
@ -292,7 +292,7 @@ changed.
helps others and shows that these mainboards are currently being
maintained. At some point, boards that are not up to date in the
board-status repo will probably end up getting removed from the coreboot
master branch.
main branch.
* Abandon patches that are no longer useful, or that you don’t intend to
keep working on to get submitted.

16
Documentation/corebootBuildingGuide.tex
View File

@ -386,7 +386,7 @@ want to submit all commits in the currently checked-out branch for
review on gerrit:
{ \small
\begin{verbatim}
$ git config remote.origin.push HEAD:refs/for/master
$ git config remote.origin.push HEAD:refs/for/main
\end{verbatim}
}
@ -399,10 +399,10 @@ $ make gitconfig
\subsection{Work flow}
It is recommended that you make a new branch when you start to work, not pushing changes to master.
It is recommended that you make a new branch when you start to work, not pushing changes to main.
{ \small
\begin{verbatim}
$ git checkout master -b mybranch
$ git checkout main -b mybranch
\end{verbatim}
}
After you have done your changes, run:
@ -452,7 +452,7 @@ make a new local commit that fixes the issues reported by the
reviewers, then rebase the change by preserving the same Change-ID. We
recommend you to use the git rebase command in interactive mode,
Once your patch gets a +2 comment, your patch can be merged (cherry-pick, actually) to origin/master.
Once your patch gets a +2 comment, your patch can be merged (cherry-pick, actually) to origin/main.
%
% Working with Gerrit
@ -474,9 +474,9 @@ click \url{https://review.coreboot.org}
|Search for status:open |
+-----------------------------------------------------------+
|Subject Status Owner Project Branch Updated CR V |
|cpu: Rename.. Alexandru coreboot master 1:20 PM +1 |
|cpu: Only a.. Alexandru coreboot master 1:17 PM X |
|arch/x86: D.. Alexandru coreboot master 1:09 PM |
|cpu: Rename.. Alexandru coreboot main 1:20 PM +1 |
|cpu: Only a.. Alexandru coreboot main 1:17 PM X |
|arch/x86: D.. Alexandru coreboot main 1:09 PM |
| |
| Next -> |
|Press '?' to view keyboard shortcuts | Powered by Gerrit |
@ -637,7 +637,7 @@ Gerrit makes reviews easier by showing changes in a side-by-side
display, and allowing inline comments to be added by any reviewer.
Gerrit simplifies Git based project maintainership by permitting any
authorized user to submit changes to the master Git repository, rather
authorized user to submit changes to the upstream Git repository, rather
than requiring all approved changes to be merged in by hand by the
project maintainer. This functionality enables a more centralized
usage of Git.

6
Documentation/index.md
View File

@ -146,9 +146,9 @@ coreboot is primarily developed in the
system, using [Gerrit](https://review.coreboot.org) to manage
contributions and code review.
In general we try to keep the `master` branch in the repository functional
In general we try to keep the `main` branch in the repository functional
for all hardware we support. So far, the only guarantee we can make is
that the master branch will (nearly) always build for all boards in a
that the main branch will (nearly) always build for all boards in a
standard configuration.
However, we're continually working on improvements to our infrastructure to
@ -200,4 +200,4 @@ Contents:
* [External Resources](external_docs.md)
* [Documentation License](documentation_license.md)
[Documentation]: https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/Documentation/
[Documentation]: https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/main/Documentation/

6
Documentation/infrastructure/builders.md
View File

@ -74,7 +74,7 @@ These times are taken from the week of Feb 21 - Feb 28, 2022
There are a number of builds handled by the coreboot jenkins builders,
for a number of different projects - coreboot, flashrom, memtest86+,
em100, etc. Many of these have builders for their current master branch
em100, etc. Many of these have builders for their current main branch
as well as Gerrit and [Coverity](coverity.md) builds.
@ -91,14 +91,14 @@ machines. These tasks run overnight in the US timezones.
You can see all the builds in the main jenkins interface:
[https://qa.coreboot.org/](https://qa.coreboot.org/)
Most of the time on the builders is taken up by the coreboot master and
Most of the time on the builders is taken up by the coreboot main and
coreboot gerrit builds.
* [coreboot gerrit build](https://qa.coreboot.org/job/coreboot-gerrit/)
([Time trend](https://qa.coreboot.org/job/coreboot-gerrit/buildTimeTrend))
* [coreboot master build](https://qa.coreboot.org/job/coreboot/)
* [coreboot main build](https://qa.coreboot.org/job/coreboot/)
([Time trend](https://qa.coreboot.org/job/coreboot/buildTimeTrend))

4
Documentation/lib/fw_config.md
View File

@ -106,8 +106,8 @@ protection)* with the `ectool` command in a ChromeOS environment.
For more information on the firmware configuration field on ChromeOS devices see the Chromium
documentation for [Firmware Config][1] and [Board Info][2].
[1]: http://chromium.googlesource.com/chromiumos/docs/+/master/design_docs/firmware_config.md
[2]: http://chromium.googlesource.com/chromiumos/docs/+/master/design_docs/cros_board_info.md
[1]: http://chromium.googlesource.com/chromiumos/docs/+/HEAD/design_docs/firmware_config.md
[2]: http://chromium.googlesource.com/chromiumos/docs/+/HEAD/design_docs/cros_board_info.md
## Firmware Configuration Table

2
Documentation/lib/payloads/fit.md
View File

@ -180,5 +180,5 @@ The generated file includes a compressed initrd **initramfs.cpio.xz**, which
will be decompressed by the Linux kernel, a compressed kernel **Image.lzma**,
which will be decompressed by the FIT loader and an uncompressed devicetree blob.
[uImage.FIT]: https://raw.githubusercontent.com/u-boot/u-boot/master/doc/uImage.FIT/howto.txt
[uImage.FIT]: https://github.com/u-boot/u-boot/blob/master/doc/usage/fit/howto.rst
[U-Boot]: https://www.denx.de/wiki/U-Boot

2
Documentation/tutorial/part2.md
View File

@ -166,7 +166,7 @@ commit --amend` allows you to take back your commit and amend it.
When you are done with your commit, run `git push` to push your commit
to coreboot.org. **Note:** To submit as a private patch, use `git push
origin HEAD:refs/for/master%private`. Submitting as a private patch
origin HEAD:refs/for/main%private`. Submitting as a private patch
means that your commit will be on review.coreboot.org, but is only
visible to yourself and those you add as reviewers. This mode isn't
perfect: Somebody who knows the commit ID can still fetch the change and