Project:Quality Assurance/QA Team Draft Policy

On this page we will list several topics, for each topic we can have multiple alternative ideas; we can then later discuss these alternatives, when acknowledged by the QA team lead it can then be moved to a real QA team policy.

The syntax used per topic is:

{{CodeBox|title=Example topic and its ideas|1=

Topic
Explanation or question regarding the topic.

First idea
Explanation of first idea.

Second idea
Explanation of second idea. }}

Messaging the maintainer (Example)
How do we make the maintainer aware of our actions?

We message them on IRC
It's better to use IRC because ... (personal, immediate response, ...)

We always message them on mail
It's better to send e-mails because ... (scriptable, always reachable without requiring to find the person, ...)

How much notification/permission is required?
The QA team is empowered to make changes, but what changes need approval from the package maintainer, what changes should the package maintainer be notified of, etc.

Functionality change rule
Suggestion for a dividing line: if the ebuild's functionality is or could be changed, ping the maintainer and wait a reasonable amount of time for a response before making the change. Things like small repoman fixes (extra spaces, unquoted vars, etc.) or even slightly larger changes like EAPI bumps will not need notification, while larger changes like eclass migrations which could affect the package require permission first.

Yes, revbump
Makes sure that the user gets all of the latest features

No, don't revbump
Less rebuilding for users and stabilizing work for arch teams

Network access in ebuild
There is currently no officially worded policy restricting ebuilds from accessing network. The developers not being careful enough commit ebuilds that do scary things like randomly fetching subpackages during build, accessing external Internet sites during testing or sometimes even accessing locally running services (e.g. database servers) to perform tests.

This causes a few problems:
 * ebuilds (or tests) sometimes fail when network is unavailable but developers don't test for that,
 * additional bandwidth is used unexpectedly (think of bandwidth-limited users, like GPRS or cheap servers),
 * privacy loss due to accessing random sites,
 * potential dangers of playing with live servers.

Proposed policy
Wording by Michał Górny (talk) 05:43, 24 November 2016 (UTC):


 * Ebuilds must never access network directly, even if they are provided full network access. All necessary data needs to be fetched using SRC_URI. A special exception is given for live ebuilds that can fetch resources in src_unpack (or src_fetch if such a phase is introduced), provided that they are hard-masked.

v2 by Michał Górny (talk) 10:15, 26 November 2016 (UTC):


 * Ebuilds must not access external network or local network services directly, even if they are provided full network access, with the following exceptions:
 * ebuilds that require network to fetch sources (live ebuilds) can do that as long as they are not visible in any of the standard profiles (i.e. have empty keywords or are otherwise masked),
 * ebuilds that require network for tests, documentation builds or other optional purposes may expose that functionality, as long as it can not be enabled using standard ebuild facilities -- i.e. additional environment variables or masked USE flags are fine,
 * ebuilds that require external network access unconditionally must be masked with an explicit explanation. However, since those ebuilds would be masked indefinitely, adding them is strongly discouraged.
 * Ebuilds can temporarily start services on the loopback interface if that is necessary. However, it is discouraged and UNIX sockets are recommended instead.