Project:Quality Assurance/Meeting Agenda

This page should have topics to be discussed by the QA team at its next meeting. If you are a QA team member and you cannot make a meeting, please email the team beforehand with any opinions you would like brought up on the topics to be discussed. If you are a developer who wants the QA team to review a policy or bug at an upcoming meeting, please let us know (in #gentoo-qa) before adding it to the list of topics. Meetings are held on the third Wednesday of every month at 1900 UTC in #gentoo-qa.

The next meeting is set for: Wednesday, May 21, 2014 at 1800 UTC in #gentoo-qa.

Topics of next meeting

 * Roll call (creffett, patrick, Pinkbyte, TomWij, tommy, ulm, williamh, wired, zerochaos, Zlogene)
 * Open floor.

Topics of Wednesday, April 23, 2014

 * What do we do with hacked pkgconfig files? (Link)
 * Are there unclarities wrt what "QA team" and similar things mean in GLEP 48? An individual or the whole team? With agreement or not? (Link)
 * Move QA policies to the devmanual? (Suggested in "Move tree-related policies to devmanual" mail to our alias)
 * Where and how will we document what QA processes for both current and future Gentoo Developers and QA members? (Per Council meeting: "the council notes that QA is looking into documenting their process").

Portage tree business
... based on communication on our alias and/or IRC channel:


 * Where are the GNOME and QA team at with the GTK flag issue? (Mail was sent, either defer agenda item or ask leio or eva [were working on something])
 * Rely on dynamic dependencies (has binpkg and subslot problems), revision bumps (causes some unnecessary rebuilds) or keep status quo when changing dependencies in an existing ebuild?
 * Short look at the recent QA assigned bugs: How do we deal with [metadata breakage]? Do we help with  [help requested with readme.gentoo.eclass]? ...

QA processes and disagreements
... requested to be discussed by Council members:


 * Handling disagreements among ourselves (wrt two recent alias threads); do we need to change the QA process, or is the problem elsewhere?

More QA concerns
... raised by Gentoo Developers on the Gentoo mailing lists:


 * What will we do about the missing QA meeting logs and summaries?

Topics of Wednesday March 26, 2014

 * Rotating meeting times/other ways to get everyone to be able to make a meeting
 * vapier stabilizing on experimental arches (continued from last meeting, waiting on the Council to weigh in) (still continued, council hadn't met when we held the meeting)
 * Revisit policy on dropping packages to unstable when stabilization takes too long (need input from Zero_Chaos)
 * Tinderbox?
 * Status update on GTK flag issue
 * (time permitting) How to get more developers helping with QA work?

Topics of Wednesday February 19, 2014

 * Deprecating/banning EAPIs
 * Revisit policy on dropping packages to unstable when stabilization takes too long
 * vapier stabilizing on experimental arches (continued from last meeting, waiting on the Council to weigh in)
 * Multislot issue (continued, results from forums poll)
 * Review GTK USE flag situation as discussed on mailing lists (continued from last month)

Topics of Wednesday January 29, 2014

 * What should our workflow be for making policy?
 * What communication is expected when making changes to other devs' packages
 * What to do about the GTK USE flag situation? (hasufell's recent emails)
 * Official recommendation for how to recommend optional RDEPs (relevant to bug 498832)
 * What large projects do we want to tackle as a team? (See and/or add them to "Possible Future Project" in Project:Quality_Assurance/Current_projects)
 * Suggested project: Assist in migrating ebuilds away from EAPI 0/1/2 to latest.
 * How do we evaluate whether future stabilization improves or becomes worse? How bad is stabilization really at the moment? How can we make more users and/or developers interested in arch testing (and/or Gentoo)? Do we want to make a policy change now, or delay considering it till a later meeting in the future? ...? (WilliamH's stabilization thread)