"Contact the someone on the recruiters team to subscribe you to the gentoo-core developer-only mailing list or if you have any trouble." Should read more like the following... "Contact someone on the recruiters team to be subscribed to the gentoo-core developer-only mailing list or if you are having difficulties." Reproducible: Always Steps to Reproduce: 1. 2. 3.
Found another minor grammatical error in section 5.d. "Team leads are responsible for organizing the developer in their team and coordinating releases and also resolving issues within the team, as well as improving products on the basis of feedback from the community." "developer" should be plural and the sentance could use some commas. A better version might be... "Team leads are responsible for organizing the developers in their team, coordinating releases, resolving issues within the team and improving products on the basis of feedback from the community."
Section 1.b "Naming ebuild files" contains duplicate information. The following paragraph first states information pertaining to the incrementing of Gentoo-Linux specific revision numbers. "This revision number is independent of the version of the source tarball and is used to inform people that a new and improved Gentoo Linux revision of a particular package is available. Initial releases of ebuilds must have no revision number; e.g., package-4.5.3 and are considered by Portage to have a revision number of zero. This means that counting goes as follows: 1.0 (initial version), 1.0-r1, 1.0-r2, etc." Some of this information is restated in the following paragraph, almost verbatim. "If you make non-trivial improvements to an existing ebuild file, you should copy the ebuild file to a new file with the revision number incremented by 1. Initial releases normally have no revision number, e.g. package-4.5.3, and are considered by Portage to have a a revision number of zero. This means that counting goes as follows: 1.0 (initial version), 1.0-r1, 1.0-r2, etc. Remember to always make mentions of your changes in the ChangeLog when you bump a revision; not doing so is against our CVS commit policy."
Yet another correction to section 1.b "Contents of an ebuild file: Variables". "The first part of every ebuild file is made up of a number of variables. They fall under 3 categories (and are marked below with these numbers): * READ: variables you can utilize but never set * MUST: variables you must always set * OPT: variables that you should set" Those are obviously not numbers.
Section 1.b "Contents of an ebuild file: Variables", description entry for the variable KEYWORDS. "... Packages that do no support the native architecture are automatically masked by Portage. ..." Should read instead as... "... Packages that do not support the native architecture are automatically masked by Portage. ..."
Section 1.b "Contents of an ebuild file: Functions", description entry for the function pkg_install. "Use this function install the package to an image in D." Should be... "Use this function to install the package to an image in D."
Section 1.b "Contents of an ebuild file: Functions", description entry for the function pkg_config. The descript mentions the variable ROOT in bold with bright blue font, but no mention of the actual meaning of ROOT can be found in any previous documention of ebuild variables and functions.
Section 1.b "Contents of an ebuild file: Helper Functions provided by eutils.eclass" description for helper function check_license. "Displays a license for the user to accept, if the an argument is not specified then the license specified by ${LICENSE} is used." Perhapes should read, "Displays a license for the user to accept, if no arguments are specified then the license specified by ${LICENSE} is used."
Section 1.f "Changelog", reads... "Whenever you update a (or write a new) ebuild, you must also update its (or create a new) ChangeLog." which should read instead... "Whenever you update (or write a new) an ebuild, you must also update its (or create a new) ChangeLog."
Section 2.b a lot of the eclass/ebuild code uses variables in the form $VAR and not ${VAR}. It was previously stated in the documentation that $VAR is bad, and ${VAR} is the correct syntax to use.
Section 3.b "Package updates without changing the description", the title of this subsection should read "Package updates without changing the Changelog".
I forgot to note that Comments #0 reffers to "Introduction: section 3.g" and and comment #1 reffers to "Guides: section 5.d". Comments #2 - #10 continue to reffer to the "Guides" section of the Developer Handbook.
All fixed, thanks!
