blueness 14/04/21 23:01:49 Added: 20140408-summary.txt Log: Meeting logs and summary for 20140408
Revision Changes Path 1.1 xml/htdocs/proj/en/council/meeting-logs/20140408-summary.txt file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/council/meeting-logs/20140408-summary.txt?rev=1.1&view=markup plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/council/meeting-logs/20140408-summary.txt?rev=1.1&content-type=text/plain Index: 20140408-summary.txt =================================================================== Summary of Gentoo council meeting 8 April 2014 Agenda ====== 1. Roll call 2. Open issues - vote on GLEP 63 3. Use of ISO/IEC prefixes vs base-10 4. Discussion of the recent controversy regarding new libudev and libgudev virtuals, their masking by QA member and subsequent unauthorized unmasking by their maintainer. 5. Bugs assigned to Council 6. Open floor 1. Roll call ============ Present: blueness dberkholz dilfridge rich0 ulm williamh scarabeus 2. Open issues - vote on GLEP 63 ================================ Council action last meeting tabled the vote on "GLEP 63: Gentoo GPG key policies" [1] because dilfridge, one of the authors, presented a shorter version which removed the "howto" language and reduced it to just policy [2]. The council has now had time to consider this version and the general feeling was that the GLEP should concentrate only on policy and move any questions of implementation to another document. The council unanimously approved the shorter version. [2] Ref: [1] https://wiki.gentoo.org/wiki/GLEP:63 [2] https://wiki.gentoo.org/wiki/User:Dilfridge/GLEP:1001a 3. Use of ISO/IEC prefixes vs base-10 ========================================================================= The council considered whether a) ISO/IEC prefixes, Ki=2^10, etc., should be preferred over ISO base-10 prefixes, k=10^3, etc., or b) we should just require unambiguous units in check-reqs.eclass, where KiB etc are base-2 and k etc are base-10 [1]. Two proposal were brought forward by rich0 [2]. Proposal 2 was adopted: "Whenever practical developers are required to use unit prefixes defined in IEC 80000-13 (KB, KiB, etc) so that output is unambiguous. This does not require maintainers to patch upstream code to change its behavior, but they should be applied with code that originates in Gentoo." Ref: [1] http://article.gmane.org/gmane.linux.gentoo.project/3428 [2] http://article.gmane.org/gmane.linux.gentoo.project/3438 4. Recent events regarding new virtuals, masking by QA and then unmasking ========================================================================= The council consider what action to take with regards to the controversy around the recent introduction of virtual/libudev and virtual/libgudev. Roughly the time sequence of events was as follows: 1) the eudev team was excluded from discussions about the virtuals 2) the virtuals were committed, leading to breakage for eudev 3) the virtuals were masked by a member of the QA team 4) the virtuals unmasking of the virtuals by their maintainer without authorization from QA. This led to two long discussion threads on [email protected] [1] and [email protected] [2]. dilfridge suggested the council take a position on five points which address the systematic problems in the Gentoo community that led to the above events [3]. The council approved sending an email to the community based on the following 4 of the 5 points: * The council encourages teams maintaining central parts of Gentoo to accept new developers as team members and teach them the required knowledge and intricacies. We consider this important to ensure long-term continuity and increase the bus factor in critical areas. * While it is any developer's choice not to participate on the gentoo-dev and gentoo-project mailing lists, they nevertheless serve as main communication channels. If something has been discussed there, and then action has been taken, the council regards ignorance of the discussion not as a good foundation for protests against the actions. * The council believes that a wide announcement and if needed discussion of changes to central parts of Gentoo (as, e.g., system packages, profiles) should be preferred. In particular, only informing "relevant people" makes no sense if others will also be affected. * The council strongly disapproves of any developers unilaterally reverting QA team actions. While any future case decisions lie with QA and ComRel teams, the council welcomes the idea of immediate sanctions in such a case. An individual developer who disagrees with an action made in the name of QA, whether the action is proper or not, MUST follow the escalation procedures set forth in GLEP 48, and is encouraged to work with QA, or eventually ComRel or the council to settle any concerns. The council will follow up on any accusations of QA abuse the same way as on any commit that is in conflict with a QA action. One point urging QA to adopt policies regarding internal disagreements was dropped since QA is in fact looking into the matter now [4]. Ref. [1] http://article.gmane.org/gmane.linux.gentoo.project/3417 [2] http://article.gmane.org/gmane.linux.gentoo.devel/90800 [3] http://article.gmane.org/gmane.linux.gentoo.project/3474 [4] http://article.gmane.org/gmane.linux.gentoo.project/3522 5. Bugs assigned to Council =========================== The council looked at two open bugs: a) Bug #503382 - Missing summaries for 20131210, 20140114, and 20140225 council meetings dberkholz said he would upload those summaries soon. b) Bug #477030 - Missing summary for 20130611 council meeting Still no progress here. scarabeus said he would try to bug Betelgeuse again. 6. Open floor ============= No issues were brought forward. Summary submitted by Anthony G. Basile <[email protected]>
