2014-04-23 18:33:15 * zlogene is here 2014-04-23 18:33:15 * TomWij is here 2014-04-23 18:33:15 * creffett|irssi here 2014-04-23 18:33:15 @creffett|irssi showtime 2014-04-23 18:33:15 * Tommy[D]_ hides 2014-04-23 18:33:15 * ulm is here 2014-04-23 18:33:15 @creffett|irssi DrEeevil, Pinkbyte, WilliamH, wired, Zero_Chaos: ping 2014-04-23 18:33:15 @wired here 2014-04-23 18:33:15 @wired from mobile xD 2014-04-23 18:33:15 @creffett|irssi 6...a bit light, let's wait a couple minutes in case anyone else shows up 2014-04-23 18:33:15 @creffett|irssi eh, oh well 2014-04-23 18:33:15 @creffett|irssi let's get started 2014-04-23 18:33:15 @creffett|irssi topic 1: hacked pkgconfig files 2014-04-23 18:33:15 @creffett|irssi thoughts on the matter? 2014-04-23 18:33:15 @wired per case, I could think of justified cases 2014-04-23 18:33:15 @Tommy[D]_ uh, that matter is pretty old 2014-04-23 18:33:15 @ulm isn't this just part of the larger picture that our patches should be sent upstream 2014-04-23 18:33:15 @TomWij Upstream where possible, otherwise create one in FILESDIR; I don't think the problem is that bad or complex to justify an eclass, afaik. 2014-04-23 18:33:15 @creffett|irssi you tell me 2014-04-23 18:33:15 @wired ulm++ 2014-04-23 18:33:15 @ulm and yes, it doesn't justify an eclass 2014-04-23 18:33:15 @creffett|irssi ulm: and what about cases where upstream won't take our changes? 2014-04-23 18:33:15 @TomWij And banning, as suggested, kind of keeps the breakage around; I'd rather see us work towards creating (and upstreaming) pkgconfig files. 2014-04-23 18:33:15 @Tommy[D]_ wired: what justified cases do you have in mind? 2014-04-23 18:33:15 @creffett|irssi so...status quo? "We encourge all developers to upstream any changes made to pkgconfig files, just as with any other local changes" 2014-04-23 18:33:15 @wired I don't have a specific example in mind atm, I was thinking that patches should be sent upstream and if they don't accept them but they make our life easier, we can keep em 2014-04-23 18:33:15 @creffett|irssi I do not like banning pkgconfig edits, since I can imagine cases where it would help (and cases where upstream hates us or something and so would just ignore the patches) 2014-04-23 18:33:15 @ulm creffett|irssi: something like that, yes 2014-04-23 18:33:15 @wired +1 2014-04-23 18:33:15 @zlogene дпеь 2014-04-23 18:33:15 @zlogene errr 2014-04-23 18:33:15 @Tommy[D]_ wired: in which case are gentoo-only *.pc files usefull anyway? If those are not upstream, no other package should use it anyway, so only gentoo-specific or -modified packages would use them 2014-04-23 18:33:15 @zlogene lgtm 2014-04-23 18:33:15 @TomWij +1 2014-04-23 18:33:15 @creffett|irssi Tommy[D]_: thoughts on my suggested opinion? 2014-04-23 18:33:15 @Tommy[D]_ creffett|irssi: is this only about modified pkgconfig files or also about creation of those? 2014-04-23 18:33:15 @wired tommy as I said before, I don't have specific examples in mind 2014-04-23 18:33:15 @creffett|irssi Tommy[D]_: if you make one, it should be upstreamed too, so that case falls under these rules 2014-04-23 18:33:15 @creffett|irssi thanks for pointing that out 2014-04-23 18:33:15 @Tommy[D]_ do we have some way to make clear, that a pkgconfig file has been created or modified for gentoo so noone does depend on them? 2014-04-23 18:33:15 @creffett|irssi I don't know, but I'm not sure why someone would take our pkgconfig files instead of upstream's, or not check them carefully if we make one ourselves because upstream doesn't provide one 2014-04-23 18:33:15 @Tommy[D]_ as written in that discussion, if someone with a gentoo system depends on a lib and does see a pkgconfig file installed, he may depend on it, results in failures on all other distros 2014-04-23 18:33:15 @TomWij Tommy[D]_: I'd think they should depend on it and even upstream it, having other upstreams push the one upstream to create a pkgconfig file. 2014-04-23 18:33:15 @Tommy[D]_ maybe some short ewarn line about "pkgconfig file is custom/gentoo-only" if it does not get upstream and continues to exist in gentoo? 2014-04-23 18:33:15 @creffett|irssi Tommy[D]_: that's...kind of stupid, to not verify whether something actually provides a pkgconfig file upstream 2014-04-23 18:33:15 @creffett|irssi doubt people would see, notice, or care 2014-04-23 18:33:15 @creffett|irssi uh, can we suggest putting comments in locally created/modified pkgconfig files? (I assume those support comments, at least) 2014-04-23 18:33:15 @Tommy[D]_ creffett|irssi: uhm, no, i dont call it stupid, i expect gentoo to install upstream content, so without any hint or notice i expect the installed content to be from upstream 2014-04-23 18:33:15 @TomWij Tommy[D]_: You often would look for it after packages have been installed; so, instead of the ewarn, you might as well look into the FILESDIR or patches tarball. 2014-04-23 18:33:15 @creffett|irssi Tommy[D]_: the issue is that I really think it's excessive to warn for every custom/patched Gentoo file 2014-04-23 18:33:15 @Tommy[D]_ creffett|irssi: i dont talk about warning for every file, but something like pkgconfig files, which dont exist in this form upstream/for other distros is imho an important detail 2014-04-23 18:33:15 @TomWij A comment could work theoretically; but in practice, I don't see this consistently be done. Unless we grep FILESDIR and check those that don't have a comment yet. Furthermore, even with comments in them; would other maintainers read the pkgconfig contents of other packages when considering to use it? 2014-04-23 18:33:15 @creffett|irssi well, an ewarn is frankly useless; most ewarns/elogs/etc. are ignored, and the person would need to be (re)installing it when making their new package dep on the pkgconfig file to actually see it 2014-04-23 18:33:15 @Tommy[D]_ it is afaik the only way to even get a message out 2014-04-23 18:33:15 @creffett|irssi I don't see why we're obligated to get a message out 2014-04-23 18:33:15 @creffett|irssi also, while we're arguing, could I get a volunteer to take notes on the meeting? 2014-04-23 18:33:15 @TomWij creffett|irssi: Already making a summary here. 2014-04-23 18:33:15 @Tommy[D]_ hm, would initially also be a hassle to change, but suggest some gentoo-*.pc naming for those pkgconfig files, which cannot be upstreamed? 2014-04-23 18:33:15 @creffett|irssi TomWij: thank you 2014-04-23 18:33:15 @creffett|irssi Tommy[D]_: I don't know a ton about .pc files, would naming them that way cause any problems? 2014-04-23 18:33:15 @Tommy[D]_ if it is done consistantly, one would have to do the pkgconfig calls with this gentoo prefix, which should make it pretty obvious, that it is gentoo-only 2014-04-23 18:33:24 @Tommy[D]_ but it was just a quick idea to avoid the issues mentioned in that discussion from 2 years ago 2014-04-23 18:33:41 @creffett|irssi yes, but then this requires more work to make sure that everything calls it with the gentoo- prefix 2014-04-23 18:34:10 @Tommy[D]_ well, if gentoo creates it, only gentoo could use it, so we control everything calling it, no? 2014-04-23 18:34:13 @TomWij Tommy[D]_: I like the naming idea, should work out well in terms of visibility; only one wonder, what do you do once it eventually does arrive upstream, how do you migrate away from the gentoo- prefix version? 2014-04-23 18:34:56 @TomWij Hmm, maybe... Break it locally and test whether rev deps still configure? 2014-04-23 18:35:11 -- Mode #gentoo-qa [+nt] 2014-04-23 18:35:11 -- Channel created on Sun, 26 Nov 2006 07:42:47 2014-04-23 18:35:23 @creffett|irssi Tommy[D]_: yes, I guess so 2014-04-23 18:35:23 @Tommy[D]_ TomWij: either include it for some time after upstream added a pkgconfig file (transition period) or bump/stable matching versions at the same time 2014-04-23 18:35:39 @creffett|irssi how much work would it be to migrate everything to using gentoo-*.pc files? 2014-04-23 18:35:41 @TomWij Yeah, multiple options; should work out. 2014-04-23 18:36:39 @Tommy[D]_ How about encourage upstreaming pkgconfig files now and adding a topic on -dev ML about the gentoo-prefix for those, which are not accepted? 2014-04-23 18:36:49 @creffett|irssi +1 2014-04-23 18:36:56 @TomWij +1 2014-04-23 18:37:03 @ulm +1 2014-04-23 18:37:03 @wired +1 2014-04-23 18:37:07 @zlogene ++ 2014-04-23 18:37:49 @creffett|irssi okay, sold. 2014-04-23 18:38:11 @creffett|irssi next topic: "Are there unclarities wrt what "QA team" and similar things mean in GLEP 48? An individual or the whole team? With agreement or not?" 2014-04-23 18:38:41 @creffett|irssi did we cover this sufficiently last time, or is there more to go over? 2014-04-23 18:40:51 @Tommy[D]_ can you write for clarity, what in your view was covered last time? 2014-04-23 18:41:29 @creffett|irssi if I had a summary, I would remember what we covered 2014-04-23 18:41:36 @creffett|irssi (in other words: I am blanking right now) 2014-04-23 18:41:55 @zlogene creffett|irssi, http://article.gmane.org/gmane.linux.gentoo.project/3509 2014-04-23 18:42:42 @TomWij What we have voted on last time should help, that is the order in which we elevate a disagreement; I think that going forward, we can assume that in case of disagreement "QA team" means a vote by the entire team unless otherwise noted or implied by another GLEP 48 compliant policy we have formed. 2014-04-23 18:42:51 @creffett|irssi we agreed on the order of action for undoing (dev does action, deputy/lead may revert action unilaterally but take the consequences, team vote overrides that) 2014-04-23 18:42:54 @creffett|irssi yes 2014-04-23 18:43:05 @TomWij The idea with this agenda item is that the GLEP 48 should be sufficiently clear to most people; and if not, we'd need to suggest a change to the Council. 2014-04-23 18:43:14 @wired I'm happy with that 2014-04-23 18:43:43 * creffett|irssi running to next class, please discuss if we need to clearly indicate any parts of the GLEP which are "any team member" vs "team must agree" 2014-04-23 18:44:21 @Tommy[D]_ so "QA team" is every member unless there is a disagreement, if the lead takes over, he takes over the term, if we vote, the voters become "QA team"? 2014-04-23 18:45:31 @ulm fine with me 2014-04-23 18:45:39 @zlogene fine 2014-04-23 18:45:39 @wired ++ 2014-04-23 18:46:18 @ulm might still be wise to follow a four-eyes principle for matters that could be controversial 2014-04-23 18:46:41 @TomWij Tommy[D]_: So; that means that in case of disagreement, we go further with the statement (the escalation order [member, deputy, lead, team vote]) we've agreed on last week. 2014-04-23 18:47:04 @Tommy[D]_ TomWij: that is my suggestion 2014-04-23 18:47:17 @wired ulm I would consider this best practice whenever possible 2014-04-23 18:47:26 @TomWij Ah, I see now; yes. 2014-04-23 18:47:54 @TomWij +1 then 2014-04-23 18:47:56 @Pinkbyte Hi guys, i am late, sorry 2014-04-23 18:48:33 @zlogene hello 2014-04-23 18:49:13 @Tommy[D]_ Pinkbyte: you just missed one topic, so your opinion on the clarification of the term "QA team"? 2014-04-23 18:49:54 * Pinkbyte looking at backlog of bouncer 2014-04-23 18:50:10 @Pinkbyte +1 from me too 2014-04-23 18:51:01 @TomWij Pinkbyte: Feel free to vote on "Encourage upstreaming pkgconfig files now and add a topic on -dev ML about prefixing pkgconfig files with gentoo- (eg. gentoo-${PN}.pn), which are not accepted." 2014-04-23 18:52:15 @Pinkbyte to be honestly, i think that downstream pkgconfig files should be banned at all 2014-04-23 18:52:32 @Pinkbyte i mean, if they are added by downstream 2014-04-23 18:53:21 @Pinkbyte modification is a different point, but adding non-existant pkgconfig file will confuse software developers that use Gentoo. Not sure about prefixing stuff though 2014-04-23 18:54:43 * creffett|irssi back 2014-04-23 18:54:48 @creffett|irssi hello Pinkbyte 2014-04-23 18:54:57 @Tommy[D]_ thats why i suggested a gentoo-prefix for those, which are not accepted by upstream, so software developers dont get confused 2014-04-23 18:55:55 @creffett|irssi ulm, Tommy[D]_, etc.: concur, with recommendation that issues which the developer expects to be controversial should always be discussed with a couple other developers before action 2014-04-23 18:56:11 @creffett|irssi (so strongly recommend the four-eyes principle, basically) 2014-04-23 18:56:13 @Pinkbyte Yeah, so, my conclusion: allow adding only prefixed pkgconfig files and trivial modification(like libdir fixes or other such stuff) for non-prefixed ones 2014-04-23 18:57:31 @creffett|irssi Pinkbyte: well, let's start with recommending upstreaming and starting an RFC on prefixing 2014-04-23 18:57:34 @creffett|irssi since that's going to break stuff 2014-04-23 18:58:26 @TomWij Currently I've listed Pinkbyte's vote on the first one as abstain, as he wants a different / more strong vote; do we want to revise the statement and/or votes, or stay with our decision and look into the situation at a future meeting? 2014-04-23 18:59:13 * creffett|irssi stands by "proceed as discussed, RFC for prefixing" 2014-04-23 18:59:17 @TomWij But yeah, the prefixing needs some docs; might as well create a general doc on pkgconfig while we're at it. 2014-04-23 18:59:20 @creffett|irssi since I expect stuff to break 2014-04-23 18:59:22 * TomWij agrees with creffett. 2014-04-23 19:00:42 @wired me 2 2014-04-23 19:01:38 @Tommy[D]_ Pinkbyte: are you ok with an RFC on the -dev ML first? If it gets accepted, we can then make the prefix a policy (keep in mind, it was a quick idea from me, did not check all consequences yet) 2014-04-23 19:02:34 @Pinkbyte Tommy[D]_, sure, sounds good 2014-04-23 19:02:50 @Pinkbyte we need wider discussion with a lot of bikeshedding ;-) 2014-04-23 19:03:55 @creffett|irssi k, next topic 2014-04-23 19:04:01 @creffett|irssi "Move QA policies to the devmanual" 2014-04-23 19:04:05 @creffett|irssi input? 2014-04-23 19:04:05 @TomWij And for creffett I've listed the second vote as agreeing with the motion (duo to "concur"), do we want to add his recommendation? "issues which the developer expects to be controversial should always be discussed with a couple other developers before action"? 2014-04-23 19:04:20 @wired I like the devmanual idea 2014-04-23 19:05:39 @Pinkbyte Me too. It will help new developers, who may lost finding documentation in dozen different places 2014-04-23 19:05:59 @ulm can we even distinguish between "qa policy" and "general policy"? 2014-04-23 19:06:20 @TomWij I like the devmanual idea; more generic, I like all non-specific (!= GNOME / KDE specific details) information for developers to be in one convenient place. 2014-04-23 19:07:08 @Pinkbyte ulm, i think not. All "general policies" are usually established for QA sake 2014-04-23 19:07:28 @creffett|irssi well, QA team internal policy stays on the wiki 2014-04-23 19:07:30 @creffett|irssi of course 2014-04-23 19:07:51 @TomWij Yes, internal should still be separate. 2014-04-23 19:07:54 @ulm sure 2014-04-23 19:08:02 @zlogene just to clarify, what sort of policy want we move? 2014-04-23 19:08:08 @creffett|irssi and I think that specific stuff should stay on the wiki (such as the gtk situation), whereas more general policy (say, on versioning USE flags) would go to devmanual 2014-04-23 19:08:47 @wired ++ 2014-04-23 19:08:55 @Tommy[D]_ how to distinguish, what should stay in qa wiki and what should go into devmanual? Also, if things go into devmanual, should it get a seperate chapter for "qa rules to follow"? 2014-04-23 19:09:04 @TomWij "Move general recommendations, guidelines and policies for Gentoo Developers to the devmanual" 2014-04-23 19:09:48 @TomWij Tommy[D]_: Just categorize it where it fits, I think we'll want to avoid a dry list of QA rules to follow. 2014-04-23 19:09:49 @ulm Tommy[D]_: things should go to the section of the devmanual that is relevant 2014-04-23 19:10:02 @wired actually, all policies should be in the devmanual, except from internal qa team policies 2014-04-23 19:10:39 @creffett|irssi wired: yes, but some of the decisions are specific enough to not really belong in devmanual 2014-04-23 19:10:55 @creffett|irssi so, any objections to moving stuff to devmanual? /me in favor of moving some stuff 2014-04-23 19:11:00 @wired well, even the gtk thing is important enough 2014-04-23 19:11:31 @TomWij Wait, to avoid confusion: Are we suggesting the statement we're forming to be an internal QA policy or affect anyone? 2014-04-23 19:11:31 @wired I would want devs adding new gtk ebuilds to be aware of that policy 2014-04-23 19:11:56 @TomWij (Iotw, is our goal to move the policies we make to the devmanual or do we want all non-specific pollicies to go to the devmanual?) 2014-04-23 19:13:00 @creffett|irssi TomWij: well, both I guess, but the question before us is "should QA team move" not "should everybody move" 2014-04-23 19:13:10 @zlogene creffett|irssi, +1, it will useful for new developers 2014-04-23 19:13:11 @wired one place for everything for the developer is my thought 2014-04-23 19:13:47 @Tommy[D]_ So question is "Should qa team move everything except internal policies to devmanual?"? 2014-04-23 19:14:20 @wired ++ 2014-04-23 19:14:25 @ulm I think devmanual maintainers will also have a say ;) 2014-04-23 19:14:37 @creffett|irssi ulm: we administratively own devmanual, if nothing else 2014-04-23 19:14:38 @creffett|irssi :P 2014-04-23 19:15:13 @Pinkbyte creffett|irssi, that's where evil laughing should be heard 2014-04-23 19:15:15 @Pinkbyte :-D 2014-04-23 19:15:31 @creffett|irssi we will MAKE THEM follow our demands! muahahaha. 2014-04-23 19:15:32 @creffett|irssi no. 2014-04-23 19:15:33 @wired lol 2014-04-23 19:15:48 @creffett|irssi that said, I don't think hwoarang will have too many issues with us moving stuff 2014-04-23 19:16:10 @wired I'll take care of him 2014-04-23 19:16:16 @wired harhar 2014-04-23 19:16:19 @creffett|irssi so, votes for "QA team to move everything except internal policies to devmanual"? 2014-04-23 19:16:28 @wired +1 2014-04-23 19:16:31 * creffett|irssi yes, though the more specific policies will take work to move to devmanual 2014-04-23 19:16:34 @zlogene +1 2014-04-23 19:16:34 @ulm +1 2014-04-23 19:16:38 @Tommy[D]_ yes 2014-04-23 19:16:49 @Pinkbyte +1 from me 2014-04-23 19:16:56 @TomWij Well, you (creffett and ulm) both are members; hwoarang has already stated something along the lines that he doesn't mind if it is formed and reviewed policy, hwoarang also is busy these days, the history of our changes can be tracked and reviewed as well, I don't think this forms a problem. And if it does, we'll hear about it... 2014-04-23 19:17:06 @creffett|irssi TomWij: vote? 2014-04-23 19:17:15 @TomWij creffett|irssi: I'm not so sure what "everything" means. 2014-04-23 19:17:30 @creffett|irssi anything on the policies page that is not marked "QA team policy" 2014-04-23 19:17:38 @TomWij eg. I don't want to force GNOME team policies to go there. 2014-04-23 19:17:50 @TomWij If it's limited to our non-internal QA made policies; then: 2014-04-23 19:17:53 @TomWij +1 from me 2014-04-23 19:18:01 @creffett|irssi kk, passes 2014-04-23 19:18:46 @creffett|irssi can I get a couple volunteers to start prepping changes for devmanual? (you can push yourself, though I'd suggest the first couple changes go through github pull requests just to make sure they're formatted right and stuff) 2014-04-23 19:19:56 @wired I volunteer, God help 2014-04-23 19:19:59 @wired me 2014-04-23 19:20:03 @wired he he 2014-04-23 19:20:20 @wired we should discuss the proper places by email first though 2014-04-23 19:20:33 @ulm creffett|irssi: should be filed as bugs, not pull requests 2014-04-23 19:21:05 @creffett|irssi ulm: why not? we have github for a reason 2014-04-23 19:21:20 * ulm won't use non-free software for gentoo development 2014-04-23 19:21:36 @Tommy[D]_ sorry, plan to get a recruit on board, takes enough time for now 2014-04-23 19:22:11 @TomWij I don't care where, as long as we know about the place and it is tracked; eg. pull requests are one way, but if you do it through bugs then mention the bug number in the commit message. Also point out when and where we decided on a certain policy in the commit message or bug. 2014-04-23 19:22:34 @creffett|irssi ulm: okay then 2014-04-23 19:22:35 @TomWij (s/or bug/or bug or pull request/) 2014-04-23 19:22:44 @creffett|irssi ulm: you're welcome to use bugzie, then 2014-04-23 19:23:06 @creffett|irssi wired: thank you for volunteering 2014-04-23 19:23:59 @TomWij ulm: Is devmanual.gentoo.org mirrored elsewhere than GitHub? 2014-04-23 19:24:08 @ulm creffett|irssi: I won't object others using github, but if you want me to volunteer then don't make github a requirement :p 2014-04-23 19:24:41 @ulm TomWij: it's hosted on git.overlays.gentoo.org 2014-04-23 19:24:42 * TomWij isn't sure if devmanual.gentoo.org on GitHub is a mirror af a Gentoo repository or whether it is the only place. 2014-04-23 19:25:03 @creffett|irssi ulm: it's not a requirement, just a suggestion 2014-04-23 19:25:09 @creffett|irssi TomWij: it's a mirror of a gentoo repo 2014-04-23 19:25:14 @creffett|irssi devmanual.git 2014-04-23 19:25:14 @ulm http://git.overlays.gentoo.org/gitweb/?p=proj/devmanual.git;a=summary 2014-04-23 19:25:21 @creffett|irssi any dev may push to it iirc 2014-04-23 19:25:29 @wired hopefully others will volunteer as well?? xD 2014-04-23 19:25:41 @creffett|irssi wired: you may also enlist non-QA devs as your minions 2014-04-23 19:25:43 @ulm wired: sure, I do 2014-04-23 19:26:06 @TomWij Thanks, I've used pull requests in the past; but reasonably, we're working with a team here that needs to review it and everyone needs to get a mail from it so we might opt to solely do this on Bugzilla instead of either. 2014-04-23 19:26:11 @wired ++ 2014-04-23 19:27:45 @creffett|irssi all right, you all may sort that out 2014-04-23 19:27:54 @creffett|irssi last topic: documenting QA policy/workflow 2014-04-23 19:28:01 @creffett|irssi we've covered some of that today 2014-04-23 19:28:10 @creffett|irssi what else do we do that's not really documented? 2014-04-23 19:29:06 @TomWij creffett|irssi: We could document how developers can approach and await the QA team. 2014-04-23 19:30:13 @creffett|irssi okay 2014-04-23 19:30:14 @TomWij eg. Do they file a bug? Do they mail us? Is both fine? When they've mailed, what kind of answer should they wait for (single member, team vote, next meeting summary, ...)? What things can and can't QA be contacted for? 2014-04-23 19:30:38 @zlogene first part *where?* 2014-04-23 19:31:35 @creffett|irssi well, item 1: they need to tell us what they want, and do so clearly 2014-04-23 19:31:55 @creffett|irssi there have been a lot of bugs where QA gets CC'd and nobody says exactly what they want us to decide on 2014-04-23 19:32:06 @Pinkbyte Filing a bug seems a best bet IMO. Easier to keep track of things.] 2014-04-23 19:32:10 @Pinkbyte creffett|irssi, ++ 2014-04-23 19:32:23 @TomWij On the Gentoo Wiki, one or two visible links ("How to raise an issue for the QA team?" and "What kind of issues can I bring to the QA team?") 2014-04-23 19:32:29 @creffett|irssi to get on the meeting agenda, they just need to email us/ping us and say "Here is the situation, please decide if this is good or bad" 2014-04-23 19:32:36 @creffett|irssi or something like that 2014-04-23 19:32:37 @TomWij (Or perhaps throw these questions into a FAQ) 2014-04-23 19:32:52 @creffett|irssi what kind of issues, now that's a different story 2014-04-23 19:32:56 @creffett|irssi "does this violate policy" 2014-04-23 19:33:04 @creffett|irssi "should there be a policy against this" 2014-04-23 19:33:41 @creffett|irssi what I would like to try to avoid is the more blatant examples of people trying to use the QA hammer against someone else 2014-04-23 19:33:47 @creffett|irssi so...more input, please 2014-04-23 19:35:06 @TomWij creffett|irssi: The last question (wrt kind of issues) we need to clarify we don't want ComRel matters (existing policy breakage) and that we don't want matters that should be discussed in public first (otherwise we need to make it public under our name), etc... 2014-04-23 19:35:14 @Tommy[D]_ well, hard to list everything not to bring to qa, so just decide on it case by case? 2014-04-23 19:35:32 @creffett|irssi yes 2014-04-23 19:35:52 @creffett|irssi but it would still be helpful to suggest stuff we do want and stuff we don't want 2014-04-23 19:36:49 @Tommy[D]_ "dont bring comrel issues to qa" sounds like "dont bring kde bump requests to qa" ... to obvious to me 2014-04-23 19:37:00 @Pinkbyte Tommy[D]_, but needed 2014-04-23 19:37:08 @Pinkbyte i made such mistake... well... today :-) 2014-04-23 19:37:26 @TomWij Tommy[D]_: Not mention it like that in the literal way; but for the less obvious cases, like how we were CCed today. 2014-04-23 19:37:39 @Pinkbyte i am sure, other devs(read non qa team members) can do this too 2014-04-23 19:37:54 @Pinkbyte s/can/could/ 2014-04-23 19:38:03 @Pinkbyte and we do not want this 2014-04-23 19:38:04 @TomWij So, more like "if it a lack of communication or breaks existing policy, consider ComRel instead"; less like "we don't take ComRel issues". 2014-04-23 19:38:31 @creffett|irssi yes 2014-04-23 19:38:39 @Tommy[D]_ well, for the first, comrel will say "then communicate" :) 2014-04-23 19:38:55 antarus "now kiss" 2014-04-23 19:39:30 @TomWij Right; more like "consider communicating with the community or people involved first, then escalate to ComRel when really necessary", might even drop everything after the comma. 2014-04-23 19:39:31 @Tommy[D]_ antarus: you dont have to write your private activities in public :) 2014-04-23 19:40:33 @TomWij Or we just add "...; if not, then kiss." there as a side joke. :D 2014-04-23 19:40:38 @Pinkbyte antarus, is this your suggestion as a ComRel lead? :-) 2014-04-23 19:40:47 antarus no 2014-04-23 19:42:54 @Tommy[D]_ the question is, how to divide? if to people/groups argue about a technical detail, the techical part may well be qa area while personal attacks may become comrel area 2014-04-23 19:43:03 @Tommy[D]_ *two people/groups 2014-04-23 19:43:12 antarus I really haven't posted my manifesto 2014-04-23 19:43:15 antarus so sorry about that 2014-04-23 19:43:21 @TomWij creffett|irssi: So, moving towards a statement; I think we can work towards creating one or two Wiki pages (perhaps a FAQ if it fits that format better). Those would then contain how to reach QA (a bug with clear information), as well as examples of what to (and what not to) contact QA with. 2014-04-23 19:44:01 @TomWij As for whether the pages are in the right place and what on them is right or wrong, we can still work that out outside the meeting (or when there are disagreements, sort it out further at a future meeting). 2014-04-23 19:44:43 @Tommy[D]_ fine with me 2014-04-23 19:45:16 @TomWij Tommy[D]_: At that point there has been a discussion; which works out better than receiving a mail from someone who doesn't want to discuss, as a result we don't know the viewpoints the community would have on the matter at hand. 2014-04-23 19:46:06 @creffett|irssi TomWij: ++, let's go FAQ 2014-04-23 19:46:26 @creffett|irssi there's space for one on the main QA page already, we can start there 2014-04-23 19:48:18 @TomWij Pinkbyte, Tommy[D]_ wired, ulm, zlogene: Your vote on the statement of two messages sent in response to creffett|irssi above? Or do you want to propose an alternative statement? More discussion? 2014-04-23 19:49:02 @wired I like it 2014-04-23 19:49:18 @Pinkbyte +1 from me 2014-04-23 19:49:20 @zlogene fine for me 2014-04-23 19:49:32 @Tommy[D]_ TomWij: i already responded to your "moving towards a statement" part 2014-04-23 19:49:32 @ulm fine with me too 2014-04-23 19:49:56 @TomWij Tommy[D]_: Heh, sorry; I figured out I'm missing out on myself instead of you. :D 2014-04-23 19:50:31 @TomWij 7 for, 0 against, 0 abstain, 3 absent. Motion passed. 2014-04-23 19:50:35 @creffett|irssi okay 2014-04-23 19:50:39 @creffett|irssi anything else for today? 2014-04-23 19:50:51 @wired just short of 2h 2014-04-23 19:50:56 @wired nice 2014-04-23 19:51:23 @creffett|irssi mhm 2014-04-23 19:51:37 @creffett|irssi speak now or forever hold your peace 2014-04-23 19:51:45 @creffett|irssi ...until next meeting, at least 2014-04-23 19:52:19 @zlogene Pinkbyte, what sutation with your suggestion for tinderbox? 2014-04-23 19:52:23 @Tommy[D]_ nothing else from me for now 2014-04-23 19:52:50 @Pinkbyte zlogene, nothing changes - only can gave hardware resources for it 2014-04-23 19:53:07 @zlogene okay 2014-04-23 19:53:46 @TomWij Meeting summary available at https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Summaries#Summary_of_Wednesday_April_23.2C_2014 2014-04-23 19:54:08 @creffett|irssi TomWij++ 2014-04-23 19:54:12 * creffett|irssi bangs the gavel 2014-04-23 19:54:18 @creffett|irssi meeting adjourned, thank you all for coming 2014-04-23 19:54:31 @wired woot 2014-04-23 19:54:33 @wired thanks