Project:Quality Assurance/Meeting Summaries

This page summarizes previous meetings.

Summary of Wednesday January 29, 2014
Present: creffett, Pinkbyte, Tommy[D], TomWij, ulm, WilliamH, wired, zlogene

Absent: bonsaikitten, Zero_Chaos

The lead creffett appointed TomWij as deputy lead
When creffett is out (which will be a lot of weekends this semester) and a decision has to be made, TomWij is in charge; and anything TomWij does as deputy lead carries the same weight as creffett's decisions.

Meeting scheduling (Third Wednesday, 1900 UTC)
Third Wednesday of the month (which is a week after Council's meeting) at 1900 UTC.

8 QA members agreed, 0 rejected, 0 abstains, 0 didn't vote; 2 absent. Motion passed.

Policymaking workflow (by creffett and Tommy[D])
When a person brings us problem, we look into the problem and discuss it at meeting. If there is no policy on problem, we make policy; if the policy or documentation is unclear, we update it. If the policy is actively being ignored we politely ask the person to stop. It is more reactive than proactive, this does not preclude emergency action on our part. This will give the team the time to work out basic rules and workflows, we might do more proactive tasks later one, if there is any need for them.

There were some further clarifications by Pinkbyte:

TODO: Should be summarized as part of above workflow.

6 QA members agreed, 0 rejected, 0 abstains, 2 didn't vote; 2 absent. Motion passed.

Amount of communication expected from the QA team when making changes to maintainer's packages
We fix and send a friendly reminder for trivial fixes; open bug, wait 2 weeks, make a change for larger but non-critical fixes; we make a change and send a notification for critical fixes.

8 QA members agreed, 0 rejected, 0 abstains, 0 didn't vote; 2 absent. Motion passed.

GTK USE flag situation (gtk, gtk2, gtk3; relevant to )
We tentatively recommend "gtk means gtk2, gtk3 means gtk3, burn gtk2 flag, transition flags as appropriate" and discussing this further on @-dev.

Voting on this is unclear, however we have a majority that had no objections and wants to see discussion on the mailing list; there is no motion to pass here, it is merely a recommendation.

Official recommendation for how to recommend optional RDEPs (relevant to )
This yields a bikeshed between (not limiting to, in no particular order) README.gentoo, elog and optfeature as to which approach to use for this; and thus, for the moment, we agree that using USE-deps for optional packages is bad. Except in certain case-by-case circumstances, where an acknowledgement by the QA team is needed (which is then documented in a comment in the ebuild).

8 QA members agreed, 0 rejected, 0 abstains, 0 didn't vote; 2 absent. Motion passed.

How do we want to communicate policy/policy changes made during meetings?
gentoo-dev-announce, gentoo-dev, Gentoo Wiki, maybe a blog post, ...

No voting really happened, it comes down to communicate them on the required as well as on multiple appropriate channels such that we reach the right people.

What large projects do we want to tackle as a team?
Due to the length of the discussion, we consider "Possible Future Project" in Project:Quality_Assurance/Current_projects as sufficient to list the large projects; no actual discussion is crucially needed here.

Stabilization thread (TL;DR: Some slow arch team's queues are growing, how do we deal with that?)
Due to the multiple options / topics involved the early discussion mixed some of the topics; where the general idea is that we need get more people interested in joining arch teams (advertisement, PR, ...) as well as make sure that the arch team's work is more fit to the situation (more work on important, less work on non-important, ...) and that the naming of ~ can be confusing ("unstable" vs "testing" vs "current" vs ...).

The later part of the discussion however came up with a statement by Tommy[D] that we vote on: "Allow the maintainer to drop stable keyword or last stable version, if arch team does not respond within 90 days; if it breaks the dependency tree, then the maintainer has to work with maintainers of depending packages before dropping keyword/last stable version."

7 QA members agreed, 0 rejected, 1 abstains, 0 didn't vote; 2 absent. Motion passed.

Multislot issue
TODO: This still has to be summarized.

TODO: Any other open floor issues
TODO: This still has to be summarized.