blueness 14/04/22 17:55:00 Modified: 20140408-summary.txt Log: Fix line wrap and other minor errors
Revision Changes Path 1.2 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.2&view=markup plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/council/meeting-logs/20140408-summary.txt?rev=1.2&content-type=text/plain diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/council/meeting-logs/20140408-summary.txt?r1=1.1&r2=1.2 Index: 20140408-summary.txt =================================================================== RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/council/meeting-logs/20140408-summary.txt,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- 20140408-summary.txt 21 Apr 2014 23:01:49 -0000 1.1 +++ 20140408-summary.txt 22 Apr 2014 17:54:59 -0000 1.2 @@ -6,12 +6,12 @@ 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. +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 ============ @@ -21,11 +21,12 @@ 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. +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] @@ -44,9 +45,9 @@ 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." +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 @@ -57,20 +58,20 @@ ========================================================================= 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: +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. + 4) the vertuals were unmasked 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: +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 @@ -79,24 +80,23 @@ * 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. +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]. @@ -114,7 +114,8 @@ The council looked at two open bugs: -a) Bug #503382 - Missing summaries for 20131210, 20140114, and 20140225 council meetings +a) Bug #503382 - Missing summaries for 20131210, 20140114, and 20140225 council + meetings dberkholz said he would upload those summaries soon.
