Project:Quality Assurance/QA Team Draft Policy

This article is a stub. You can help by expanding it.

Warning
The policies on this page do not apply to the tree! These are draft policies up for discussion, not final versions.

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:

CODE Example topic and its ideas

==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.

Revbumps on EAPI bump?

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