diff options
Diffstat (limited to 'meeting-logs/20140423.txt')
| -rw-r--r-- | meeting-logs/20140423.txt | 289 |
1 files changed, 289 insertions, 0 deletions
diff --git a/meeting-logs/20140423.txt b/meeting-logs/20140423.txt new file mode 100644 index 0000000..74e7912 --- /dev/null +++ b/meeting-logs/20140423.txt @@ -0,0 +1,289 @@ +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
\ No newline at end of file |