Apr 08 15:03:36 let's start: blueness dberkholz dilfridge rich0 scarabeus ulm williamh Apr 08 15:03:39 ping ^^^ Apr 08 15:03:44 * WilliamH here Apr 08 15:03:48 * rich0 is here Apr 08 15:03:59 * ulm here Apr 08 15:04:03 * dilfridge here Apr 08 15:04:17 hi Apr 08 15:04:27 scarabeus, ping? Apr 08 15:04:42 the minutes are at http://dev.gentoo.org/~blueness/council/council_agenda_20140408.txt Apr 08 15:04:57 take a minute to look them over and see if they are okay, if i missed something Apr 08 15:05:47 I'll pop up the resolution suggestions in the right places... Apr 08 15:05:59 dilfridge, yes that would be best Apr 08 15:06:10 for the agenda i tried to be minimalist Apr 08 15:06:27 okay first item then is GLEP 63 Apr 08 15:06:33 if you recall we tabled that from last time Apr 08 15:06:41 pending some language changes from dilfridge Apr 08 15:06:54 blueness: should I text scarabeus? Apr 08 15:06:55 we had an issue regarding how much policy vs implementation should be in the GLEP Apr 08 15:07:02 ulm, yes! Apr 08 15:07:04 please do Apr 08 15:07:07 we had an issue regarding how much policy vs implementation should be in the GLEP Apr 08 15:07:07 he's in danger of a slacker mark Apr 08 15:07:19 the feeling was we should move implementation out Apr 08 15:07:21 sent Apr 08 15:07:26 [pmg Apr 08 15:07:27 pong Apr 08 15:07:29 :) Apr 08 15:07:32 thanks for the ping :) Apr 08 15:07:34 scarabeus, okay! saved by the bell Apr 08 15:07:35 hi :) Apr 08 15:07:42 i was here but meanwhile i got distracted again :) Apr 08 15:08:06 dilfridge, do you want to say anything about the final language for GLEP 63? Apr 08 15:08:36 nothing changed... I pinged robbat2 but did not get any result. Apr 08 15:08:41 I suggest the following: Apr 08 15:09:06 1) we vote whether we prefer the long or the short version (with or without docs/explanations) Apr 08 15:09:19 2) we vote to confirm the version Apr 08 15:09:25 the versions are here: Apr 08 15:09:40 https://wiki.gentoo.org/wiki/User:Dilfridge/GLEP:1001 long version Apr 08 15:09:49 https://wiki.gentoo.org/wiki/User:Dilfridge/GLEP:1001a short version Apr 08 15:10:02 the actual specs should be identical Apr 08 15:11:07 I do prefer the short version - the docs are spotty, but the spec is fine. Apr 08 15:11:10 dilfridge, the shorter version just seems to have the full ~/.gnupg/gpg.conf at the end Apr 08 15:11:26 it's not the full file Apr 08 15:11:27 rich0, i concur, the shorter is better Apr 08 15:11:38 i like the shorter too Apr 08 15:11:51 Oh, the spec isn't quite the same, good catch blueness Apr 08 15:11:54 dilfridge, okay if you make avaialble the extra FAQ in a seperate wiki, then yeah Apr 08 15:12:09 separate wiki page Apr 08 15:12:09 I'd prefer the shorter version too Apr 08 15:12:23 okay are we ready to vote for GLEP 63 - shorter version - to be adopted? Apr 08 15:12:58 let me call the question ... all those in favor of GLEP 63 - short version - say "yes" Apr 08 15:13:01 Sure - this is a standards glep, so it is accepted until a reference std is in place Apr 08 15:13:08 Then it is final. Apr 08 15:13:13 I seem to be the only one to prefer the long version, but I also vote yes for the short one Apr 08 15:13:15 * dilfridge yes Apr 08 15:13:18 * blueness yes Apr 08 15:13:21 * ulm yes Apr 08 15:13:22 * rich0 yes Apr 08 15:13:24 * scarabeus yes Apr 08 15:13:30 * WilliamH yes Apr 08 15:13:34 unanimous Apr 08 15:13:42 ping the bug with a reminder of your decision, please Apr 08 15:13:54 yes Apr 08 15:13:56 creffett|irssi, okay Apr 08 15:14:03 creffett|irssi, do you have the bug number handy for the log? Apr 08 15:14:16 blueness: unfortunately I do not Apr 08 15:14:28 * twitch153 (~twitch153@gentoo/developer/twitch153) has joined #gentoo-council Apr 08 15:14:31 creffett|irssi, okay no problem i'll look it up later Apr 08 15:14:46 bug 501726? Apr 08 15:14:47 ulm: https://bugs.gentoo.org/501726 "new GLEP: Gentoo GPG key policies"; Doc Other, New GLEP submissions; IN_P; dilfridge:glep Apr 08 15:14:56 indeed Apr 08 15:15:05 that's it Apr 08 15:15:08 thanks Apr 08 15:15:11 Might not hurt to CC council on bugs like this when it is waiting for us. Apr 08 15:15:17 rich0, ++ Apr 08 15:15:43 okay if there is no more discussion on this, item 2 - Use of ISO/IEC prefixes vs base-10 Apr 08 15:16:14 I see there as two parts to this one - whether we advocate base 2 vs 10, and whether we require unambiguous units. Apr 08 15:16:18 isnt ISO = base10? Apr 08 15:16:22 No Apr 08 15:16:25 dilfridge: no Apr 08 15:16:36 the question here is whether or not we should prefer ISO/IEC prefixes over base 10 especially in check-reqs.eclass Apr 08 15:16:42 IEC/ISO just says to use GiB for base 2, and GB for base 10. Apr 08 15:16:43 * dilfridge confused, but it's not so important Apr 08 15:16:45 rich0: IIRC, you posted two versions of a possible motion Apr 08 15:16:54 do you have a pointer to it? Apr 08 15:16:59 sure Apr 08 15:17:03 http://article.gmane.org/gmane.linux.gentoo.project/3428 Apr 08 15:17:08 http://article.gmane.org/gmane.linux.gentoo.project/3438 Apr 08 15:17:28 (blueness is to thread, my link is to my proposals) Apr 08 15:17:38 rich0, true Apr 08 15:17:52 Both of my proposals require the ISO/IEC units for non-ambiguity. The first suggests base 10 when there isn't a reason to do otherwise. Apr 08 15:18:02 rich0, do you want to lead this discussion then? Apr 08 15:18:03 * NeddySeagoon (~NeddySeag@gentoo/developer/NeddySeagoon) has joined #gentoo-council Apr 08 15:18:29 What are upstreams doing on this these days? Apr 08 15:18:41 Sure. Honestly, I think non-ambiguous units are the most important thing here - GB if base 10, GiB if base 2. I think we should prefer 10, but that gets into religion, and it should always be maintainer-discretion. Apr 08 15:19:14 I think upstreams vary - it is a religous debate. But, the GB vs GiB thing is becoming much more common. I think people recognize the value of clarity. Apr 08 15:19:23 WilliamH, there is no consistency that i can see Apr 08 15:19:34 IMHO the rationale for switching to IEC prefixes in Linux summarises it well: Apr 08 15:19:36 "Best practice in editing a technical or standards document is to (a) avoid ambiguous usages, seek clarity and precision; and (b) to use, follow and reference international standards." Apr 08 15:19:50 I dont particularly like the "i" stuff, but it's good for being precise. Apr 08 15:19:54 so yes. Apr 08 15:20:01 ulm: makes sense to me. Apr 08 15:20:31 (given that in Germany people are filing lawsuits since monitor diagonals are specified in the non-si unit inch) Apr 08 15:20:53 would it be fair to say that the council doesn't care about SI vs ISO/IEC provided we don't have ambiguity Apr 08 15:21:04 so KB means 1000 B and KiB means 1024 Apr 08 15:21:29 I'm all for proposal 1 Apr 08 15:21:29 Well, I feel strongest that we should use the "ibi" units when referring to base 2. I don't feel strongly about base 2 vs 10. Use your favorite units, but be clear. Maintainers have the best insight into what makes the most sense. Apr 08 15:21:35 blueness: that's rich0's proposal 2 Apr 08 15:21:48 ulm, correct, but i'm asking if everyone feels the same Apr 08 15:22:11 but indeed, most important is that it's unambiguos. by a mile. Apr 08 15:22:11 blueness: just to clarify - ISO/IEC specifies both. It isn't about base 2 vs 10. It is about using the right abbreviation for each. Apr 08 15:22:21 I'm happy with both, slight preference for 2 Apr 08 15:22:21 rich0, oh okay Apr 08 15:22:32 Sounds like we have consensus for 2. Do we want to vote on 1 first and see how it goes? Apr 08 15:22:49 can do Apr 08 15:22:50 we can do that ... Apr 08 15:23:01 Proposal 1 Apr 08 15:23:01 "Whenever practical Developers are encouraged to use SI units and base Apr 08 15:23:01 10 values (ie 1KB = 1000 bytes). They may use base 2 values when this Apr 08 15:23:01 output is more likely to be useful to users (eg in memory hexdumps, Apr 08 15:23:01 etc). Either way, unit prefixes defined in IEC 80000-13 (KB, KiB, Apr 08 15:23:02 etc) must be used so that output is unambiguous. This does not Apr 08 15:23:04 require maintainers to patch upstream code to change its behavior, but Apr 08 15:23:06 they should be applied with code that originates in Gentoo." Apr 08 15:23:20 who is in favor of this formulation of the motion ^^^ Apr 08 15:23:40 * blueness no Apr 08 15:23:40 * dilfridge yes Apr 08 15:23:42 * rich0 yes Apr 08 15:23:57 * WilliamH yes -- let's not force maintainers to patch Apr 08 15:24:26 dberkholz, scarabeus ping Apr 08 15:24:30 * ulm abstain Apr 08 15:24:33 I prefer 2 Apr 08 15:24:35 (emphasis on "encouraged") Apr 08 15:24:40 hang on Apr 08 15:24:46 * WilliamH wants to see 2 Apr 08 15:24:51 i preffer 2 Apr 08 15:25:01 * WilliamH retracts vote without seeing 2 Apr 08 15:25:08 i find the ibi units confusing for many people regardless so i'm going to abstain Apr 08 15:25:20 Ok, let me post 2 just so that it is here... Apr 08 15:25:27 Proposal 2 Apr 08 15:25:27 "Whenever practical developers are required to use unit prefixes Apr 08 15:25:27 defined in IEC 80000-13 (KB, KiB, etc) so that output is unambiguous. Apr 08 15:25:27 This does not require maintainers to patch upstream code to change its Apr 08 15:25:27 behavior, but they should be applied with code that originates in Apr 08 15:25:29 Gentoo." Apr 08 15:25:54 it looks to me like proposal 1 failed ... only dilfridge and rich0 said yes Apr 08 15:26:00 WilliamH, changed his minde Apr 08 15:26:10 so let's vote for proposal 2 Apr 08 15:26:15 * blueness yes Apr 08 15:26:16 * rich0 yes to 2 Apr 08 15:26:21 * ulm yes Apr 08 15:26:26 * dilfridge yes to 2 Apr 08 15:26:29 * scarabeus yes Apr 08 15:26:35 * WilliamH yes Apr 08 15:26:50 argh Apr 08 15:26:58 rich0: s/KB/kB/ Apr 08 15:27:09 hehe Apr 08 15:27:15 Yes, thanks Apr 08 15:27:23 KB and mB Apr 08 15:27:31 okay proposal 2 passes Apr 08 15:27:32 It is kB and KiB Apr 08 15:27:32 it's kB MB GB vs KiB MiB GiB Apr 08 15:27:44 not kiB Apr 08 15:27:45 ? Apr 08 15:27:49 nope Apr 08 15:27:49 (A comma between "practical" and "developers" might help reading; I've been reading it as "practical developers", had to backtrack from the end of the sentence to see where I've misread) Apr 08 15:27:58 dilfridge, it is in fact kB and KiB Apr 08 15:28:03 don't ask! Apr 08 15:28:06 ugh, how ugly Apr 08 15:28:06 K is kelvin Apr 08 15:28:07 yes, a comma would help. :) Apr 08 15:28:12 ulm: not mB? Apr 08 15:28:26 ssuominen: that would be millibytes ;) Apr 08 15:28:30 that would be millibyte... :D Apr 08 15:28:30 Let's not mention that in JEDEC it is K for KiB Apr 08 15:28:35 eg temperature of the surface of the sun is 2.5 kK Apr 08 15:28:47 Err, JEDEC is KB for 1024 bytes. :) Apr 08 15:28:55 enough... Apr 08 15:28:56 dilfridge: KB = 1000, KiB = 1024 Apr 08 15:28:57 * dilfridge notes that the council has 3 physicists Apr 08 15:29:02 ulm: dilfridge just mentioned it above ^, got confused. Apr 08 15:29:12 I'm a chemist, not a physicist Apr 08 15:29:21 me, ulm, blueness Apr 08 15:29:26 and i'm a physicist, not a chemist! Apr 08 15:29:34 dberkholz is a biologist or biochemist if I'm not mistaken Apr 08 15:29:39 yikes! Apr 08 15:29:51 thank god there are no comp sci majors here! Apr 08 15:30:03 * WilliamH is a comp sci major lol Apr 08 15:30:13 * WilliamH was actually, lol. Apr 08 15:30:15 WilliamH, we still love you! Apr 08 15:30:32 * WilliamH graduated in 91 so it has been a few years ;-) Apr 08 15:30:37 No wonder we're all indoctrinated in SI. Apr 08 15:31:02 So, on to the main event? Apr 08 15:31:06 okay .... shall we move on to item 3 ... discussion of recent events regarding new virtuals, masking by QA and then unmasking Apr 08 15:31:11 yippi-yey Apr 08 15:31:41 * rich0 finishes tightening the straps on his helmet Apr 08 15:31:51 okay first, let me ask for minimal bikeshedding while the council tries to work thorugh this thorny issue(s) Apr 08 15:31:57 * WilliamH says no for the first point, I don't think this is a policy issue. Apr 08 15:32:15 WilliamH, 1 sec ... let me first see if the 3 items are acceptable Apr 08 15:32:21 I believe that discussing the concrete case in this council meeting wouldn't be wise Apr 08 15:32:22 before comrel and qa have done their part Apr 08 15:32:31 discussing general guidelines for the future is o.k. though Apr 08 15:32:35 so ... i wasn't even sure how to formulate this, so I came up with 3 issues that came forward Apr 08 15:32:37 ulm++ Apr 08 15:33:05 is everyone okay with the 3 issues ... even if you plan to vote no ... Apr 08 15:33:05 I do support ulm that we should focus more on the general / future / policy and less on who did what when last week. Apr 08 15:33:09 do you think i missed any issues Apr 08 15:33:42 rich0, ulm how then do you want to proceed? Apr 08 15:33:46 might I suggest that some of the elements of the proposal seemed non-controversial. Maybe tackle those first? Apr 08 15:34:11 rich0, okay begin by suggesting issue 1 Apr 08 15:34:53 Ugh - digging through the thread... Apr 08 15:35:03 http://article.gmane.org/gmane.linux.gentoo.project/3474 Apr 08 15:35:04 this one? Apr 08 15:35:18 http://thread.gmane.org/gmane.linux.gentoo.project/3412/focus=3417 Apr 08 15:35:24 There we go... Apr 08 15:35:39 dilfridge: ++ Apr 08 15:35:43 * FamousEccles (~roy@gentoo/developer/NeddySeagoon) has joined #gentoo-council Apr 08 15:36:00 How about work from the end back. Apr 08 15:36:03 okay let's drop my 3 issues and look at dilfridge's stuff Apr 08 15:36:13 5) The council encourages teams maintaining central parts of Gentoo to accept Apr 08 15:36:13 new developers as team members and teach them the required knowledge and Apr 08 15:36:13 intricacies. We consider this important to ensure long-term continuity and Apr 08 15:36:14 increase the bus factor in critical areas. Apr 08 15:36:34 okay let's begin there ... discussion regarding this? Apr 08 15:36:43 i don't think that's something we should even need to vote on or write down Apr 08 15:37:06 we're in danger of over documenting what normal behavior should be Apr 08 15:37:07 * WilliamH agrees with dberkholz Apr 08 15:37:07 imho this is fairly non-controversial, a pure recommendation, and something that should be obvious to everyone Apr 08 15:37:08 I like it - not everything has to be a rule. Apr 08 15:37:25 There is nothing for us to do wrt that. Apr 08 15:37:37 by spelling it out, we might just put some emphasis behind it. Apr 08 15:37:38 I think it is a message we can still endorse. Apr 08 15:37:49 It doesn't have to be engraved in the code of Gentoo., Apr 08 15:38:07 dberkholz, i read that as a position the council encourages without it being policy or "written down" Apr 08 15:38:44 dberkholz, i would say, the council should email gentoo-dev@ and "remind" people of this fact Apr 08 15:39:19 I think as leaders it is a message we should try to send. We can't force people to do it, but that doesn't mean it shouldn't be said. Apr 08 15:39:33 can we make an action item of it, i.e. someone (dilfridge?) sends a mail to -dev? Apr 08 15:39:36 so how about we vote on it with the understanding that i will email gentoo-dev@ as an "encouragement" to the community. Apr 08 15:39:44 blueness: ++ Apr 08 15:39:51 ok Apr 08 15:39:58 or dilfridge can speak on behalf of hte committee since he wrote it Apr 08 15:39:58 that's as far as it need go Apr 08 15:40:11 that's all the action it needs from us Apr 08 15:40:25 dilfridge, okay as an action item, you will email that to gentoo-dev@ as an encouragement from the council Apr 08 15:40:35 will do. Apr 08 15:40:36 shall we vote on this? Apr 08 15:40:38 Unless there is more to discuss, maybe just vote and see where we end up? The meat is really in the first item or two. Apr 08 15:40:38 * blueness yes Apr 08 15:40:42 * rich0 yes Apr 08 15:40:44 * dilfridge yes Apr 08 15:40:45 * WilliamH yes Apr 08 15:40:53 * ulm yes Apr 08 15:41:08 * scarabeus yes Apr 08 15:41:10 ok Apr 08 15:41:14 okay! Apr 08 15:41:24 next would be #4 in our countdown Apr 08 15:41:31 4) While it is any developer's choice not to participate on the gentoo-dev and Apr 08 15:41:31 gentoo-project mailing lists, they nevertheless serve as main communication Apr 08 15:41:31 channels. If something has been discussed there, and then action has been Apr 08 15:41:31 taken, the council regards ignorance of the discussion not as a good Apr 08 15:41:31 foundation for protests against the actions. Apr 08 15:41:44 this is a similar "intent" Apr 08 15:41:55 make it part of the other email? Apr 08 15:41:57 ++ from me - there was a lot of debate about the "optionalness" of the lists - Apr 08 15:41:59 I'd suggest we do the same as for 5 Apr 08 15:42:12 action = mailing to list Apr 08 15:42:15 dilfridge++ Apr 08 15:42:19 ++ Apr 08 15:42:22 dilfridge, yes, make it part of the same email Apr 08 15:42:26 sure Apr 08 15:42:27 shall we vote then? Apr 08 15:42:30 sure Apr 08 15:42:32 * blueness yes Apr 08 15:42:32 * dilfridge yes for 4 Apr 08 15:42:36 * rich0 yes for 4 Apr 08 15:42:36 * WilliamH yes for 4 Apr 08 15:42:41 * ulm yes for 4 Apr 08 15:42:55 scarabeus, dberkholz Apr 08 15:43:13 i guess Apr 08 15:43:24 scarabeus, ?? Apr 08 15:43:41 kinda feeling that important discussions should be kicked off with a pointer from -dev-ann Apr 08 15:43:59 ye Apr 08 15:44:00 s Apr 08 15:44:02 dberkholz, sometimes that makes sense Apr 08 15:44:07 dberkholz: ++ Apr 08 15:44:19 okay next ... Apr 08 15:44:20 3) The council believes that a wide announcement and if needed discussion of Apr 08 15:44:20 changes to central parts of Gentoo (as, e.g., system packages, profiles, Apr 08 15:44:20 global use-flags) should be preferred. In particular, only informing "relevant Apr 08 15:44:20 people" makes no sense if others will also be affected. Apr 08 15:44:23 Not sure we need to debate the wording, but that can go in the email. Apr 08 15:44:26 dberkholz: makes sense for really important stuff, but if we do it too often people just get drowned there too. Apr 08 15:44:56 I think the wording of #3 could probably be cleaned up a tad, but I agree with the intent. Apr 08 15:45:01 this one feels different, it is a response to a "relevant person" argument brought forward during the email exchagnes Apr 08 15:45:34 it still is only an intent or advice, though. Apr 08 15:45:46 the devmanual already says "Before introducing a new global USE flag, it must be discussed on the gentoo-dev mailing list." Apr 08 15:46:02 so no need to include use flags again Apr 08 15:46:20 i'd like to discourage the provincalism of "relevant people" ... not just to avoid clicks but so that newbies can come to better understand how gentoo's internals evolve Apr 08 15:46:22 Doesn't hurt to include use-flags just to have one consolidated policy. Apr 08 15:46:54 ulm, let's avoid making htis policy and include this with the previous email ad encouragement Apr 08 15:47:01 rich0: if the policy says "must" and we say "should be preferred" we weaken it Apr 08 15:47:03 Yup, gentoo-dev isn't high-volume compared to some other project dev lists where all kinds of minutae get discussed Apr 08 15:47:15 ulm, fair enough Apr 08 15:47:39 * FamousEccles has quit (Remote host closed the connection) Apr 08 15:47:40 Honestly, my whole feeling on this stuff is that we almost shouldn't have to say any of this, but it still bears saying. Apr 08 15:47:54 ok, take use flags out, same e-mail? Apr 08 15:47:57 It amounts to "act like part of a community" Apr 08 15:48:05 well, as does e.g. 5 Apr 08 15:48:37 okay so do people want this to be added to the email dilfridge will be sending out? Apr 08 15:48:48 Fine with me. Apr 08 15:48:50 Sure, why not. Apr 08 15:49:00 works for me Apr 08 15:49:03 yes, if global use flags are taken out Apr 08 15:49:11 yes without use flags Apr 08 15:49:23 looks like a vote to me ... os i'll add a yes Apr 08 15:49:40 scarabeus, are you in favor? Apr 08 15:50:02 *sigh* Apr 08 15:50:08 let's move one to item 2 Apr 08 15:50:09 3a) The council believes that a wide announcement and if needed Apr 08 15:50:09 discussion of changes to central parts of Gentoo (as, e.g., system Apr 08 15:50:09 packages, profiles) should be preferred. In particular, only informing Apr 08 15:50:09 "relevant people" makes no sense if others will also be affected. Apr 08 15:50:54 2) The council recognizes that there are some open questions around when Apr 08 15:50:55 individuals in QA ought to take action, and how internal disagreements Apr 08 15:50:55 get resolved. The council would like to ask QA to design its own Apr 08 15:50:55 operating procedures and publish them. There should be a reasonably Apr 08 15:50:55 clear process so that QA members can act in the confidence that they are Apr 08 15:50:56 doing things properly, and the rest of the community can be assured that Apr 08 15:50:58 there is accountability. The council requests an update on the progress Apr 08 15:51:00 of establishing procedures prior to its next monthly meeting. Apr 08 15:51:11 okay moving on to item 2 Apr 08 15:51:12 * FamousEccles (~roy@gentoo/developer/NeddySeagoon) has joined #gentoo-council Apr 08 15:51:45 I think creffett has already prepared something for the next qa meeting which is next week Apr 08 15:51:47 (We need to remind ourselves that a primary goal of public awareness is to have more eyes on these important matters; to catch duplication (eg. eclasses), errors (we're human), breakage (something unforeseen). Discussion, bikeshedding and disagreements are side effects; it's kind of like a cost/benefit situation, ...) Apr 08 15:51:57 so no need to remind qa Apr 08 15:52:00 ulm: agree, creffett did address some of this on -dev Apr 08 15:52:26 we can put this on the side and return to it if QA doesn't follow through on what they announced on -dev Apr 08 15:52:39 Maybe we should just note in the summary that we take note that QA is looking to document their proceses? Apr 08 15:52:48 that's good enough Apr 08 15:53:19 blueness: ++ Apr 08 15:53:21 is everyone okay with that ^^^ Apr 08 15:53:25 yea that is nice Apr 08 15:53:29 * WilliamH yes Apr 08 15:53:30 yes, we can always come back if there are still open questions Apr 08 15:53:42 ok fine with me Apr 08 15:53:44 * WilliamH has to abstain if this is a vote Apr 08 15:53:56 let's get back to it next month Apr 08 15:54:00 dberkholz, any feelings on this? Apr 08 15:54:36 WilliamH: you think this is a conflict of interest for qa members? Apr 08 15:54:47 blueness: From QA perspective, we've already have had quite some talk on it in the past, we're already doing things in certain ways, there's the GLEP 48 stating expectations; as I see it we're doing fine, in this case there wasn't a team wide vote based on disagreement because nobody send out a disagreement to the team, but none the less, more discussion will follow (it's on agenda, as well as in our Apr 08 15:54:49 i agree, it's along the lines of what devrel has Apr 08 15:54:50 minds) so I think will work out. Apr 08 15:54:55 now comrel Apr 08 15:55:03 ulm: are we voting? Apr 08 15:55:15 WilliamH: not sure ;) Apr 08 15:55:21 WilliamH, we weren't really voting, i was just asking for feelings Apr 08 15:55:27 For reference on QA - creffett's email: http://article.gmane.org/gmane.linux.gentoo.project/3522 Apr 08 15:55:30 given the impact on other groups, additional transparency into how QA works is of value Apr 08 15:55:32 blueness: Ok, I'm fine with it then. Apr 08 15:56:14 okay unless there are objections and someone wants a vote, i'll just note that the council notes that QA is looking into documenting their process Apr 08 15:56:41 okay let's go onto item 1 Apr 08 15:56:42 1) The council strongly disapproves of any developers unilaterally reverting Apr 08 15:56:42 QA team actions. While the case decision lies with QA and ComRel teams, the Apr 08 15:56:42 council welcomes the idea of immediate sanctions in such a case. An individual Apr 08 15:56:42 developer who disagrees with an action made in the name of QA, whether the Apr 08 15:56:42 action is proper or not, MUST follow the escalation procedures set forth in Apr 08 15:56:42 GLEP 48, and is encouraged to work with QA, ComRel or eventually the council Apr 08 15:56:42 to settle any concerns. The council will follow up on any accusations of QA Apr 08 15:56:42 abuse the same way as on any commit that is in conflict with a QA action. Apr 08 15:57:14 the question here is: is comrel looking into this? Apr 08 15:57:33 I hear they are, but do not have specific knowledge. Apr 08 15:57:50 There is a bug Apr 08 15:58:00 WilliamH, do you have the bug # Apr 08 15:58:10 pinged antarus Apr 08 15:58:16 blueness: I can get it probably, hang on. Apr 08 15:58:19 i like the statement but i don't want to step on comrel's toes Apr 08 15:58:21 didn't we agree that we were to discuss general guidelines only? Apr 08 15:58:33 but not past week's incident Apr 08 15:58:35 right Apr 08 15:58:36 ulm: agree Apr 08 15:58:48 the bug is ONLY on a specific event. Apr 08 15:58:50 ulm, how are these not general guidelines? Apr 08 15:58:52 bug 506156 Apr 08 15:58:52 which is not our scope. Apr 08 15:59:14 what! -> You are not authorized to access bug #506156. Apr 08 15:59:15 I do think we should make it clear that GLEP48 already specifies the proper way to handle disagreements with QA. Apr 08 15:59:15 so how about we clarify somehow that 1) is meant as future guideline. Apr 08 15:59:48 blueness: we can't see devrel bugs if nto devrel Apr 08 15:59:54 I'd strongly advise that we wait for comrel and qa before taking any action in the concrete case Apr 08 15:59:56 blueness: comrel bugs are typicaly restricted to the parties involved Apr 08 16:00:08 what's 506156? i'm not authorized either. Apr 08 16:00:10 if it's escalated to us then it's our turn, but not before Apr 08 16:00:16 I think the "immediate sanctions" sentence is really the one that needs the most care. Apr 08 16:00:17 okay if we can't see that bug, then i don't know if comrel is looking into the matter Apr 08 16:00:43 blueness: That's typical comrel policy, qa and comrel can see it. Apr 08 16:00:44 The rest seems to be general policy. Apr 08 16:00:45 so i feel that dilfridge's item 1 should be included in his email stipulating our position Apr 08 16:01:25 do we want some version of 1 to be included with the email dilfridge will send out? Apr 08 16:01:32 how about the following minor change: Apr 08 16:01:55 "While the case decision lies" -> "While any future case decisions lie" Apr 08 16:02:15 sure Apr 08 16:02:39 again, this is meant to be an encouragement as to how things should go in the future Apr 08 16:02:42 Agree. We should be clear that we're not calling for any "punishment" for a case we haven't even formally heard the facts on. Apr 08 16:03:08 dilfridge "encouraged to work with QA, ComRel or eventually the council" -> "encouraged to work with QA or eventually ComRel or the council" Apr 08 16:03:09 i think everyone looking over what happened realizes that things could have gone so much better Apr 08 16:03:17 and so let's just steer people that way Apr 08 16:03:25 they should start with qa Apr 08 16:03:35 ulm: fine with me, yes. Apr 08 16:03:36 comrel implies that it's a personal matter Apr 08 16:03:56 ulm, good point, it might be a purely technical difference Apr 08 16:04:35 So, cleaned up we have: Apr 08 16:04:36 1) The council strongly disapproves of any developers unilaterally Apr 08 16:04:36 reverting QA team actions. While any future case decisions lie with QA Apr 08 16:04:36 and ComRel teams, the council welcomes the idea of immediate sanctions Apr 08 16:04:36 in such a case. An individual developer who disagrees with an action Apr 08 16:04:36 made in the name of QA, whether the action is proper or not, MUST follow Apr 08 16:04:38 the escalation procedures set forth in GLEP 48, and is encouraged Apr 08 16:04:40 to work with QA, or eventually ComRel or the council to settle any Apr 08 16:04:42 concerns. The council will follow up on any accusations of QA abuse the Apr 08 16:04:44 same way as on any commit that is in conflict with a QA action. Apr 08 16:05:08 looks good to me Apr 08 16:05:13 ok to me Apr 08 16:05:23 LGTM Apr 08 16:05:27 LGTM? Apr 08 16:05:29 lgtm Apr 08 16:05:36 looks good to me = LGTM Apr 08 16:05:38 ah! Apr 08 16:05:40 fine Apr 08 16:05:55 Those ETLAs... Apr 08 16:06:07 okay so it looks like dilfridge will be rolling that into the email as well ... no vote unless someone objects Apr 08 16:06:26 I think we should probably vote on this one. Apr 08 16:06:31 okay Apr 08 16:06:51 vote to include this item (as cleaned up by rich0) for incusion in the email to the community by dilfridge Apr 08 16:06:55 * blueness yes Apr 08 16:06:58 * dilfridge yes Apr 08 16:07:03 * rich0 yes Apr 08 16:07:07 * WilliamH yes Apr 08 16:07:42 ulm, dberkholz scarabeus ping Apr 08 16:07:42 yes Apr 08 16:07:45 yes Apr 08 16:07:47 it's already accepted? Apr 08 16:07:51 brb Apr 08 16:07:59 I abstain, because I'm qa member myself Apr 08 16:08:02 okay Apr 08 16:08:09 i thought we voted above with the fine "P Apr 08 16:08:10 * WilliamH retracts vote for the same reason Apr 08 16:08:31 scarabeus, kinda sorta Apr 08 16:08:38 ulm: +1; this event went too fast from a single QA developer to higher instances, it should be more like talking with everyone and elevating when really necessary: 1) qa dev 2) qa@gentoo.org 3) gentoo-dev ML or comrel (depends on matter) 4) council Apr 08 16:08:46 okay is there any more discussion regarding this issue? Apr 08 16:09:02 TomWij: I fully agree Apr 08 16:09:46 ulm, TomWij whether or not that's true, the council has not, in my opinion, acted heavy handedly Apr 08 16:10:01 so while it came to our attention early, its not like we acted rashly Apr 08 16:10:09 blueness: Just saying that escalation went too fast, not action. Apr 08 16:10:15 and the issue is not over since it is working its way throuh QA and comrel Apr 08 16:10:33 I think ignoring the issue would have been a mistake, because it did go public on the lists Apr 08 16:10:36 TomWij, i'm not sure there was escalation, we noted the event and took a position Apr 08 16:10:43 If it were a private dispute a private resolution would be fine. Apr 08 16:10:49 i'm with rich0 Apr 08 16:11:02 we're "nipping it in the bud" Apr 08 16:11:29 any more discussion Apr 08 16:11:40 regarding this issue Apr 08 16:11:41 eg. rich0's mails address QA, which is good as we can always use improvement; but if nobody that was involved sends a mail to the whole team to vote for a disagreement, QA kind of hasn't had the ability to do anything. Apr 08 16:12:14 TomWij: The council hasn't done anything other than state a position. Apr 08 16:12:27 blueness: There was escalation to ComRel quite early, because things got personal too fast; this happened at night hours in the weekend when QA team was barely around, at the worst possible time... Apr 08 16:12:30 TomWij: creffett plans to discuss how to handle QA disagreements in the next meeting, so I'm content to let you guys hash it out for now. Apr 08 16:12:42 yes creffett does. Apr 08 16:13:00 WilliamH: See above message to blueness, I'm not referring to Council in specific. Apr 08 16:13:28 TomWij, i don't see any problems escalating something to comrel on day 0 Apr 08 16:13:33 that's their job Apr 08 16:13:42 coming to council should be a last resort Apr 08 16:13:57 blueness: Same goes for ComRel as they've stated multiple times. Apr 08 16:13:58 Well, escalating to anybody should only be done when people can't work it out themselves. Apr 08 16:14:01 gentlemen, on a personal note, i'm very happy about how this was handled above ^^^ Apr 08 16:14:23 however, anybody CAN escalate to Comrel on day 0 if they just can't handle it. Anybody can put something on our agenda as well. Apr 08 16:14:29 We're just not the best forum for personal conflict. Apr 08 16:14:35 correct Apr 08 16:14:40 yeah. I'm aware that lots of different things went wrong recently. but that's why this is not on the current issue but more a statement for future issues. Apr 08 16:15:39 rich0: The lead of a project shouldn't be skipped in that day 0 process; but well, I know whom to talk to about this. Thanks. Apr 08 16:15:49 Yup, if all the parties can work out an agreeable solution, fine. The community at large shouldn't get the impression that we just ignore issues. Apr 08 16:16:29 TomWij: I'll send you some thoughts on that by email - just friendly advice. :) Apr 08 16:16:48 friendly with baseball bat? Apr 08 16:16:49 :D Apr 08 16:16:52 okay everyone, it think we can move this back to the email lists Apr 08 16:17:08 I just view this in the sense that as Council we're accountable for fixing things, even if we necessarily aren't the ones to fix them... Apr 08 16:17:16 blueness: ++ Apr 08 16:17:33 rich0: No need, afaik, this is all "written down". Apr 08 16:17:35 TomWij, no one is closing dialog here, so feel free to continue the discussion Apr 08 16:17:55 but we must finish off the meeting (since I really have to pee soon too!) Apr 08 16:18:01 last issue Apr 08 16:18:07 Bugs assigned to Council Apr 08 16:18:14 Bug #503382 - Missing summaries for 20131210, 20140114, and 20140225 council meetings Apr 08 16:18:14 Bug #477030 - Missing summary for 20130611 council meeting Apr 08 16:18:14 Bug #498332 - Dropping stable keywords on m68k, s390, sh Apr 08 16:18:15 blueness: https://bugs.gentoo.org/503382 "Missing summaries for 20131210, 20140114, and 20140225 council meetings"; Doc Other, Project-specific documentation; CONF; ulm:council Apr 08 16:18:16 blueness: https://bugs.gentoo.org/477030 "Missing summary for 20130611 council meeting"; Doc Other, Project-specific documentation; CONF; ulm:council Apr 08 16:18:17 blueness: https://bugs.gentoo.org/498332 "Dropping stable keywords on m68k, s390, sh"; Gentoo Linux, Keywording and Stabilization; CONF; dilfridge:council Apr 08 16:18:20 (blueness: I'm not intending to stall, I was merely pointing out fast escalation; feel free to proceed) Apr 08 16:18:32 anything to do there? Apr 08 16:18:49 sure, write the summaries ;) Apr 08 16:19:01 i have 2 of those 3 summaries written Apr 08 16:19:08 i lost the 3rd one so i am rewriting it Apr 08 16:19:12 yay! dberkholz++ Apr 08 16:19:17 okay Apr 08 16:19:25 progress ;) Apr 08 16:19:33 what about the 20130611 council meeting minutes? Apr 08 16:19:45 * antarus (user97381@gentoo/developer/antarus) has joined #gentoo-council Apr 08 16:19:50 I hath been summoned Apr 08 16:19:55 what can I help you with? Apr 08 16:20:00 blueness: scarabeus wanted to ping betelgeuse Apr 08 16:20:24 antarus: too late :) Apr 08 16:20:36 scarabeus, can you report back for next time to see what we want to do with this one, its been plaguing us since the beginning Apr 08 16:21:03 i pinged, i should be more drastic Apr 08 16:21:09 maybe some posters campain Apr 08 16:21:16 then musical marching band... Apr 08 16:21:21 scarabeus, try your best and we'll decide next time what to do about it Apr 08 16:21:38 shall we move to the open floor? Apr 08 16:21:40 that might be too rad i guess, anyway i shall sent him mail again :P Apr 08 16:22:29 rich0, can you close out the meeting, i really have to go (in a couple of ways) .... sorry guys Apr 08 16:22:45 blueness: sure Apr 08 16:22:48 rich0, thanks Apr 08 16:22:56 open floor then... Apr 08 16:23:05 * creffett|irssi has one Apr 08 16:23:18 creffett|irssi: go ahead Apr 08 16:23:51 I would like the council's opinion on whether a developer ignoring existing ebuild policy is a QA issue or a ComRel issue. Apr 08 16:24:16 sorry to spring this one on you, but it's relevant to what I'm going to be doing with QA team, and it just occurred to me about two hours ago. Apr 08 16:24:27 the first time, it's a qa issue Apr 08 16:24:37 Well, the way I"ve always heard it is it is a technical issue, unless Apr 08 16:24:37 Good question. I've seen this debated before. I've gotten the impression that comrel would prefer QA handle these kinds of issues and that it be an enforcing body as a result. Apr 08 16:24:45 but if he continues after being reminded it will become a comrel issue Apr 08 16:24:53 a dev says "leave my @#$% ebuild alone" Apr 08 16:24:56 rich0: and I, speaking with the lead hat on, would like it to be comrel's problem. Apr 08 16:25:06 since I feel that it's muddying the scope of what QA does Apr 08 16:25:07 aren't you lucky that I am here then! Apr 08 16:25:09 ;p Apr 08 16:25:17 I think Comrel may want a determination from QA as to whether policy was broken or not. Apr 08 16:25:31 I intend to crack down on QA people "flashing the badge" without cause Apr 08 16:25:32 antarus: ++ Apr 08 16:25:34 your thoughts? Apr 08 16:25:37 I'm happy to enforce existing, clear, documented policy Apr 08 16:25:51 (as a comrel issue) Apr 08 16:25:53 w/ 20 Apr 08 16:25:55 bah Apr 08 16:26:18 I like what ulm had to say: we ask them nicely, they ignore us, we pass them to comrel. Apr 08 16:26:55 WilliamH: a dev says because he believe someone is deliberately sabotaging his work with no technical basis, or policy to back it up and says "don't touch my ebuild ever again." with a minor temper :) Apr 08 16:27:41 creffett|irssi: I understand that there may be difficulties in getting new policies adopted Apr 08 16:27:45 Well, I imagine before Comrel gets involved they'd want a formal statement by "QA" and not by an individual member of QA. Apr 08 16:27:47 creffett|irssi: I'm not sure what to do about that Apr 08 16:27:58 ssuominen: At that point, it is still personal, because qa can touch any ebuild in the tree. Apr 08 16:28:00 antarus: I'm not even concerned with adopting new policies at this point Apr 08 16:28:04 rich0: I don't mind making rulings Apr 08 16:28:08 right now I'm concerned with existing policy Apr 08 16:28:16 rich0: Wrt that determination, I believe the problem here is that QA is technical whereas ComRel is personal. Apr 08 16:28:19 rich0: as long as people aren't actually angry when we rule against them ;p Apr 08 16:28:24 TomWij: precisely. Apr 08 16:28:46 the problem as I see it is that qa is happy for comrel to rule, until comrel makes ruling they dislike Apr 08 16:28:47 antarus: people get angry around here? never, as long as you're beating up on somebody else... Apr 08 16:28:56 then suddenly it is an issue Apr 08 16:28:58 I feel that some issues with people flashing the QA badge have been people issues, not technical issues, and so we should not have gotten involved to start with Apr 08 16:29:29 antarus: your decision is your decision Apr 08 16:29:30 Personally I think it is a grey area, and if the policy is that questionable that is why you can appeal to council... Apr 08 16:29:34 I don't care who decides, as long as it is celar, IMHO Apr 08 16:29:37 clear* Apr 08 16:30:16 isn't there a rule in glep 48 for this? Apr 08 16:30:32 Yup Apr 08 16:30:34 "If a particular developer persistently causes breakage, the QA team may request that Comrel re-evaluates that developer's commit rights. Evidence of past breakages will be presented with this request to Comrel." Apr 08 16:30:49 thats sort of a bad rule Apr 08 16:30:52 that's not enough. Apr 08 16:30:54 I'm unlikely to actually suspend people Apr 08 16:31:11 should be last resort, probably Apr 08 16:31:16 it does not actually make clear the distinction between people issues and technical issues Apr 08 16:31:19 in the case of this particular bug Apr 08 16:31:24 I mostly just talked to both parties Apr 08 16:31:35 and described how I thought they should handle the situation Apr 08 16:31:39 no suspensions were involved Apr 08 16:31:51 (I don't find suspensions to be very useful) Apr 08 16:32:42 creffett|irssi: would you liek to discuss that aspect further then? Apr 08 16:32:48 creffett|irssi: what parts do you want to own (if any?) Apr 08 16:33:44 antarus: ...I'm still hashing it out mentally, but roughly speaking, if someone causes actual breakage (dependencies break, ebuilds running rm -rf /, like that), it's in our court Apr 08 16:34:02 * jlec (~jlec@gentoo/developer/jlec) has joined #gentoo-council Apr 08 16:34:09 * jlec (~jlec@gentoo/developer/jlec) has left #gentoo-council Apr 08 16:34:30 if it's just ignoring a policy but not actively breaking stuff (recent udev issue, as far as I could tell, fell into this) it's yours Apr 08 16:35:00 again, still thinking this through, that's why I asked the council what they think Apr 08 16:35:04 ok Apr 08 16:35:33 in the end, it's mostly that qa and comrel come to an agreement among themselves Apr 08 16:35:48 i have a question too, when QA/ComRel stuff is finished Apr 08 16:36:15 dilfridge: I concur, I think creffett|irssi is mostly looking input from others Apr 08 16:36:18 (not a ruling, per se) Apr 08 16:36:20 creffett|irssi: I think I see what you're getting at, communicating to the mailing list feels like ComRel terrain (in the positive sense); but I think that the mask is still our terrain, a bit more technical, and I hope to see a mail to qa@gentoo.org next time we've got a similar case going on. Apr 08 16:36:45 unless the council has other opinions on this, I've got nothing further Apr 08 16:36:59 * antarus also has nothing further Apr 08 16:38:00 rich0? shall we pass to johu's question? Apr 08 16:38:01 Anything else? I'm fine with where you're heading with this - you have to live with it! Apr 08 16:38:09 If not, go ahead johu Apr 08 16:38:53 johu? Apr 08 16:39:32 Ok current situation: proj xml is not allowed anymore, few projects migrated, a lot of missing, a3li from wiki team said to me he dont want to enforce ppl to migrate. who is reponsible to get out of this half migrated state? Apr 08 16:40:15 I suggest we take it to the lists to see if there is any reason not to push, but at some point we should push. Apr 08 16:40:37 Swift made a script to have auto-conversion Apr 08 16:40:53 https://wiki.gentoo.org/wiki/Project:Wiki/Project_Page_Migration_Status Apr 08 16:40:59 this looks still more red than green Apr 08 16:41:17 what's still missing is hosting for text files Apr 08 16:41:25 like council logs Apr 08 16:41:39 create a git repo for logs and done Apr 08 16:41:43 Well, we could still move the proj.xml, right? Apr 08 16:42:00 Council is done, for example. Apr 08 16:42:02 the git repo is actually not such a bad idea, it uses existing infrastructure Apr 08 16:42:16 johu: still there needs to be some nice way for presenting them Apr 08 16:42:20 and even cvs history could be converted Apr 08 16:42:47 ulm: well, right now we just get the bare text display in the browser... same if we link to the raw file in gitweb Apr 08 16:42:51 is the current log still presented in a nice way? :D Apr 08 16:43:26 anyway this is getting into details Apr 08 16:43:30 yup Apr 08 16:43:44 I suggest starting a -project thread about this. Is there a reason we shouldn't just do a final migration? Apr 08 16:43:46 yeah, presumably that's not the main blocker Apr 08 16:44:53 Anything further on this/ Apr 08 16:44:55 ? Apr 08 16:45:00 thanks for your wokr Apr 08 16:45:02 work Apr 08 16:45:16 johu: thanks for brining it up! :) Apr 08 16:45:37 Ok, anything else? Apr 08 16:45:57 i'd prefer to have 'em on the wiki, actually, so they're searchable Apr 08 16:46:05 ++ Apr 08 16:46:12 good point. Apr 08 16:46:25 Ok, sounds like we're done. Next meeting is the 13th I believe, and I'm chairing. Apr 08 16:46:38 * rich0 bangs the gavel Apr 08 16:46:41 dberkholz: what? council logs? Apr 08 16:47:12 yep, logs, summaries, other related text files Apr 08 16:47:15 they're logs, supposed to be static Apr 08 16:47:30 nothing to put into a wiki Apr 08 16:47:31 aren't the text files searchable? Apr 08 16:47:39 i often find myself searching for when something was discussed Apr 08 16:47:43 Summaries maybe in wiki? Apr 08 16:48:29 The trustees kept a log of motions across meetings. Apr 08 16:48:37 yeah, summaries might be there Apr 08 16:48:56 what's the issue with static files in the wiki? Apr 08 16:48:57 but then you'd have to convert the old ones Apr 08 16:49:48 Logs are raw. Seems like work to try to wikify them for what? Apr 08 16:49:50 jmbsvicetto: they wouldn't be static any more if you put the content in a wiki ;-) Apr 08 16:50:21 mark the logs as read-only ? Apr 08 16:50:44 Is that possible? Apr 08 16:50:53 I'm asking ;) Apr 08 16:50:54 jmbsvicetto: another issue is that mediawiki isn't well suited for plain ascii Apr 08 16:51:44 you'll need
blocke everywhere Apr 08 16:51:47 ulm: hmm, old ascii text ? It shouldn't look any worse than the plain txt files looked in the old project pages, no? Apr 08 16:51:48 *blocks Apr 08 16:52:08 ulm: or 
 blocks
Apr 08 16:52:31 	also there are more use cases than just logs
Apr 08 16:52:53 	e.g. text files that should be easy to download
Apr 08 16:53:19 	there's some bug open for it, but I fail to find it
Apr 08 16:54:37 	bug 451074
Apr 08 16:54:38 	https://bugs.gentoo.org/451074 "wiki.gentoo.org doesn't allow upload of plain text files"; Website www.gentoo.org, Wiki; CONF; ulm:wiki
Apr 08 16:55:32 	e.g. in tracwiki one would simply attach the meeting logs to the council page
Apr 08 16:55:42 *	antarus (user97381@gentoo/developer/antarus) has left #gentoo-council
Apr 08 16:55:55 	not possible with mediawiki, you need subpages there, or external hosting