| 1 |
On 10/25/2017 03:18 AM, Michał Górny wrote: |
| 2 |
>>> ... |
| 3 |
>>> The QA checks can inspect the installation image or live system respectively, |
| 4 |
>> |
| 5 |
>> Respective to what? |
| 6 |
> |
| 7 |
> To the type of check, as explained later? If you want to help, then |
| 8 |
> please be specific instead of asking questions and expecting me to |
| 9 |
> figure out how should I change it. |
| 10 |
> |
| 11 |
>>> output and store both user- and machine-oriented QA warning logs, manipulate |
| 12 |
>>> the files and abort the install, as necessary. |
| 13 |
>>> |
| 14 |
>> |
| 15 |
>> An oxford comma would make that easier to read: "files, and abort the |
| 16 |
>> install as necessary." |
| 17 |
> |
| 18 |
> Wouldn't that change the meaning? The point is it can do all those |
| 19 |
> things as necessary, not just the last. |
| 20 |
> |
| 21 |
|
| 22 |
The grammar is ambiguous but personally I would parse it the way you |
| 23 |
intend. To address both comments at once, I would change that whole |
| 24 |
sentence to, |
| 25 |
|
| 26 |
The QA checks can inspect the installation image or live system, |
| 27 |
output and store both user- and machine-oriented QA warning logs, |
| 28 |
manipulate files, and abort the install. |
| 29 |
|
| 30 |
The "can" makes the "as necessary" redundant. Usually "respectively" is |
| 31 |
used to match up two series of words in a one-to-one fashion, like |
| 32 |
"spoons and knives are used to eat soup and steak, respectively." Seeing |
| 33 |
it in the original abstract confused me a little because I couldn't tell |
| 34 |
what things I was supposed to be matching up in my head. Since the |
| 35 |
sentence reads fine without it, it can probably be omitted. |
| 36 |
|
| 37 |
(I know only one type of check can inspect the live image, but only one |
| 38 |
type of check can abort the install, too. It's OK to be a little vague |
| 39 |
in the abstract.) |
| 40 |
|
| 41 |
|
| 42 |
|
| 43 |
>>> In case of severe QA issues, the checks are allowed to alter the contents of |
| 44 |
>>> the installation image in order to sanitize them, or call the ``die`` function |
| 45 |
>>> to abort the build. |
| 46 |
>> |
| 47 |
>> I'm not sure that having the image silently modified is a good idea. It |
| 48 |
>> seems like everyone would benefit more if the QA check crashed, and let |
| 49 |
>> the maintainer fix his ebuild. Is this already possible with the Portage |
| 50 |
>> checks, or is it new in the repository-based checks? |
| 51 |
> |
| 52 |
> I'm pretty sure this was used somewhere in Portage internally. Anyway, |
| 53 |
> if you want to change it, then convince people it's fine to add a new |
| 54 |
> check that is going to cause random packages to suddenly explode for |
| 55 |
> stable users when the problem can be fixed trivially. |
| 56 |
|
| 57 |
I wouldn't suggest that. Instead, we could do something like is |
| 58 |
happening on https://bugs.gentoo.org/588944 where we fix the packages |
| 59 |
before introducing the new check (it would have to be a very serious |
| 60 |
issue to "die" in the first place). |
| 61 |
|
| 62 |
If we want to commit the check as soon as possible -- before all of the |
| 63 |
ebuilds are fixed -- then we could add a whitelist at the top of the QA |
| 64 |
check script. Bugs would be filed against the packages, and once fixed, |
| 65 |
we would remove that $CAT/$P from the whitelist. |
| 66 |
|
| 67 |
|
| 68 |
|
| 69 |
>>> |
| 70 |
>>> Function specification |
| 71 |
>>> ---------------------- |
| 72 |
>> |
| 73 |
>> |
| 74 |
>> Also appears twice. |
| 75 |
> |
| 76 |
> How is that a problem? It appears twice because it strictly corresponds |
| 77 |
> to the same section in specification. |
| 78 |
> |
| 79 |
|
| 80 |
It's not, so long as it's intentional. Just checking. |
Archives