On 10/25/2017 03:18 AM, Michał Górny wrote: >>> ... >>> The QA checks can inspect the installation image or live system >>> respectively, >> >> Respective to what? > > To the type of check, as explained later? If you want to help, then > please be specific instead of asking questions and expecting me to > figure out how should I change it. > >>> output and store both user- and machine-oriented QA warning logs, manipulate >>> the files and abort the install, as necessary. >>> >> >> An oxford comma would make that easier to read: "files, and abort the >> install as necessary." > > Wouldn't that change the meaning? The point is it can do all those > things as necessary, not just the last. >
The grammar is ambiguous but personally I would parse it the way you intend. To address both comments at once, I would change that whole sentence to, The QA checks can inspect the installation image or live system, output and store both user- and machine-oriented QA warning logs, manipulate files, and abort the install. The "can" makes the "as necessary" redundant. Usually "respectively" is used to match up two series of words in a one-to-one fashion, like "spoons and knives are used to eat soup and steak, respectively." Seeing it in the original abstract confused me a little because I couldn't tell what things I was supposed to be matching up in my head. Since the sentence reads fine without it, it can probably be omitted. (I know only one type of check can inspect the live image, but only one type of check can abort the install, too. It's OK to be a little vague in the abstract.) >>> In case of severe QA issues, the checks are allowed to alter the contents of >>> the installation image in order to sanitize them, or call the ``die`` >>> function >>> to abort the build. >> >> I'm not sure that having the image silently modified is a good idea. It >> seems like everyone would benefit more if the QA check crashed, and let >> the maintainer fix his ebuild. Is this already possible with the Portage >> checks, or is it new in the repository-based checks? > > I'm pretty sure this was used somewhere in Portage internally. Anyway, > if you want to change it, then convince people it's fine to add a new > check that is going to cause random packages to suddenly explode for > stable users when the problem can be fixed trivially. I wouldn't suggest that. Instead, we could do something like is happening on https://bugs.gentoo.org/588944 where we fix the packages before introducing the new check (it would have to be a very serious issue to "die" in the first place). If we want to commit the check as soon as possible -- before all of the ebuilds are fixed -- then we could add a whitelist at the top of the QA check script. Bugs would be filed against the packages, and once fixed, we would remove that $CAT/$P from the whitelist. >>> >>> Function specification >>> ---------------------- >> >> >> Also appears twice. > > How is that a problem? It appears twice because it strictly corresponds > to the same section in specification. > It's not, so long as it's intentional. Just checking.
