diff options
authorUlrich Müller <>2015-04-13 19:17:16 +0200
committerUlrich Müller <>2015-04-13 19:17:16 +0200
commit9d5824b5147a8c97cdcccc292e036237d5b9718b (patch)
Import QA team meeting logs.
7 files changed, 3201 insertions, 0 deletions
diff --git a/meeting-logs/20140219.txt b/meeting-logs/20140219.txt
new file mode 100644
index 0000000..ed8d3b2
--- /dev/null
+++ b/meeting-logs/20140219.txt
@@ -0,0 +1,628 @@
+2014-02-19 19:55:24 * TomWij opens up the door, toggles the light switch, brings the sandwiches and coffee in, puts the agenda copies on the table, wipes the whiteboard and opens the window for some fresh air.
+2014-02-19 19:59:35 * zlogene is here
+2014-02-19 20:00:28 * Pinkbyte is almost ready, making himself a coffee
+2014-02-19 20:00:48 * wired here as well
+2014-02-19 20:01:17 @creffett let's get this show on the road, then
+2014-02-19 20:01:43 @creffett DrEeevil, Tommy[D], ulm, WilliamH, Zero_Chaos: ping, time for meeting
+2014-02-19 20:01:55 @ulm here
+2014-02-19 20:02:01 @Tommy[D] TomWij: you have the agenda? I want to see it too :)
+2014-02-19 20:02:50 * creffett waits a couple more minutes in case anyone else is showing up
+2014-02-19 20:02:58 @TomWij Tommy[D]:
+2014-02-19 20:04:02 @Tommy[D] looks pretty empty :)
+2014-02-19 20:04:44 @creffett then we might not have a 2.5 hour meeting this time
+2014-02-19 20:04:49 @creffett and that's quite all right with me
+2014-02-19 20:05:04 * creffett bangs his gavel
+2014-02-19 20:05:19 @creffett okay, let's get going, 7/10 is sufficient for a meeting
+2014-02-19 20:05:48 @creffett first up: deprecating/banning EAPIs, this is also going before the council next Tuesday but we might as well have a recommendation
+2014-02-19 20:06:29 @creffett I'm in favor of "ban 1/2, deprecate 0/3" myself
+2014-02-19 20:06:38 @ulm have all of you seen dilfridge's graphs?
+2014-02-19 20:06:43 @creffett I haven't, got a link
+2014-02-19 20:06:57 @zlogene ulm: it is ready?
+2014-02-19 20:06:57 @creffett ?
+2014-02-19 20:06:58 @ulm
+2014-02-19 20:07:37 @creffett interesting
+2014-02-19 20:07:43 @ulm it's showing approximately exponential decay for old eapis
+2014-02-19 20:07:59 @ulm with a time constant of about 3 years
+2014-02-19 20:08:08 @Pinkbyte EAPI 5 beats EAPI 4 - yes, total win!
+2014-02-19 20:08:19 @zlogene :D
+2014-02-19 20:08:21 @TomWij On the last one EAPI 4 goes down, but then goes flat again; odd.
+2014-02-19 20:08:32 @ulm the council's deprecation of eapis 1 and 2 had no visible influence
+2014-02-19 20:08:36 @Tommy[D] creffett: you want to ban EAPI-2, also it has still thousands of ebuilds using it? sounds way too early to me
+2014-02-19 20:08:56 @creffett Tommy[D]: 2 has already been deprecated by the council
+2014-02-19 20:09:05 @creffett this just forces people to actually make the change instead of ignoring repoman
+2014-02-19 20:09:09 @Tommy[D] creffett: deprecation and baning are 2 different things
+2014-02-19 20:09:15 @ulm it should be clear what a ban means
+2014-02-19 20:09:20 @Tommy[D] creffett: you know you cannot force people on doing something?
+2014-02-19 20:09:25 @TomWij But yeah, I agree we should suggest something along the line ban 1/2 and deprecate 0/3.
+2014-02-19 20:09:27 @zlogene i think we can ban EAPI=1 anyway
+2014-02-19 20:09:29 @ulm does updating an ebuild count?
+2014-02-19 20:09:29 @Pinkbyte Tommy[D], well, it affects only new ebuilds. I think that ADDING new ebuilds with EAPI=2 is weird
+2014-02-19 20:09:30 @wired ban it, if a dev is in a rush they can speedbump to eapi 3
+2014-02-19 20:10:12 @creffett ulm: I believe updating an ebuild will trigger a ban warning
+2014-02-19 20:10:16 @Tommy[D] Pinkbyte: well, if i only read "ban 1/2", then i dont see your "for adding ebuilds" there ;)
+2014-02-19 20:10:23 @Pinkbyte Tommy[D], and upping from 2 to 3 is super easy. 4 and 5 may be tough ones, cause many changes happen
+2014-02-19 20:10:23 @TomWij Tommy[D] (and others): Banning itself is a bit ambiguous, we want to make clear what this means where we compare between an 1) in-place change (eg. DESCRIPTION), 2) rev bump and 3) new ebuild.
+2014-02-19 20:10:35 @creffett but really, if you're updating an ebuild, it's a minute or two more to change the EAPI
+2014-02-19 20:10:57 @TomWij Unless we really want to mean that none of those three is permitted.
+2014-02-19 20:10:59 @creffett and for most cases, you don't need to actually change the ebuild, unless you're using a function which was banned in a later EAPI
+2014-02-19 20:11:09 @Pinkbyte creffett, i prefer to make repoman fatal only on adding new ebuild(does not matter - revision or version bump)
+2014-02-19 20:11:11 @Tommy[D] creffett: a ban warning is the same as deprecation warning, so what does it add?
+2014-02-19 20:11:16 @ulm creffett: so for example, if I remove a keyword from an old ebuild, then I must update the EAPI?
+2014-02-19 20:11:26 @creffett ulm: valid point
+2014-02-19 20:11:28 @Pinkbyte so, in-place edits with not changing EAPI should be possible
+2014-02-19 20:11:33 @ulm that would be just annoying
+2014-02-19 20:11:37 @creffett Pinkbyte: that's what deprecating is supposed to mean
+2014-02-19 20:11:59 @ulm we should only ban 2) and 3) in TomWij's list above
+2014-02-19 20:12:08 @Tommy[D] creffett: also, when i have EAPI=1, then bumping the EAPI may not be trivial, dont assume a minimal ebuild without defined phases ;)
+2014-02-19 20:12:11 @creffett but either a) that's been thoroughly ignored by devs, or b) people aren't touching the EAPI 1/2 stuff
+2014-02-19 20:12:16 @Pinkbyte creffett, huh? Can not we add new EAPI 2 ebuilds in tree now no matter how silly it is?
+2014-02-19 20:12:43 @creffett Pinkbyte: give me a use case where people should add an EAPI=2 ebuild instead of an EAPI=5 ebuild
+2014-02-19 20:12:48 @ulm Pinkbyte: you'll get a repoman warning
+2014-02-19 20:12:50 @Pinkbyte creffett, i think base-sysrtem are doing this quite a long time
+2014-02-19 20:13:00 @Pinkbyte ulm, warning != fatal
+2014-02-19 20:13:03 @Pinkbyte that's my point
+2014-02-19 20:13:27 @Pinkbyte now all we have in all cases(new ebuilds or just change old one) are warnings
+2014-02-19 20:13:27 @Tommy[D] Pinkbyte: maybe 2 to 3 is easy, but what about 1 to 3?
+2014-02-19 20:13:46 @creffett Tommy[D]: then the person moves some configure stuff and some patching stuff around
+2014-02-19 20:13:49 @creffett it's not rocket science
+2014-02-19 20:13:53 @wired Tommy[D]: that's just an excuse not to update IMO, it needs to be done
+2014-02-19 20:14:15 * ulm fears people will take the easy escape and downgrade from 1 to 0
+2014-02-19 20:14:18 @Pinkbyte Tommy[D], not so much changes too. I have done some 0->4 non-trivial bumps - that was a pain, yes
+2014-02-19 20:14:35 @creffett ulm: that's why we're also deprecating 0 (pending an estimate from toolchain on getting everything to EAPI 5)
+2014-02-19 20:14:46 @wired is it boring? yeah. do we want to get those ebuilds on the new EAPI wagon? heck yeah
+2014-02-19 20:14:57 @creffett they're going to have to make the update sooner or later, I see no reason to delay forever
+2014-02-19 20:15:13 @creffett and these _have_ been deprecated for over a year now
+2014-02-19 20:15:13 @Tommy[D] creffett: i know what to do, but i also know that such things need additional time and as you should know, if you have limited time and have the choice, then such forced additional work may be further delayed
+2014-02-19 20:15:29 @creffett so the maintainers have had adequate warning to update
+2014-02-19 20:16:03 @Pinkbyte Tommy[D], it should be done some day. Sooner is better. But, again, updating old ebuilds without touching EAPI should be possible
+2014-02-19 20:16:14 @Tommy[D] creffett: unless you want to step up to do the ebuild conversions yourself, i am against a force/ban/whatever additional
+2014-02-19 20:16:27 @Pinkbyte we do not want to force maintainer to update the whole damn EAPI for just one simple typo fix in ebuild - that would be super-silly
+2014-02-19 20:17:20 @wired a fatal error that can be overridden with --force would be fine IMO
+2014-02-19 20:17:22 @Tommy[D] neither do i want to require the maintainer to do the EAPI dance just to add a minor change with revision bump
+2014-02-19 20:17:34 @ulm BTW, I'm not sure if QA can ban EAPIs
+2014-02-19 20:17:36 @ulm that's council territory
+2014-02-19 20:17:53 @creffett ulm: it is council territory
+2014-02-19 20:17:55 @Pinkbyte wired, --force usage of repoman should be highly discouraged
+2014-02-19 20:17:58 @creffett but we can still ask them nicely
+2014-02-19 20:18:06 @creffett Tommy[D]: why not?
+2014-02-19 20:18:09 @ulm yeah, we can make a recommendation
+2014-02-19 20:18:09 @Tommy[D] wired: and thats another reason to not do it: it makes using that option more common, in the end less care about repoman warnings and finally less QA in the tree
+2014-02-19 20:18:18 @wired Pinkbyte: true, but it's a way out if you really need to commit an ebuild without bumping it
+2014-02-19 20:18:20 @zlogene ulm:but we can suggest recomendation i think
+2014-02-19 20:18:25 @creffett again: the maintainers need to make the change sooner or later
+2014-02-19 20:18:26 @wired Pinkbyte: and a way for us to track what's happening
+2014-02-19 20:18:27 @TomWij (Typing slowly:) If base-system really has some toolchain / eclass reason to keep an old EAPI around they can --force as an exception or something; we're trying to target the main thing here, they will be an exception for a while. And by the time they're the only one left, maybe they've already progressed; or we can help them with getting to EAPI 5 (as it gets more visible to non-base-system people what is
+2014-02-19 20:18:27 @TomWij stuck on lower EAPIs and why).
+2014-02-19 20:18:43 @creffett if you're taking the time to update an ebuild, you can take another minute to change the EAPI
+2014-02-19 20:18:51 @Pinkbyte wired, let's propose this as repoman fatal error with commiting straight to stable - it works only for NEW ebuilds
+2014-02-19 20:19:23 @Pinkbyte so -> want to update some things in old ebuild with old EAPI - fine. Want to commit revbump with old EAPI - go and upgrade it
+2014-02-19 20:19:42 @TomWij +1 on this being a recommendation; and yes, I think some of us try to upgrade an old EAPI ebuild every now and then.
+2014-02-19 20:19:46 @Pinkbyte s/fine/warning/ :-)
+2014-02-19 20:19:47 @wired Pinkbyte: yeah, that's what I have in mind as well
+2014-02-19 20:19:49 @Tommy[D] also keep in mind that the repoman depcrecation warning is way less then a year old and not everyone does read council logs/whatever to catch such things
+2014-02-19 20:20:17 @creffett Tommy[D]: that's not our problem.
+2014-02-19 20:21:01 @creffett also, reading over the repoman code briefly, it doesn't appear that there is a real difference between "banned" and "deprecated" besides the output
+2014-02-19 20:21:05 @Tommy[D] creffett: you argument with "it has been over a year now" and my point is "it may have been a council decision, but enough people may not have it noticed, so its imho no valid argument for banning
+2014-02-19 20:22:24 @creffett Tommy[D]: then what do you want to do?
+2014-02-19 20:22:34 @Tommy[D] creffett: also from the stats i have seen in here, all EAPI versions get reduced numbers every day/week, so it works
+2014-02-19 20:22:43 @creffett Tommy[D]: but it works slowly
+2014-02-19 20:22:56 @creffett really, really slowly
+2014-02-19 20:22:57 @Tommy[D] creffett: and an added ban wont make it faster
+2014-02-19 20:23:06 @Pinkbyte Tommy[D], not totally true
+2014-02-19 20:23:09 @Tommy[D] creffett: if you want it faster, add more manpower to the slow areas
+2014-02-19 20:23:17 @creffett how?
+2014-02-19 20:23:46 @creffett we're already working on removing old EAPIs on our own
+2014-02-19 20:23:50 @Pinkbyte Tommy[D], you want to propose QA team to force upgrading EAPIs all over the tree?
+2014-02-19 20:24:03 @Pinkbyte there would be a lot of noise about such proposal, do not you know?
+2014-02-19 20:24:05 @creffett I've been working through maintainer-needed, we've been talking to Java about migrating from EAPI 1
+2014-02-19 20:24:06 @Tommy[D] if an area is slow, it usually means not enough people in the team, so join the team, do the needed work, but dont request others to do the needed work
+2014-02-19 20:24:13 @creffett disagree
+2014-02-19 20:24:22 @Tommy[D] Pinkbyte: where did i say that?
+2014-02-19 20:24:29 @creffett it is every maintainer's responsibility to help maintain the QA of the tree, or something like that
+2014-02-19 20:24:35 @zlogene Tommy[D]: we have _too_ many slow areas
+2014-02-19 20:24:43 @zlogene it is impossible
+2014-02-19 20:24:50 @creffett if people want help, we can help
+2014-02-19 20:24:51 @Pinkbyte Tommy[D], that's the only way for us as QA to do the job. Other way - join to all teams.
+2014-02-19 20:24:53 @creffett I never said that we can't
+2014-02-19 20:25:00 @Tommy[D] Pinkbyte: i see no added value in a ban beside additional noice/annoyence, if you want things to go faster, join those teams with missing manpower and help them
+2014-02-19 20:25:06 @Tommy[D] nothing QA-hat related
+2014-02-19 20:25:07 @creffett but that doesn't prevent us from telling people to actually help out
+2014-02-19 20:25:18 @Pinkbyte but we need to be seven-headed octocats with 48 hours workdays to do all the job
+2014-02-19 20:25:24 @Tommy[D] zlogene: true, but a ban wont fix that
+2014-02-19 20:25:25 @creffett until we ban EAPIs, people won't CARE whether we want them to upgrade
+2014-02-19 20:25:42 @ulm I also think that a ban won't help much in removing old EAPIs
+2014-02-19 20:25:54 @TomWij Tommy[D]: Good point you raise; there are multiple ways for it to be slow; 1) the maintainer leaves it in place and doesn't care about the warning, 2) it is kept in place (slow stabilization) or 3) the package is unmaintained and/or old and just doesn't get touched. What we're doing here would only really affect (1) and make that faster; however, we're not dealing with (2) and (3) here. (Maybe the next
+2014-02-19 20:25:54 @TomWij agenda point helps with (2), and (3) could be fixable by having us pay some more attention to unmaintained/old stuff)
+2014-02-19 20:26:03 @ulm it's mostly old ebuilds sitting around, and they're just not touched
+2014-02-19 20:26:06 @Pinkbyte ok, guys, let's calm down
+2014-02-19 20:26:11 @Tommy[D] creffett: see the stats, all older EAPI versions go down, so people do respect the deprecation and do migrate
+2014-02-19 20:26:21 @Pinkbyte there is one more proposal that we all forget about
+2014-02-19 20:26:22 @Tommy[D] creffett: but you cannot force it and a ban wont help/enforce it
+2014-02-19 20:26:32 @Pinkbyte we are QA - what we should do when we see QA warning?
+2014-02-19 20:26:40 @Pinkbyte yep - we filing the damn bug
+2014-02-19 20:26:49 @creffett and it gets ignored
+2014-02-19 20:26:51 @Pinkbyte and when maintainer is slow? we fixing the damn thing
+2014-02-19 20:26:59 @zlogene Pinkbyte: i know, fix IT!
+2014-02-19 20:27:01 @Pinkbyte why this should be different?
+2014-02-19 20:27:02 @zlogene hehe
+2014-02-19 20:27:51 @creffett Tommy[D]: so you don't want anything banned or deprecated?
+2014-02-19 20:29:10 @Tommy[D] creffett: i see EAPI-1+2 deprecated and all EAPI versions being less used, so things do migrate, when a dev has the needed time, a ban wont increase this
+2014-02-19 20:29:34 @creffett all right then.
+2014-02-19 20:29:35 @Pinkbyte creffett, i rethink that and agreed with ulm said - let's gave banning decision to Council.
+2014-02-19 20:29:41 @zlogene I think we have not enough manpower, so even if we ban anything, we can't do any work more faster.
+2014-02-19 20:29:49 @Tommy[D] imho we can ban an EAPI if there is no user of it left in the tree, but otherwise i see no reason to do that
+2014-02-19 20:29:58 @creffett Pinkbyte: it's their decision, but we can still say "we, QA, would like X banned and Y deprecated"
+2014-02-19 20:30:06 @TomWij Pinkbyte: We're deciding on a recommendation here; as ulm pointed out, it's Council terrain.
+2014-02-19 20:30:10 @wired I'd like more "loud" messages, my recommendation would be to make the first commit of 1/2 eapi ebuilds fail.
+2014-02-19 20:30:17 @Pinkbyte creffett, and for now those who are bored can go and do fun with filing bugs, poking maintainers and fixing the stuff in the end
+2014-02-19 20:30:35 @creffett but right now, if those EAPIs aren't banned, there's not much point in filing the bugs
+2014-02-19 20:30:37 @ulm Tommy[D]: EAPI 1 is very close to being extinct
+2014-02-19 20:30:44 @creffett the maintainer will just say "it's not an error, go away"
+2014-02-19 20:31:10 @Tommy[D] ulm: well, if EAPI-1 is down to zero, a ban is fine by me
+2014-02-19 20:31:13 @Pinkbyte creffett, CFLAGS/LDFLAGS are also not repoman error, so?
+2014-02-19 20:31:41 @creffett Pinkbyte: apples to oranges, in this case
+2014-02-19 20:31:53 @creffett Tommy[D]: could we at least compromise on banning EAPI 1? it only has a couple hundred left in tree
+2014-02-19 20:31:54 @Tommy[D] creffett: please show us your huge amount of developers telling you "EAPI is no error, go away" ;)
+2014-02-19 20:32:03 @TomWij zlogene: Banning is just another more verbal way to say "please do upgrade, it's been around for long enough now"; the positive side is that it can get more people to upgrade, the negative side is that people that --force will become more visible. (As --force is a red light to us)
+2014-02-19 20:32:24 @creffett Tommy[D]: please show me your developers who won't do stuff if they get a repoman error because of banned EAPIs
+2014-02-19 20:32:42 @TomWij creffett: Given an hour has passed, I think we should look at how many people are for and against "recommending a ban".
+2014-02-19 20:32:52 @Tommy[D] TomWij: i dont think that it will help with any upgrade speed, imho it may even make it worse and slow it down
+2014-02-19 20:32:53 @creffett TomWij: fine with me
+2014-02-19 20:32:56 @TomWij s/an hour/an half hour/
+2014-02-19 20:33:22 @creffett all in favor of banning EAPI 1 and/or EAPI 2? (we'll nail down which to recommend if this passes)
+2014-02-19 20:33:27 * creffett yes
+2014-02-19 20:33:31 @Pinkbyte creffett, python eclasses are deprecated and throws warnings and i see no developer who said(in bugreport, maillists have some complains about new eclasses design) - 'i will stick with my old shiny python eclass, go away with your -r1 cruft'
+2014-02-19 20:33:34 @TomWij (The arguments aren't really improving at this point anymore.)
+2014-02-19 20:33:34 @wired yeah
+2014-02-19 20:33:57 @TomWij creffett: yes
+2014-02-19 20:34:14 @Tommy[D] creffett: well, if i have little time, want to do e.g. a quick bump and get a repoman error, i likely will delay it to anytime in the future and likely to the end of my todo list
+2014-02-19 20:34:15 @Pinkbyte creffett, yes
+2014-02-19 20:34:22 @ulm yes
+2014-02-19 20:34:32 @creffett Tommy[D], zlogene: your votes, please?
+2014-02-19 20:34:47 @Tommy[D] against ban, so no
+2014-02-19 20:34:55 @zlogene yes
+2014-02-19 20:35:09 @creffett 6 for, 1 against, 3 missing. Motion passes
+2014-02-19 20:35:22 @creffett all in favor of recommending EAPI 1 be banned?
+2014-02-19 20:35:25 * creffett yes
+2014-02-19 20:35:29 * ulm yes
+2014-02-19 20:35:29 * Pinkbyte yes
+2014-02-19 20:35:31 * TomWij yes
+2014-02-19 20:35:46 * wired yes
+2014-02-19 20:35:58 * zlogene yes
+2014-02-19 20:35:58 @Tommy[D] creffett: wrt your question above: once those couple hundred ebuilds are converted, i am ok with a ban, before i dont see any value, so no again
+2014-02-19 20:35:59 @zlogene just for straight
+2014-02-19 20:36:12 @creffett 6 for, 1 against, 3 missing. motion passes.
+2014-02-19 20:36:19 @creffett all in favor of recommending EAPI 2 be banned?
+2014-02-19 20:36:24 * ulm no
+2014-02-19 20:36:25 * Pinkbyte abstain
+2014-02-19 20:36:29 @Tommy[D] no again
+2014-02-19 20:36:30 * creffett yes
+2014-02-19 20:36:38 * wired yes
+2014-02-19 20:36:55 @TomWij irker707 | [01:00:07] EAPI-stats: EAPI 1: 360 ebuilds ( 0.95 percent) +0 daily +0 weekly -10 monthly diff
+2014-02-19 20:36:55 @TomWij irker707 | [01:00:08] EAPI-stats: EAPI 2: 3216 ebuilds ( 8.49 percent) +1 daily -14 weekly -84 monthly diff
+2014-02-19 20:37:09 * TomWij yes
+2014-02-19 20:37:27 @creffett zlogene: your vote?
+2014-02-19 20:37:29 * zlogene abstain
+2014-02-19 20:37:46 @creffett 3 yes, 2 no, 2 abstain, 3 missing. motion fails to pass
+2014-02-19 20:37:56 @creffett next, deprecation
+2014-02-19 20:38:09 @creffett all in favor of deprecating EAPI 0?
+2014-02-19 20:38:17 * ulm yes
+2014-02-19 20:38:18 * Pinkbyte yes
+2014-02-19 20:38:21 * zlogene yes
+2014-02-19 20:38:23 @ulm but talk to toolchain
+2014-02-19 20:38:27 * creffett yes, but want to talk to toolchain
+2014-02-19 20:38:38 @TomWij it's just a warning afaik
+2014-02-19 20:38:38 @Tommy[D] once toolchain has an upgrade path, then yes
+2014-02-19 20:38:39 @creffett mhm
+2014-02-19 20:38:40 * TomWij yes
+2014-02-19 20:39:07 @creffett wired: your vote?
+2014-02-19 20:39:28 @wired yes
+2014-02-19 20:39:30 @wired srry
+2014-02-19 20:39:39 @creffett 7 for, 3 missing. motion carries
+2014-02-19 20:39:47 @creffett all in favor of deprecating EAPI 3?
+2014-02-19 20:39:48 * creffett yes
+2014-02-19 20:39:59 * zlogene yes
+2014-02-19 20:40:22 @wired yes
+2014-02-19 20:40:28 @Pinkbyte out of curiosity - one sec - which year was EAPI 3 introduced?
+2014-02-19 20:40:37 * ulm abstain
+2014-02-19 20:40:52 @Pinkbyte it seems that was 2010
+2014-02-19 20:40:55 * TomWij yes
+2014-02-19 20:40:56 @Pinkbyte so, i vote - 'no'
+2014-02-19 20:41:02 @ulm Pinkbyte:
+2014-02-19 20:41:06 @ulm bottom of page
+2014-02-19 20:41:28 @Tommy[D] abstain
+2014-02-19 20:41:29 @Pinkbyte ulm, thanks, discovered that myself in EAPI 3 PMS edition in your devspace ;-)
+2014-02-19 20:41:47 @creffett 4 yes, 1 no, 2 abstain. motion passes.
+2014-02-19 20:42:20 @creffett next: " Revisit policy on dropping packages to unstable when stabilization takes too long "
+2014-02-19 20:43:18 @Tommy[D] what exactly is the issue/problem?
+2014-02-19 20:43:23 @creffett my opinion is that you should only be dropping stable as a last resort, and I am okay with the solution of dropping all but the stable keywords from an old version of a package (but am opposed to use of KEYWORDS="-* arch" in this context
+2014-02-19 20:43:32 @TomWij (I think the fail on banning EAPI 2 is okay if people consider the amount of ebuilds too big; of course, if it is that big it can become quite an annoyance to put a ban on it. Math shows the rate of migration is similar to that of EAPI 1, but indeed the size on its own is important as well; I voted purely on ratio there.)
+2014-02-19 20:43:52 @TomWij Zero_Chaos: Present?
+2014-02-19 20:44:21 @Tommy[D] creffett: so you now want to suggest a different policy?
+2014-02-19 20:45:05 @creffett Tommy[D]: there were concerns raised about how this ignores the standard removal policy
+2014-02-19 20:45:29 @TomWij creffett: "last resort" is kind of free for interpretation; if the maintainer cares about it, I think it is often kind of a last resort especially when a waiting time is introduced.
+2014-02-19 20:45:50 @Tommy[D] creffett: my question again: what exactly is the issue and which exact policy could be ignored with our last vote?
+2014-02-19 20:45:54 @creffett TomWij: but people were interpreting it as "if I feel like maintainers took too long, I can just drop stuff"
+2014-02-19 20:45:56 @creffett Tommy[D]: sec
+2014-02-19 20:46:36 @ulm we should always keep in mind that removing stable will break things on users' systems for these arches
+2014-02-19 20:46:38 @Tommy[D] creffett: sure about that? our vote was about maintainers, so you did replace arch teams with maintainers there?
+2014-02-19 20:46:52 @creffett Tommy[D]: er, sorry, yes, meant arch teams
+2014-02-19 20:47:34 @TomWij creffett: The policy as we had voted only allowed the maintainer to do so, did you mean "arch teams" in your quotes?
+2014-02-19 20:47:40 @TomWij creffett: Dropping the other keywords from an old ebuild version is something already done, policy doesn't disallow you to do that (and I've already done so in the past, once on gentoo-sources for instance to keep a nvidia-drivers compatible version around); so, I see it is as irrelevant wrt to forming a policy. (It is relevant to the discussion)
+2014-02-19 20:47:41 @Tommy[D] creffett: and yes, it did mean exactly that, what is the issue with dropping an old, outdated, not anymore maintained version?
+2014-02-19 20:48:33 * creffett sighs
+2014-02-19 20:48:41 @Tommy[D] also reducing keywords adds no benefit, any arch doings its work has newer stable versions, so you wont have users there anyway, so having or dropping a keyword there does not matter
+2014-02-19 20:48:41 @creffett Zero_Chaos could explain the issue better
+2014-02-19 20:49:11 @TomWij creffett: Do we have Zero_Chaos concerns somewhere summarized? Or do you remember them well? One of them was wrt. proper masking and such, which we definitely should make policy if we continue with this; but on the other hand, I think he didn't want to see this policy at all for other concerns.
+2014-02-19 20:49:27 @creffett TomWij: I don't know
+2014-02-19 20:49:42 * creffett has to run to class, back in 5...if someone could dig out Zero_Chaos's concerns, that would be much appreciated
+2014-02-19 20:49:46 @Tommy[D] creffett: well, he was not able to explain it to me at all, it was more a general "but it breaks something and a policy", but nothing more specific
+2014-02-19 20:50:52 @TomWij ulm: The package.mask for 30 days or so could make the progress for the user more soft, or we need to introduce something PM style to make ARCH -> ~ARCH moves more easy for the user.
+2014-02-19 20:50:56 @Tommy[D] his concerns have been something like "but it breaks stable user experience/tree" also i did not get why or how
+2014-02-19 20:51:24 @TomWij I think we really need Zero_Chaos for this discussion; so, I think we should keep this "in discussion" and schedule a mini-meeting later with Zero_Chaos present.
+2014-02-19 20:51:47 @TomWij Or give Zero_Chaos like X days to formally write down his concerns and reasons so we get a good understanding of them.
+2014-02-19 20:51:48 @Tommy[D] and his point with policy was, that our policy for removing packages in his eyes also applies to removing versions, so he claimed our policy violates the policy for removing packages
+2014-02-19 20:52:03 @ulm TomWij: why should one package mask an ebuild that is still working?
+2014-02-19 20:52:21 @ulm unless there are security issues, but that's already covered by policy
+2014-02-19 20:52:25 @Pinkbyte Tommy[D], you drop the last one "foo" ebuild, cause "foo" arch is slow. Only ~foo ebuilds are left. User, that have installed "foo"-stable version of package will get breakage on upgrade and he had to add package to keywords file
+2014-02-19 20:52:38 <-- creffett (~creffett@gentoo/developer/creffett) has quit (Read error: Operation timed out)
+2014-02-19 20:52:43 @Pinkbyte unless he has ACCEPT_KEYWORDS=~foo of course
+2014-02-19 20:53:33 @Tommy[D] Pinkbyte: well, you have any other solution except letting the package bitrot, eventually fail to even install/function just so the user thinks he has a stable system?
+2014-02-19 20:54:04 @Tommy[D] Pinkbyte: keep in mind that users on minor arches have to add entries to package.keywords for a good amount of packages anyway
+2014-02-19 20:54:34 @TomWij ulm: Well, because it is quite old and can no further be maintained; let's say sun-jdk / sun-jre-bin / sun-jce-bin didn't have security issues, then we would have still masked it at some point in time because we can no longer look after the package (but yet some people use it for some java applets in corporate companies or on bank websites).
+2014-02-19 20:55:19 @Pinkbyte Tommy[D], i know that. But to be honest, i do not see ideal solution there
+2014-02-19 20:55:46 @ulm TomWij: what's the problem with old software, given that it works and has no security issues?
+2014-02-19 20:55:53 @Pinkbyte idealistic one is understaffed but responsive arch team that CONSTANTLY drops "foo" to "~foo" on most of packages
+2014-02-19 20:55:57 @Tommy[D] Pinkbyte: imho dropping stable version/keywords is the best solution we can have without adding to much additional work on maintainers
+2014-02-19 20:55:57 @Pinkbyte for all versions
+2014-02-19 20:56:07 @TomWij Or when there's like 20 sun-* bugs and 20 oracle-* bugs; then you're simply going to say, I have time to fix the new oracle ones but the old sun ones are getting unfixable and I have no further time to look at them at well.
+2014-02-19 20:56:10 @Pinkbyte and respecting revdeps
+2014-02-19 20:56:18 @TomWij Kind of similar like the GNOME team not being able to keep GNOME 2.x around.
+2014-02-19 20:56:35 @Tommy[D] Pinkbyte: it does not matter if it is the arch team or the maintainer, dropped keywords are dropped keywords, result is the same ;)
+2014-02-19 20:56:52 @TomWij ulm: GNOME 2.x breaks over time simply because the libraries get bumped.
+2014-02-19 20:57:13 @ulm TomWij: sure, if it's broken then it's another issue
+2014-02-19 20:57:17 @TomWij New glibc, ...
+2014-02-19 20:57:19 @Tommy[D] that is likely true for all software
+2014-02-19 20:57:24 @TomWij ulm: You need to spot the breakage though.
+2014-02-19 20:57:44 @Pinkbyte Tommy[D], arch team has, well, more generic view of supported packages on their own arch
+2014-02-19 20:58:23 @TomWij I don't think a maintainer intentionally tests the oldest versions of a package on an old arch though; the maintainer doesn't even have the arch, so it rather boils down to the arch team to do that. But the arch team is undermanned ...
+2014-02-19 20:58:40 @Tommy[D] Pinkbyte: problem is usually, that there is not enough time to do keywording, doing such generic things requires more work, so less likely to happen
+2014-02-19 20:58:54 @TomWij The user does notice it and files some bugs, but they get to stick in a backlog; they depend on the stabilization bug, that stabilization bug that is never dealt with.
+2014-02-19 20:59:31 @Tommy[D] and in the end the bug becomes WONTFIX, the ebuild removed and the result is the same
+2014-02-19 20:59:49 @TomWij Let's say hypothetically, like, GNOME 1.x was still around; how would we deal with that?
+2014-02-19 20:59:50 --> creffett (~creffett@gentoo/developer/creffett) has joined #gentoo-qa
+2014-02-19 20:59:50 -- Mode #gentoo-qa [+o creffett] by ChanServ
+2014-02-19 20:59:56 @Tommy[D] just with added bad user experience
+2014-02-19 20:59:59 @Pinkbyte Well, guys, we talked about this last time with exactly the same arguments. Let's conclude - what's our options?
+2014-02-19 21:00:22 @Tommy[D] i still support the vote from last time
+2014-02-19 21:00:30 @Pinkbyte Add maintainer power to drop keywords on some arches from stable to testing after some reasonable amount of time?
+2014-02-19 21:00:51 * creffett back
+2014-02-19 21:00:57 @Pinkbyte of course, with proper doing stuff on revdeps, etc, etc
+2014-02-19 21:01:12 @creffett I move that we postpone the discussion until we get Zero_Chaos here, since he can articulate his concerns much better than I can
+2014-02-19 21:01:20 @TomWij Pinkbyte: There are a ton of options in the stabilization threads, but it's so wide and lengthy that summarizing them is a bit hectic to do; there's been some options more explored, but those are rather the ones that were the least well received by people on the mailing list. Maybe some of the good options even drown in the bad options...
+2014-02-19 21:01:23 @zlogene creffett: glad to see you again :)
+2014-02-19 21:01:32 @wired creffett++
+2014-02-19 21:02:07 @Pinkbyte TomWij, tbh, i did not see any good options other than supported here. And no ideal, so i am a bit frustrated :'-(
+2014-02-19 21:02:09 @TomWij Similar to Tommy[D], I still support the vote from last time _under the premise_ that we update its wording; but also similar to creffett, I'd like to get Zero_Chaos input on this.
+2014-02-19 21:02:24 @Tommy[D] creffett: please ask him to write a mail, otherwise some will miss his points and then we are again in the same position as today
+2014-02-19 21:02:43 @creffett Tommy[D]: will do
+2014-02-19 21:02:58 @creffett all right, postponed
+2014-02-19 21:03:01 * creffett bangs the gavel
+2014-02-19 21:03:47 @creffett next: vapier stabling on experimental arches
+2014-02-19 21:03:49 @creffett do we care?
+2014-02-19 21:03:55 @TomWij (update its wording = make it clear what the conditions are, make sure no words are ambiguous or easily misinterpreted, make sure it is clear what needs to be done [= package.mask 30 days, ...] to not get a plain `rm ...`; but well, updating the wording only applies if we make the policy succeed)
+2014-02-19 21:04:07 @Tommy[D] wait for council decision for the minor arches and stable keywords
+2014-02-19 21:04:11 @zlogene creffett: it is a major problem
+2014-02-19 21:04:22 @zlogene Mike ignore all rules
+2014-02-19 21:04:36 @creffett technically there's no rule saying you can't stable on an experimental arch
+2014-02-19 21:04:42 @creffett it's just usually considered a waste of time
+2014-02-19 21:05:05 @TomWij creffett: vapier stabling; as far as I am aware of what was going on with that, I think that was not a problem given there is no stage3 yet. This guarantees that users installing it are doing experimental stuff themselves and should expect the possibility of total breakage as part of that.
+2014-02-19 21:05:19 @creffett zlogene: do you have anything to add here?
+2014-02-19 21:05:35 @Pinkbyte creffett, but we should have some rules for this. For example - have stable only for stage building cruft
+2014-02-19 21:05:43 @Tommy[D] TomWij: i dont see any ways of misinterpretation or changed rules, but as you said, lets talk about it next time when/if it is accepted again
+2014-02-19 21:05:48 @zlogene creffett: even if we'll downgrade experemental arches, he will revert our commits again
+2014-02-19 21:05:54 @Pinkbyte TomWij, tbh, we HAVE stages for s390, that was dropped to unstable
+2014-02-19 21:06:10 @zlogene for example see dev-lang/perl ChangeLog
+2014-02-19 21:06:16 @TomWij What I find more concerning is what happens after that; when it moves out of stable it needs a "go" from whoever needs to be involved in that, such that the stabilization has passed multiple eyes rather than just that of vapier.
+2014-02-19 21:06:16 @zlogene as i already said
+2014-02-19 21:06:57 @creffett except the council hasn't met yet, so we don't have their input on this matter...
+2014-02-19 21:07:03 @creffett dammit fosdem. :P
+2014-02-19 21:07:08 @Pinkbyte err, that question relies on previous one
+2014-02-19 21:07:11 @zlogene TomWij: : vapier does ot responsive
+2014-02-19 21:07:21 @Tommy[D] i suggest postphone until council has decided on the minor arch keywording situation
+2014-02-19 21:07:38 @Pinkbyte i mean, we have package-0.19 stable on s390, newer versions are not stabililzed, stabilization bug is closed, our options as maintainer?
+2014-02-19 21:07:54 @TomWij Tommy[D]: Were you present when Zero_Chaos addressed me in #gentoo-dev and #gentoo-qa? Part of it boiled down to there being a misinterpretation by people on the ML; as for the details, it had to do with `rm the.ebuild` versus following a set of proper mask&wait&remove steps.
+2014-02-19 21:07:58 @creffett I second Tommy[D]'s suggestion, I forgot that the council meeting was put off
+2014-02-19 21:08:12 @creffett TomWij: we've already postponed that discussion, please drop it
+2014-02-19 21:08:23 @Pinkbyte drop old version after fixing revdeps and hope that he would not mark new versions stable? Probably without testing as "urgent" matter as tree may be "broken" from his side?
+2014-02-19 21:08:46 @Tommy[D] TomWij: feel free to move this to pm after meeting is done, so we dont mix topic during meeting
+2014-02-19 21:08:49 @TomWij creffett: Yes, I agree with doing that next time; just noting its context, such that Tommy[D] can read up on it if wanted.
+2014-02-19 21:09:02 @creffett okay
+2014-02-19 21:09:06 @Pinkbyte so, probably we should deal minor arches question first and then - talk about vapier behaviour when we have clear decision what we SHOULD do in such cases
+2014-02-19 21:09:10 @creffett yeah
+2014-02-19 21:09:27 @creffett vapier does need to be handled somehow, but first we have to see if the council thinks he's in the wrong
+2014-02-19 21:09:42 @TomWij zlogene: What is "ot" in "vapier does ot responsive"?
+2014-02-19 21:09:53 @Pinkbyte TomWij, probably it was 'not'
+2014-02-19 21:10:02 @TomWij As in "vapier doesn't respond"?
+2014-02-19 21:10:08 @creffett TomWij: yes
+2014-02-19 21:10:27 @zlogene TomWij: a typo
+2014-02-19 21:10:32 @creffett if people have ideas for how to deal with unresponsive maintainers like vapier, let me know privately, but for now we'll postpone this
+2014-02-19 21:10:40 @Pinkbyte creffett, agreed. Anyway, he does this stuff on arches where he is the one in arch team, so nobody can say him 'hey, i know that arch, bro, you are not right'. Cause there are no guys who really KNOWS :-/
+2014-02-19 21:10:41 @TomWij Well, I don't think vapier sees a problem in it; so, he probably won't /care unless it forms a real problem.
+2014-02-19 21:10:52 @creffett since the agenda said that this item was waiting for a council decision which hasn't come
+2014-02-19 21:11:04 * creffett bangs his gavel
+2014-02-19 21:11:19 @creffett next topic: multislot issue
+2014-02-19 21:12:00 @creffett the forum poll broke down (and isn't exactly a representative sample), but we've heard from dirtyepic that he's got no preference about it, and most of the forum didn't care
+2014-02-19 21:12:12 @creffett (also, I _suspect_ the one person who said it would braek things was referring to GRUB)
+2014-02-19 21:12:16 @TomWij (creffett: I think that if there's a real problem wrt vapier that actually affects people, then that should be brought forward such that we have actual material to discuss (and not just vapier as a person); but I don't see the problem on vapier here, given its experimental non-stage3 nature.)
+2014-02-19 21:12:33 @ulm creffett: yeah, 1 user using dynamic slots
+2014-02-19 21:12:44 @ulm and 24 that don't care
+2014-02-19 21:12:47 @wired creffett: seems to me this whole thing should go away to an overlay maintained by people that actually care about it
+2014-02-19 21:12:51 @creffett wired++
+2014-02-19 21:13:04 @Pinkbyte creffett, the trick is gcc ebuild
+2014-02-19 21:13:06 @creffett I move that we ask toolchain to remove the flag, either moving it to an overlay or just dropping it
+2014-02-19 21:13:29 @wired creffett++
+2014-02-19 21:13:29 @Pinkbyte which relies on toolchain eclass and dirtyepic was strongly agains maintaining two eclasses as i understand from his e-mail
+2014-02-19 21:13:30 @creffett I don't really care if they implement microslots, that's their decision, but the flag and the USE-dependent SLOT need to go
+2014-02-19 21:13:59 @creffett Pinkbyte: yeah, but I don't think it is the end of the world to have some special handling in toolchain eclass
+2014-02-19 21:14:13 @creffett heck, they probably could just remove USE=multislot from the tree and leave the eclass as-is
+2014-02-19 21:14:20 @TomWij wired++: Sounds good, let people whom are interested experiment it with overlay / PM forks and what not they deem good; but as long as it is just a hot topic, and users aren't really looking forward to this feature or approach it doesn't make much sense to add it to the Portage tree. (And I don't think it benefits us either, in terms of easier maintenance or what not)
+2014-02-19 21:14:25 @creffett but a package.use.mask isn't acceptable here either, sine the breakage is still there
+2014-02-19 21:14:28 @wired Pinkbyte: I wouldn't mind keeping eclass code in the tree, as long as the ebuilds in the tree have fixed slots
+2014-02-19 21:14:41 @ulm wired ++
+2014-02-19 21:15:20 @creffett so, formal vote: we ask toolchain to remove multislot from the tree, and further we add a policy saying that USE-dependent SLOT values are not permitted in tree
+2014-02-19 21:15:22 * creffett yes
+2014-02-19 21:15:28 * wired yes
+2014-02-19 21:15:29 @Tommy[D] so just ask them to drop the exposed feature as in remove the useflag in the main tree, rest could stay as it is not visible/doing harm?
+2014-02-19 21:15:48 @creffett Tommy[D]: I _think_ that is an acceptable solution
+2014-02-19 21:16:11 * ulm yes
+2014-02-19 21:16:23 * zlogene yes
+2014-02-19 21:16:26 @Tommy[D] yes with clarification, that the exposed/visible part as the useflag has to go, internal parts like in the eclass coudl stay
+2014-02-19 21:17:15 @creffett TomWij, Pinkbyte: votes?
+2014-02-19 21:17:23 * Pinkbyte yes
+2014-02-19 21:18:49 * creffett twiddles
+2014-02-19 21:19:03 * wired whistles
+2014-02-19 21:19:03 * TomWij reads
+2014-02-19 21:19:13 * TomWij yes
+2014-02-19 21:19:27 @creffett there we go
+2014-02-19 21:19:36 @creffett 7 for, 3 missing. motion passes.
+2014-02-19 21:19:39 * creffett bangs his gavel
+2014-02-19 21:19:48 @wired
+2014-02-19 21:19:52 @creffett last on the agenda: " Review GTK USE flag situation as discussed on mailing lists (continued from last month) "
+2014-02-19 21:19:59 * creffett ducks and covers
+2014-02-19 21:20:06 @creffett the opinion on the list has been mixed
+2014-02-19 21:20:14 @TomWij We've got 40 mins for this one. \o/
+2014-02-19 21:20:28 @creffett my impression is that the GNOME people like their system, most others like the gtk2/gtk3/(gtk4?)/... solution
+2014-02-19 21:20:50 @wired creffett: yeah, that's what I thought too
+2014-02-19 21:20:51 @zlogene wired: i should save it :D
+2014-02-19 21:20:57 @Pinkbyte creffett, and hasufell has already complains on us to council, nice :-/
+2014-02-19 21:20:58 @creffett and I still think the -r200/-r300 is a horrific abuse of slots, but that's a separate issue
+2014-02-19 21:21:13 @wired well, I still need to reply to the thread
+2014-02-19 21:21:56 @wired but my opinion is there are cases where libraries need to be treated differently (like webkit-gtk)
+2014-02-19 21:22:01 @creffett I would like to recommend gtk2/gtk3 (or in this case, gtk and gtk3, to simplify everyone's workload)
+2014-02-19 21:22:03 @Tommy[D] sadly i had not enough time to read the -dev ML, so cant talk about that thread :/
+2014-02-19 21:22:12 @creffett and use a versioned GTK flag
+2014-02-19 21:22:16 @wired still, we should really push for gtk/gtk3{/gtk4,etc}
+2014-02-19 21:22:39 @creffett does anyone have input otherwise before I call a vote?
+2014-02-19 21:22:41 @wired and we really need to steer away from USE="gui"
+2014-02-19 21:22:42 @TomWij creffett: Yeah, and remembering that the RESOLVED INVALID bugs kind of are a similar situation; it seems there definitely are two camps here, and making either camp happy might dissatisfy the other camp. Now the question is what the better choice is; GNOME's view, gtk2/gtk3/... view or inconsistency? (Unless there is some intermediate / different choice that satisfies both)
+2014-02-19 21:22:45 @Pinkbyte ulm, would it be unfair if i ask you to say other Council members that we actually care about this, no matter what hasufell said? Or am i a bit overreacting? >:-/
+2014-02-19 21:22:56 @wired that use flag reminds me of ubuntu
+2014-02-19 21:22:56 @wired :p
+2014-02-19 21:23:10 @ulm Pinkbyte: will do ;)
+2014-02-19 21:23:12 @creffett wired: heh
+2014-02-19 21:23:30 @Pinkbyte TomWij, inconsistency should be killed with fire, definitely
+2014-02-19 21:23:48 @creffett TomWij: we're going to piss one side or the other off.
+2014-02-19 21:23:51 @creffett let's pick which one
+2014-02-19 21:23:52 @ulm wired: we used to have USE=X for that
+2014-02-19 21:24:00 @TomWij Yeah, and I think wired's statement is inconsistency so I would be against this: "but my opinion is there are cases where libraries need to be treated differently (like webkit-gtk)"
+2014-02-19 21:24:01 @ulm may change with wayland, though
+2014-02-19 21:24:16 @TomWij Unless wired has some good use case for that, but then it complicates things.
+2014-02-19 21:24:32 @creffett I move that we recommend the use of versioned flags (that is, a separate flag for gtk2, gtk3, etc.); we will discuss whether gtk should = gtk2 if this passes
+2014-02-19 21:24:35 @wired ulm: that was gui under cover :P
+2014-02-19 21:24:51 * creffett yes
+2014-02-19 21:25:00 @wired creffett: I recommend we don't do this specifically for gtk, but establish a baseline for all similar cases
+2014-02-19 21:25:31 @TomWij creffett: Wait ... do we want to "recommend" this or make it policy?
+2014-02-19 21:25:34 @creffett wired: that's vote number 3
+2014-02-19 21:25:41 @creffett TomWij: clarification, make it policy
+2014-02-19 21:25:55 @ulm creffett: what's the concrete vote? o.O
+2014-02-19 21:25:56 @wired and I would like this to be a policy that makes the tree consistent
+2014-02-19 21:25:59 @creffett one sec
+2014-02-19 21:26:07 @creffett okay, I would like to call three votes
+2014-02-19 21:26:16 @wired TomWij: well, there are corner cases that could be treated differently, but those would be exceptions
+2014-02-19 21:26:19 @creffett first, do we make it policy that GTK uses versioned USE flags (gtk2, gtk3, etc.)
+2014-02-19 21:26:29 * TomWij yes on first.
+2014-02-19 21:26:31 * wired yes
+2014-02-19 21:26:40 @creffett can I finish? :P
+2014-02-19 21:26:57 * Pinkbyte yes
+2014-02-19 21:27:01 @Tommy[D] type faster :D
+2014-02-19 21:27:02 @creffett second, do we say that we migrate to gtk instead of gtk2 for the sake of simplicity
+2014-02-19 21:27:12 * TomWij no on "can I finish?".
+2014-02-19 21:27:26 * zlogene yes
+2014-02-19 21:27:32 @Pinkbyte meh, let's be serious
+2014-02-19 21:27:33 @creffett (since there were a lot of complaints about how a lot of stuff uses gtk, but gtk2 is quick to kill)
+2014-02-19 21:27:39 * Pinkbyte yes on both
+2014-02-19 21:27:39 @TomWij Pinkbyte: Yes, we should.
+2014-02-19 21:27:56 @TomWij I thought they were going one by one, but creffett wants to make it a table.
+2014-02-19 21:28:05 @creffett third, do we make this a general policy: in cases where something can link against one or more versions of a library, there should be a versioned USE flag
+2014-02-19 21:28:15 @TomWij I can't even follow what zlogene is voting on now.
+2014-02-19 21:28:23 * ulm 1:yes 2:yes 3:no
+2014-02-19 21:28:31 @TomWij ^ Let's vote again ulm's way.
+2014-02-19 21:28:34 @creffett TomWij: I just wanted to make it clear what the next votes were going to be, in case people wanted to add those as conditions)
+2014-02-19 21:28:36 @ulm too few cases for 3
+2014-02-19 21:29:14 @creffett fair
+2014-02-19 21:29:16 @creffett votes, please
+2014-02-19 21:29:22 @creffett 1 yes 2 yes 3 yes
+2014-02-19 21:29:30 * Pinkbyte 1:yes 2:yes 3:yes
+2014-02-19 21:29:41 @wired yes, yes, yes
+2014-02-19 21:29:51 * zlogene 1,2,3: yes
+2014-02-19 21:30:13 @Tommy[D] abstain
+2014-02-19 21:30:20 * TomWij 1:yes 2:no 3:no (More sane per example. / If possible, make it even more neat instead of confusing. / No, we can do this on case by case; vote on this later again.)
+2014-02-19 21:30:55 @creffett I think that's everyone
+2014-02-19 21:30:56 * creffett tallies
+2014-02-19 21:31:03 @wired on 3: we can always discuss other cases, but I'd like the general policy to be "try to keep them versioned"
+2014-02-19 21:31:17 @creffett 1: 6 for, 1 abstain, 3 absent. passes.
+2014-02-19 21:31:28 @creffett 2: 5 for, 1 against, 1 abstain. passes.
+2014-02-19 21:31:43 @creffett 3: 4 for, 2 against, 1 abstain. passes.
+2014-02-19 21:31:51 @creffett well, that was surprisingly painless
+2014-02-19 21:31:54 @TomWij wired: We could do another vote (4) to recommend people to keep things versioned in generic, but don't make it necessary by policy.
+2014-02-19 21:32:14 @wired policy with exceptions sounds good to me
+2014-02-19 21:32:17 @creffett I could live with making 3) be a recommendation rather than policy, and can be revisited as needed
+2014-02-19 21:32:53 @ulm +1 for making it a recommendation
+2014-02-19 21:32:57 @Pinkbyte +1
+2014-02-19 21:33:06 @wired I'd rather say "please discuss it"
+2014-02-19 21:33:09 * TomWij yes on recommendation.
+2014-02-19 21:33:17 @wired make discussion a policy
+2014-02-19 21:33:18 @wired :p
+2014-02-19 21:33:23 * Pinkbyte scares about this some kind of votes on votes
+2014-02-19 21:33:31 @creffett I vote that we vote on voting.
+2014-02-19 21:33:36 @wired awesome
+2014-02-19 21:33:51 @ulm we should discuss if we vote on voting :p
+2014-02-19 21:33:57 @creffett all right, let's just make this a formal vote.
+2014-02-19 21:34:00 @Tommy[D] i vote for the discussion about the votes on voting :p
+2014-02-19 21:34:08 @Pinkbyte serious people do serious business? nah, screw that :-)
+2014-02-19 21:34:09 @TomWij wired: Well, discussion is as easy as bringing it up in the agenda; otherwise we're going have to figure out now in advance if it's going to lead to inconsistency or not, etc...
+2014-02-19 21:34:36 @wired true
+2014-02-19 21:34:53 @TomWij In this GNOME case it does have inconsistency, but for other cases it might not yield inconsistency if the different approach is in use and no people go for the versioned approach.
+2014-02-19 21:34:54 @wired IMO we should keep it as a policy and work our way from there
+2014-02-19 21:35:02 @wired recommendation = do whatever you want
+2014-02-19 21:35:03 @wired :p
+2014-02-19 21:35:07 @creffett do we recommend that cases like this (can link against multiple version of a library) use versioned USE flags (and this should be discussde with the QA team)
+2014-02-19 21:35:12 @wired gnome/gtk3 situation proves this
+2014-02-19 21:35:44 @creffett (this is really hard to word in a non-awkward manner, you know)
+2014-02-19 21:35:46 @creffett anyway, vote please
+2014-02-19 21:35:53 @TomWij creffett: +1
+2014-02-19 21:35:58 * creffett votes yes, make it a recommendation
+2014-02-19 21:36:12 * ulm yes
+2014-02-19 21:36:22 * wired no, I prefer a policy
+2014-02-19 21:36:55 * Pinkbyte yes, recommendation
+2014-02-19 21:37:11 * wired with clear wording that there can be exceptions if reasons are properly demonstrated
+2014-02-19 21:37:14 @TomWij I just don't want to see this turn out into changing an already consistent approach into another consistent approach; as you then get an inconsistent migration, just because it is policy. Ofc this won't happen in practice because nobody is crazy, but it's kind of what making this a policy could make happen.
+2014-02-19 21:37:23 * zlogene yes, recommendation
+2014-02-19 21:37:39 @creffett Tommy[D]: your vote?
+2014-02-19 21:37:40 @Tommy[D] abstain
+2014-02-19 21:37:49 @creffett okay
+2014-02-19 21:38:00 @creffett 5 for, 1 against, 1 abstain
+2014-02-19 21:38:05 @creffett slightly better than the last vote :P
+2014-02-19 21:38:06 @creffett motion passes.
+2014-02-19 21:38:15 @creffett next up: open floor
+2014-02-19 21:38:16 * creffett first
+2014-02-19 21:38:40 @creffett I've gotten private comments from about half of you telling me that you don't think other people are good fits for the team, should be on the team, etc.
+2014-02-19 21:38:43 @creffett I don't care :)
+2014-02-19 21:39:01 @creffett if you don't like someone on the team, you may work it out with them privately
+2014-02-19 21:39:06 @creffett you are also welcome to leave the team
+2014-02-19 21:39:29 @creffett but if you want to be on the team, you play nice in the sandbox
+2014-02-19 21:39:44 @creffett since I get tired of feeling like I'm the most mature person here when I'm pretty sure I'm one of the youngest.
+2014-02-19 21:39:50 * creffett done
+2014-02-19 21:39:55 @creffett anyone else have anything for open floor?
+2014-02-19 21:40:06 @TomWij (wired: I would agree with this being policy for new USE flags (some new toolkit or so), but not for existing USE flags; I think there's some difference in the details here, however, if needed we can just vote on this some point in the future. I doubt even whether people would read our QA policy / recommendation when introducing such USE flags; neither do I see us run after the other cases in the tree
+2014-02-19 21:40:06 @TomWij claiming its policy to do it that way, we've got better things to do...)
+2014-02-19 21:41:04 @wired TomWij: yeah, I don't expect current packages to just switch things that are working fine because of us, but if something like the gtk situation occurs I would expect them to properly follow our policy
+2014-02-19 21:42:00 * creffett twiddles
+2014-02-19 21:42:08 @creffett nobody have issues to bring up?
+2014-02-19 21:42:29 @wired I'm good
+2014-02-19 21:42:36 * creffett has nothing
+2014-02-19 21:42:47 * Tommy[D] has nothing
+2014-02-19 21:43:21 @creffett ulm, Pinkbyte, zlogene, TomWij: any issues?
+2014-02-19 21:43:32 @zlogene nothing
+2014-02-19 21:43:32 @creffett (also, audience, you're welcome to bring stuff up right now)
+2014-02-19 21:43:33 @ulm what should be the policy if a package needs gtk, but can link against gtk2 or gtk3
+2014-02-19 21:43:46 @ulm only one use flag needed in that case?
+2014-02-19 21:43:58 @creffett ulm: uhhh
+2014-02-19 21:43:58 @creffett hmm
+2014-02-19 21:44:17 @creffett can you give an example of a package which links against either without caring?
+2014-02-19 21:44:17 @TomWij creffett: Wrt those private messages, I hope people would raise that with the respective persons or bring it out in public if it's for a good enough reason; everyone sees the good and bad in other people, but as long as it's not overly bad in general it be should be fairly well okay. And sometimes even something you might consider bad about another person might be that persons strongest point.
+2014-02-19 21:44:19 @wired ulm: it can link to either?
+2014-02-19 21:44:26 @ulm yep
+2014-02-19 21:44:31 @ulm IUSE="gtk gtk3" plus REQUIRED_USE is awful
+2014-02-19 21:44:33 @wired USE="gtk gtk3"
+2014-02-19 21:44:38 @creffett I would imagine that most packages will depend specifically on one
+2014-02-19 21:44:41 @Pinkbyte ulm, but it's the only way
+2014-02-19 21:45:01 @TomWij We've got some people that may seem AFK, but they then participate to the meeting; we've got other people that take action too fast, but that makes things happen; we've got other people that are too careful, but that's sometimes needed too; etc...
+2014-02-19 21:45:01 @Pinkbyte unless maintainer decides to do only gtk3 for example
+2014-02-19 21:45:20 @creffett ulm: I would imagine that it would make a difference which was linked against
+2014-02-19 21:45:23 @creffett ohh
+2014-02-19 21:45:25 @creffett I get it
+2014-02-19 21:45:36 @creffett REQUIRED_USE.
+2014-02-19 21:45:46 @Pinkbyte real world example - net-analyzer/nmap
+2014-02-19 21:45:58 @creffett ooh
+2014-02-19 21:46:10 @ulm but we have another policy that REQUIRED_USE should only be used if a pkg has reverse dependencies
+2014-02-19 21:46:11 @Pinkbyte can link on gtk2,gtk3,qt4 but no more than one of them(or neither)
+2014-02-19 21:46:19 @creffett wait, nmap has a graphical option?
+2014-02-19 21:46:23 @creffett huh.
+2014-02-19 21:46:37 @Pinkbyte meh, blame my stupidness
+2014-02-19 21:46:41 @Pinkbyte wireshark, of course
+2014-02-19 21:46:52 @creffett ulm: we do?
+2014-02-19 21:46:59 @Pinkbyte creffett, and yes, nmap has gui, but only GTK-2 one iirc
+2014-02-19 21:47:37 @ulm creffett:
+2014-02-19 21:48:08 @creffett ulm: I don't read that as saying "only with revdeps"
+2014-02-19 21:48:37 @ulm "In some exceptional cases, above policy would break reverse USE dependencies. To avoid this, the ebuild can specify allowed USE flag combinations with REQUIRED_USE (available in EAPI 4)."
+2014-02-19 21:48:44 @creffett also, right now, qt stuff is using ^^(qt4, qt5) with no problems
+2014-02-19 21:49:14 @ulm that would have been my next question, how does qt handle it
+2014-02-19 21:49:20 @creffett ulm: that's saying "if it breaks revdeps use REQUIRED_USE" but I don't read it as meaning "only use REQUIRED_USE with revdeps"
+2014-02-19 21:49:27 @creffett Pinkbyte: any input on this as a QT guy?
+2014-02-19 21:49:38 @Pinkbyte ulm, REQUIRED_USE is used in tree not only in case of breaking revdeps, but also when package has conflicting build-time options
+2014-02-19 21:49:56 @Pinkbyte creffett, no complains from overlay/in-tree ebuild users
+2014-02-19 21:50:06 dilfridge please dont mandate any REQUIRED_USE, it breaks --autounmask
+2014-02-19 21:50:07 @creffett ^^ sufficient for me
+2014-02-19 21:50:22 @creffett dilfridge: but it's basically the only way to deal with mutually exclusive USE flags
+2014-02-19 21:50:33 @ulm Pinkbyte: it will be annoying for users if there are too many REQUIRED_USE in the tree
+2014-02-19 21:50:37 @Pinkbyte dilfridge, other options for conflicting USE-s?
+2014-02-19 21:50:52 dilfridge it's much saner to just have one useflag override another in a defined way
+2014-02-19 21:50:55 dilfridge imho
+2014-02-19 21:50:55 @ulm see the Note below in the devmanual
+2014-02-19 21:51:02 @creffett yes, I see the note
+2014-02-19 21:51:05 @Tommy[D] i also prefer to keep the amount of REQUIRED_USE as low as possible, as it raises the amount of work on users side
+2014-02-19 21:51:09 @creffett but I'm open to better ideas
+2014-02-19 21:51:12 dilfridge I would even recommend to deprecate REQUIRED_USE in a future EAPI again
+2014-02-19 21:51:13 @ulm "Note: In order to avoid forcing users to micro-manage flags too much, REQUIRED_USE should be used sparingly. Follow the normal policy whenever it is possible to do a build that will presumably suit the user's needs."
+2014-02-19 21:51:17 @Pinkbyte ulm, true. But hiding things from user applying some default when both USE are disabled/enabled is sometimes even worse
+2014-02-19 21:51:46 @creffett I mean, the other option I see is preferring latest gtk USE flag by default and printing a message saying "you picked both but only one allowed, defaulting to gtk3"
+2014-02-19 21:51:55 @ulm dilfridge: it has its use cases, but should be used sparingly
+2014-02-19 21:52:01 @creffett but the whole point of REQUIRED_USE is to get around that sort of thing
+2014-02-19 21:52:02 @Tommy[D] Pinkbyte: you can still einfo your settings to the user
+2014-02-19 21:52:10 @Pinkbyte ulm, it makes a beatiful mess in DEPEND syntax that blows my mind. When we are talking about two USE-flags - it's ok
+2014-02-19 21:52:11 dilfridge ... and in a future EAPI replace it with something like "WARN_USE" combined with a message
+2014-02-19 21:52:21 @Pinkbyte when they are three, four, infinity - it's huge, massive PITA
+2014-02-19 21:53:27 @ulm getting USE flags right with REQUIRED_USE is a NP complete problem, BTW ;)
+2014-02-19 21:53:33 @creffett I personally am okay with the use of REQUIRED_USE to indicate conflicting flags
+2014-02-19 21:54:09 @Pinkbyte ulm, we can use REQUIRED_USE with USE-enabled default
+2014-02-19 21:54:15 @Tommy[D] ulm: if you say it needs gtk, the only thing on userside is choosing, i would suggest to select the upstream preferred by default and adding a useflag for the other one to choose as alternative
+2014-02-19 21:54:35 @Pinkbyte ulm, so, things are not THAT bad
+2014-02-19 21:55:03 @Pinkbyte but some badness still happens, yes. user doing USE="gtk gtk3" in make.conf - and screwed
+2014-02-19 21:55:17 @creffett do we need a decision on this now, or are we okay with putting it off until later?
+2014-02-19 21:55:32 @ulm creffett: I don't need a decision
+2014-02-19 21:55:40 @creffett all right
+2014-02-19 21:55:46 @ulm just wnated to make you aware that this problem exists
+2014-02-19 21:55:52 @ulm *wanted
+2014-02-19 21:56:09 @creffett mhm, I'm aware, but I think this gets at a bigger issue of REQUIRED_USE in general
+2014-02-19 21:56:16 @creffett and I don't want to open that one up right now ;)
+2014-02-19 21:56:23 @Pinkbyte creffett, let's clarify is any change are going to happen from GNOME team. And if they asks - let's speak about this with all pros and cons.
+2014-02-19 21:56:48 @creffett Pinkbyte: we've made a policy, so yes, we expect them to follow it
+2014-02-19 21:57:34 * creffett will handle the meeting notes and announcements tonight
+2014-02-19 21:57:42 @creffett all in favor of closing the meeting?
+2014-02-19 21:58:47 @creffett glad you all agree
+2014-02-19 21:58:47 @wired ++
+2014-02-19 21:58:49 * creffett bangs the gavel
+2014-02-19 21:58:49 @Tommy[D] another vote :D
+2014-02-19 21:58:51 @creffett bye
+2014-02-19 21:58:52 @creffett :P
+2014-02-19 21:58:53 @Tommy[D] yes :)
+2014-02-19 22:00:01 @zlogene good night to all :)
+2014-02-19 22:00:09 @TomWij Well, we already had the vote last time; and since it is 22:00 now, the meeting is closed. :D
+2014-02-19 22:00:36 * TomWij mumbles "right on time!".
+2014-02-19 22:01:17 @Pinkbyte TomWij, cheater! :-). Anyway, thanks guys, it was interesting(as usual).
+2014-02-19 22:01:57 @zlogene wow, 01.07. Time go in bed :p
+2014-02-19 22:01:58 @Pinkbyte creffett, as you are still here, KDE meeting will be tomorrow?
+2014-02-19 22:02:23 @creffett Pinkbyte: yes
+2014-02-19 22:02:31 @creffett I may be a little late to it, though...should warn the team
+2014-02-19 22:02:59 @zlogene creffett: you are busy man :)
+2014-02-19 22:03:09 @ulm hm, gtk3 isn't even a global USE flag
+2014-02-19 22:03:39 @ulm used by 27 packages
+2014-02-19 22:03:39 @Pinkbyte ok, maybe i will be as a guest. I look like wandering from meeting to meeting, when i need to sit and appoint the damn Qt one :-(
+2014-02-19 22:04:48 * TomWij wonders if Zero_Chaos is doing another awesome presentation.
+2014-02-19 22:14:02 @creffett so, my policy changes are "use=multislot dies" "changes to gtk flags" and "general recommendations about versioned flags"
+2014-02-19 22:14:04 @creffett did I miss anything?
+2014-02-19 22:15:43 @creffett and "we recommend eapi 1 banned, 0/3 deprecated"
+2014-02-19 22:17:02 @ulm that's what I remember, too
+2014-02-19 22:18:17 @TomWij Yeah, four agenda items; one delayed, the 3 other you covered; nothing in the open floor afaik, that should be it.
diff --git a/meeting-logs/20140319.txt b/meeting-logs/20140319.txt
new file mode 100644
index 0000000..1679b88
--- /dev/null
+++ b/meeting-logs/20140319.txt
@@ -0,0 +1,144 @@
+2014-03-19 20:04:29 @wired ohai?
+2014-03-19 20:06:11 * Pinkbyte stares on creffett
+2014-03-19 20:06:38 @Tommy[D] [01:03:00] <creffett> I can't make tomorrow's meeting at all (or if I can, I will be rather late), I have an exam at the time
+2014-03-19 20:07:21 * zlogene is here
+2014-03-19 20:07:47 @Pinkbyte ok
+2014-03-19 20:07:52 * Pinkbyte stares on TomWij
+2014-03-19 20:07:59 @zlogene but busy with stydyin too
+2014-03-19 20:08:00 @Pinkbyte Deputy Lead, your word?
+2014-03-19 20:08:17 * TomWij is here.
+2014-03-19 20:08:55 @TomWij
+2014-03-19 20:08:58 @TomWij !herd qa
+2014-03-19 20:09:00 willikins TomWij: (qa) (Gentoo Quality Assurance) is not a herd. For a semi complete listing of people on that team visit
+2014-03-19 20:09:09 @TomWij Right, this thing again; moment... :D
+2014-03-19 20:09:27 @Tommy[D] !expn qa
+2014-03-19 20:09:29 willikins Tommy[D]: qa = (private)
+2014-03-19 20:09:31 @zlogene TomWij: qa is private anyway :D
+2014-03-19 20:09:34 @Pinkbyte )))
+2014-03-19 20:10:09 @TomWij creffett, patrick, Pinkbyte, TomWij, Tommy[D], ulm, WilliamH, wired, Zero_Chaos, zlogene: Everybody here?
+2014-03-19 20:10:18 * wired o/
+2014-03-19 20:10:22 * zlogene is here
+2014-03-19 20:10:34 @TomWij bonsaikitten: Here?
+2014-03-19 20:10:35 @Pinkbyte \o/
+2014-03-19 20:11:54 @TomWij If I see correctly Chris, Patrick, Ulrich, William and Rick are absent at this point.
+2014-03-19 20:12:21 @TomWij Anyone wants to do the meeting; if not, I guess I'll take it on my plate (though I'm certainly not used to it).
+2014-03-19 20:13:33 @zlogene 4 of 10
+2014-03-19 20:13:35 @zlogene hmm
+2014-03-19 20:14:10 @Pinkbyte no quorum at all, i am for reassigning meeting time
+2014-03-19 20:14:31 * WilliamH is here late
+2014-03-19 20:14:36 @wired yeah the stats are not good today, are people out to watch Champions League or sth? :p
+2014-03-19 20:14:54 @zlogene I am too, as for me i am busy right now
+2014-03-19 20:14:55 @WilliamH I'm fine with reassigning meeting time too.
+2014-03-19 20:14:56 @TomWij 6 of 10; 6 here, 4 absent; yeah, maybe we can just discuss the first agenda point.
+2014-03-19 20:15:01 @TomWij "Rotating meeting times/other ways to get everyone to be able to make a meeting"
+2014-03-19 20:15:03 @Tommy[D] maybe the rest is watching Chris? :D
+2014-03-19 20:15:37 @zlogene !seen creffett
+2014-03-19 20:15:37 willikins zlogene: creffett was last seen 16 hours, 37 minutes and 56 seconds ago, joining #gentoo-dev
+2014-03-19 20:15:46 @Tommy[D] i see no point in chaning the meeting time to a different time where less people can make it
+2014-03-19 20:15:56 @WilliamH I thought I saw him say he has an exam or something
+2014-03-19 20:16:03 @Tommy[D] zlogene: he wrote around 19 hours ago, that he cannot make it
+2014-03-19 20:16:40 @Pinkbyte well, current time is not ideal for me, but i doubt that we could choose better one that fits everybody
+2014-03-19 20:16:47 @TomWij Rick and Patrick consistently can't make it, afaik; and with the time shift, it's a problem for Chris too. So, maybe we should set up a whenisgood to figure out better times?
+2014-03-19 20:16:59 @WilliamH Right, I think we are spread pretty far across time zones?
+2014-03-19 20:17:18 @Tommy[D] TomWij: we did already have a setup there and this was afaik the best time to get most people on board
+2014-03-19 20:17:50 @Tommy[D] you cant get everyone together, if some are in europe, someone in china and somone in the west of the us
+2014-03-19 20:18:16 @TomWij Yeah, in China it's 03:18 now or so.
+2014-03-19 20:18:19 @wired perhaps we can alternate our meeting times
+2014-03-19 20:18:29 @zlogene !time Pinkbyte
+2014-03-19 20:18:30 willikins zlogene: Europe - Moscow - Wed Mar 19 23:18 MSK
+2014-03-19 20:18:40 @WilliamH !time williamh
+2014-03-19 20:18:41 willikins WilliamH: America - Chicago - Wed Mar 19 14:18 CDT
+2014-03-19 20:18:53 @Tommy[D] wired: other times mean even less people can make it there, so even higher chance we dont even get half of the team to the meeting
+2014-03-19 20:18:54 @zlogene !time Zlogene
+2014-03-19 20:18:54 willikins I don't know where zlogene is, (s)he should use !time set <Continent>/<City> to let me know
+2014-03-19 20:19:04 @zlogene !time zlogene
+2014-03-19 20:19:04 willikins I don't know where zlogene is, (s)he should use !time set <Continent>/<City> to let me know
+2014-03-19 20:19:12 @TomWij wired: Yes, something like two meetings in the same day or in the same week might work.
+2014-03-19 20:19:12 @zlogene lolwhat?
+2014-03-19 20:20:09 @wired and we can always let missing people vote over mail the next day for important issues if we are not enough present
+2014-03-19 20:20:17 @zlogene in short, i live in Europe/Moscow and curent time is not ok for me
+2014-03-19 20:20:25 @Tommy[D] TomWij: how do you want to organize that? especially, since the first group is then expected to vote without the comments from the second one
+2014-03-19 20:20:25 @wired killed that sentence \o/
+2014-03-19 20:20:52 @wired we can make a second attempt to find a good time using that website
+2014-03-19 20:21:06 @wired just in case people have different schedules now
+2014-03-19 20:21:46 @WilliamH wired: I'm not sure anyone's schedules are going to be that different, I think we are just spread too far across timezones...
+2014-03-19 20:21:47 @TomWij Tommy[D]: Voting over mail might be an option.
+2014-03-19 20:21:56 @Tommy[D] wired: unless someone moved his home, i would not expect it :)
+2014-03-19 20:22:32 @wired well, my schedule is even lighter these days
+2014-03-19 20:22:50 @TomWij Like, have the two meetings; then after that the motions are spread by mail and everyone mails their response within 24h or so.
+2014-03-19 20:22:57 @wired for one, although I had a flexible schedule to begin with
+2014-03-19 20:22:57 @Tommy[D] TomWij: we could have a majority meeting, get the log to the alias and allow the rest to vote, if needed, via mail
+2014-03-19 20:23:11 @wired Tommy[D]: that's what I was thinking as well
+2014-03-19 20:23:14 @wired for important stuff anyway
+2014-03-19 20:24:10 @Pinkbyte Tommy[D], yeah, at least more coverage for voting is good. Quorum is sufficient, but, hell, missing guys should also have opportunity at least to vote
+2014-03-19 20:24:10 @zlogene !rime Europe/Moscow
+2014-03-19 20:24:17 @zlogene !time Europe/Moscow
+2014-03-19 20:24:17 willikins zlogene: Europe - Moscow - Wed Mar 19 23:24 MSK
+2014-03-19 20:24:30 @zlogene !botsnack
+2014-03-19 20:24:30 @TomWij Hmm, anyone knows how to pull IRC statistics; could see when people talk here often and deduce activity from that.
+2014-03-19 20:24:30 willikins zlogene: schweet!
+2014-03-19 20:24:43 @wired TomWij: I have stats for gentoo-dev
+2014-03-19 20:24:53 @Pinkbyte zlogene, if you want to set time in willikins, you are doing it wrong ;-)
+2014-03-19 20:25:04 @Pinkbyte i mean, timezone, of course )
+2014-03-19 20:25:16 @wired
+2014-03-19 20:25:27 @TomWij wired: Ah, feel free to share; but, I'm thinking along the line of just grepping the individuals and chart their time presence.
+2014-03-19 20:25:27 @Tommy[D] TomWij: i would be carefull about such stats, i might shortly write a comment/line via IRC, but that should not imply i have an hour or two for a meeting ;)
+2014-03-19 20:26:01 @wired 1664 days xD
+2014-03-19 20:27:05 @Pinkbyte "Poor bonsaikitten, nobody likes him/her. He/She was attacked 5 times." - i lol'd
+2014-03-19 20:27:26 @TomWij Tommy[D]: Yeah, needs to be aggregated rather than boolean.
+2014-03-19 20:27:49 @zlogene Pinkbyte: he reset my timezone again and again :(
+2014-03-19 20:28:41 @wired so, lets keep the current meeting time for now and discuss it again over mail?
+2014-03-19 20:29:06 @Pinkbyte fine by me
+2014-03-19 20:29:28 @Tommy[D] fine with me
+2014-03-19 20:29:51 @Tommy[D] zlogene: sure you simply did not set your timezone details with the bot? :)
+2014-03-19 20:31:47 @TomWij wired: Yes, discussing it on mail gives some room to think this through; the options that I see come up afaik: 1) Another whenisgood to see if schedules have changed. 2) Multiple meetings, though that can be an organization problem (different motions, ...). 3) Alternating time meetings, though a meeting with less persons can be a quorum problem. 4) Keep things the way they are, expect absent people to mail
+2014-03-19 20:31:47 @TomWij their opinion / comment / votes; though, this is less fair if they do want to actively talk.
+2014-03-19 20:32:22 @wired I don't like having two meetings, sounds weird.
+2014-03-19 20:32:48 @wired but lets continue this discussion over mail, we need to talk with all members of the team
+2014-03-19 20:33:53 @zlogene !time set Europe/Moscow
+2014-03-19 20:33:53 willikins Ok, I'll remember that zlogene is on the Europe/Moscow time zone
+2014-03-19 20:34:08 @zlogene Pinkbyte: thanks for note
+2014-03-19 20:34:39 @TomWij I count 4 of 6 that vote we discuss this over mail, let's do that then; then we just close this meeting and I guess we can organize another meeting in one or two weeks?
+2014-03-19 20:35:17 @TomWij Probably want to do the actual planning on when to do that meeting in a week or so after we've got feedback and/or an idea on mail.
+2014-03-19 20:36:06 @wired oh, we were discussing about dropping this meeting as well? I'm in, just didn't realize it
+2014-03-19 20:36:45 @TomWij Looking at the other agenda items, there doesn't seem to be anything that important; we need to follow up on the GTK flag issue and Zero_Chaos stable dropping policy feedback, such that we have data on that by next meeting.
+2014-03-19 20:37:34 @wired I recommend we tentantively set the next meeting date to next week's Wednesday and try to figure out if we want to change it over email the next few days
+2014-03-19 20:37:35 @TomWij wired: Someone mentioned it early, given the count is low; 6 people are here (with zlogene studying), ...
+2014-03-19 20:38:06 @Tommy[D] so raise a mail about meeting time and remind Rick about his feedback, i would also suggest to set him a limit like beginning of next meeting for his feedback, so he cannot dely the policy forever
+2014-03-19 20:38:19 @wired ++
+2014-03-19 20:38:52 @TomWij ++
+2014-03-19 20:38:59 @zlogene +
+2014-03-19 20:39:02 @WilliamH TomWij: I'm still working on the email for the gtk issue, I'll have it ready for the team to look over before next week.
+2014-03-19 20:39:51 @WilliamH TomWij: I got your email and the one from creffett; I am going to come up with an email that puts ideas from both of them together.
+2014-03-19 20:40:31 @TomWij WilliamH: Are you still here? If I remember correctly, were you the person that planned to send a mail regarding the GTK flag issue; how far are we on that? I also remember the GNOME team writing something up, EvaSDK in particular; haven't seen it yet, but I suppose that's intended to be in response of that mail.
+2014-03-19 20:40:47 @TomWij Didn't look at the screen while typing that. :D
+2014-03-19 20:41:07 @TomWij Okay, sounds good; thank you in advance.
+2014-03-19 20:41:24 @WilliamH TomWij: No problem.
+2014-03-19 20:42:45 @Tommy[D] TomWij: so will you write the mail about meeting time and the reminder for Rick?
+2014-03-19 20:42:55 @TomWij Let's close the meeting then; I'll send up a mail based on Tommy's statement, when we meet again depends on whether the mail will cause a change.
+2014-03-19 20:43:20 @wired cheers
+2014-03-19 20:44:24 @Tommy[D] so meeting closed and good evening/whatever it currently is in your timezone :)
+2014-03-19 20:45:06 @wired 2145 here ;p
+2014-03-19 20:45:14 @WilliamH 14:45 here ;-)
+2014-03-19 20:45:21 @TomWij 20:45
+2014-03-19 20:45:28 @zlogene 23.51
+2014-03-19 20:46:02 @zlogene ehehe
+2014-03-19 20:46:40 @Tommy[D] zlogene: you win/loose (choose as you wish), you have the highest number :D
+2014-03-19 20:47:12 @Tommy[D] !time
+2014-03-19 20:47:12 willikins Tommy[D]: Europe - Berlin - Wed Mar 19 20:47 CET
+2014-03-19 20:47:21 @Tommy[D] ah, good, still works :)
+2014-03-19 20:47:59 @zlogene Tommy[D]: Pinkbyte live in the same timezone with me :D
+2014-03-19 20:48:28 @Tommy[D] zlogene: so sadly you have to share your price with him :)
+2014-03-19 20:48:51 @TomWij The two Tom(my)'s are in the same time zone. ^^
+2014-03-19 20:50:29 @Tommy[D] TomWij: so you will never have a price for yourself alone either :p
+2014-03-19 20:51:50 @wired !time
+2014-03-19 20:51:51 willikins wired: Europe - Athens - Wed Mar 19 21:51 EET
+2014-03-19 20:52:08 @zlogene !time
+2014-03-19 20:52:08 willikins zlogene: Europe - Moscow - Wed Mar 19 23:52 MSK
+2014-03-19 20:52:28 @wired well I'm a bit to the north atm, but OK
+2014-03-19 20:52:33 @wired same timezone :p
+2014-03-19 21:25:07 @ulm sorry I've missed the meeting
+2014-03-19 21:29:26 @zlogene ulm: don't worry, we could not make meeting
+2014-03-19 21:30:25 @ulm yeah, because of other slackers like me :/
+2014-03-19 21:30:29 @TomWij Mail sent.
+2014-03-19 22:53:13 @creffett ulm: don't worry, I missed it too :P
diff --git a/meeting-logs/20140326.txt b/meeting-logs/20140326.txt
new file mode 100644
index 0000000..c17620a
--- /dev/null
+++ b/meeting-logs/20140326.txt
@@ -0,0 +1,411 @@
+2014-03-26 19:49:57 * zlogene is here, already
+2014-03-26 19:53:11 * zlogene take chocolate ice cream with cherry and waiting for meeting start
+2014-03-26 19:53:29 * TomWij just ate chocolate and goes for a drink.
+2014-03-26 19:59:40 * Zero_Chaos is here
+2014-03-26 20:00:27 @creffett|irssi k, showtime.
+2014-03-26 20:00:38 * ulm here
+2014-03-26 20:00:40 @WilliamH ok you should get the email
+2014-03-26 20:00:45 @WilliamH qa team...
+2014-03-26 20:00:57 * WilliamH is here
+2014-03-26 20:00:59 * TomWij is here
+2014-03-26 20:01:22 * Tommy[D] didnt miss his own reminder
+2014-03-26 20:01:32 @creffett|irssi wired, Pinkbyte, bonsaikitten: you all here?
+2014-03-26 20:01:45 * Pinkbyte here
+2014-03-26 20:02:18 @creffett|irssi close enough.
+2014-03-26 20:02:36 @creffett|irssi first question: do we want to do rotating meeting times? I know this time doesn't work for everyone
+2014-03-26 20:02:36 @TomWij (Agenda @
+2014-03-26 20:03:11 @Zero_Chaos creffett|irssi: wednesday are almost always bad for me, especially in the middle of the work day. so I have to vote for rotating meetings.
+2014-03-26 20:03:33 @creffett|irssi Zero_Chaos: I agree, especially when this summer comes and I actually have a job to keep
+2014-03-26 20:04:14 @creffett|irssi so how will we want to handle that is the real question--do we want to go for discussion-only during meetings and voting some other way? vote during meetings and if you can't make it too bad? what?
+2014-03-26 20:04:27 @creffett|irssi (also, I will fire up a whenisgood so we can find another good time)
+2014-03-26 20:04:41 @Pinkbyte creffett, what about shifting meeting time to saturday or sunday?
+2014-03-26 20:04:41 @Tommy[D] i disagree, we already checked, when most people have time and even then, see last week, we have problems get enough people together
+2014-03-26 20:04:45 @TomWij I wouldn't mind if they were rotating, giving everyone a fair chance to attend; though, the only concern I have here is when times get picked where not a sufficient quorum can attend.
+2014-03-26 20:04:54 @Tommy[D] other times will make it even harder to even get half of qa together
+2014-03-26 20:05:19 @creffett|irssi Tommy[D]: then what would you prefer we do with the handful of people who can't/rarely can make the current time
+2014-03-26 20:05:27 * WilliamH agrees with Tommy[D]
+2014-03-26 20:05:32 @zlogene what about make meeting on Saturday/Sunday
+2014-03-26 20:05:35 @zlogene ?
+2014-03-26 20:06:02 @Tommy[D] creffett|irssi: pretty simple: normal meetings/votes like now and we dont get a majority, let the rest vote via mail within e.g. 48 hours after announcing open vote on the alias
+2014-03-26 20:06:06 * WilliamH isn't opposed to a weekend meeting...
+2014-03-26 20:06:17 @ulm I'm against meeting on weekends too
+2014-03-26 20:06:27 * TomWij isn't opposed to a weekend meeting either.
+2014-03-26 20:06:35 @Tommy[D] weenends is pretty bad, i often cant say when/if i have time then
+2014-03-26 20:07:27 @Zero_Chaos honestly I have more freetime if we shift this +5-6 hours
+2014-03-26 20:07:28 @creffett|irssi the issue here is that we pretty effectively span the globe
+2014-03-26 20:07:32 @Tommy[D] in addition i like it to have sometimes a day for myself without any meetings/work ;)
+2014-03-26 20:07:34 @creffett|irssi no matter when we pick, someone suffers
+2014-03-26 20:07:34 @Zero_Chaos but then everyone else is alseep
+2014-03-26 20:08:14 @zlogene so, i agree with pinkbyte about weekend
+2014-03-26 20:08:18 @Tommy[D] creffett|irssi: so the best we can get is like we do now: get the majority together, let the rest vote in addition, if needed for a majority vote
+2014-03-26 20:08:44 @Tommy[D] we cannot make it right for everyone and shifting times make it very likely we would not even get half of qa team together
+2014-03-26 20:09:27 @creffett|irssi yeah.
+2014-03-26 20:09:28 @TomWij creffett|irssi: We could 1) vote right now on making it rotating or not, 2) do a doodle to pick the preferred day of the week and 3) do another whenisgood to see if there is perhaps a better hour than 1900 UTC due to changed schedules.
+2014-03-26 20:09:42 @Tommy[D] Zero_Chaos: nothing against you personally, but seems like you got the worst timezone together with Patrick
+2014-03-26 20:09:56 @Pinkbyte Tommy[D], yep, seems the better decision. And 48h timeframe for voting can be extended a bit. Let's see, we have meeting at wednesday. Let's say, that majority should be there and other should vote till next Monday
+2014-03-26 20:09:57 @creffett|irssi Tommy[D]: I'm in Zero_Chaos's timezone :P
+2014-03-26 20:10:05 @Zero_Chaos Tommy[D]: I'm actually the same timezone as creffett|irssi, just I have a job :-P
+2014-03-26 20:10:11 @creffett|irssi ^^
+2014-03-26 20:10:45 @zlogene !time zlogene
+2014-03-26 20:10:45 willikins zlogene: Europe - Moscow - Wed Mar 26 23:11 MSK
+2014-03-26 20:11:09 @creffett|irssi I would like to try another whenisgood just to check if the DST shift (for those affected by it) has opened up a better time
+2014-03-26 20:11:38 @Tommy[D] Zero_Chaos: even then, if we take you 2 out, we still have 6 out of 10, who can make it, any other time will have even lower numbers and we need 6 to get a majority vote....
+2014-03-26 20:12:04 @creffett|irssi and for the future, I think our best bet will unfortunately be to have people send in their opinions beforehand if they can't make it, and conduct email votes if we don't have a majority
+2014-03-26 20:12:12 @Zero_Chaos Tommy[D]: I agree, but it is kinda shitty to plan every meeting to miss 40% of the team.
+2014-03-26 20:12:26 @Zero_Chaos creffett|irssi: I think possibly voting by list is a good idea.
+2014-03-26 20:12:38 @Tommy[D] Zero_Chaos: its not good, but still better to plan with 60% missing
+2014-03-26 20:12:59 @Tommy[D] *still better then to plan with 60% missing
+2014-03-26 20:13:05 @Zero_Chaos Tommy[D]: rotating meeting times to always catch at least 6 but miss different people wouldn't hurt.
+2014-03-26 20:13:09 @Zero_Chaos if possible anyway
+2014-03-26 20:13:39 @creffett|irssi I'll look into that too, if there's a different time which has >=6 on whenisgood then we can consider rotating to that occasionally
+2014-03-26 20:13:48 @Tommy[D] Zero_Chaos: thats the point: if possible, keep in mind that current schedule was the best matching time for all and we have problems getting a majority at the best time....
+2014-03-26 20:14:28 @creffett|irssi Tommy[D]: let's see how the whenisgood turns out
+2014-03-26 20:14:35 @Zero_Chaos accepted
+2014-03-26 20:14:42 @creffett|irssi next topic.
+2014-03-26 20:14:46 @WilliamH creffett|irssi: sounds reasonable to me.
+2014-03-26 20:14:57 @creffett|irssi vapier stabilizing on experimentals: do we care? what do we want to do, if we do care?
+2014-03-26 20:15:04 @Tommy[D] creffett|irssi: i suggest you create it, send a mail after meeting and we can discuss via mail once its done
+2014-03-26 20:15:15 @Zero_Chaos creffett|irssi: please provide background
+2014-03-26 20:15:15 @creffett|irssi Tommy[D]: I was planning on that
+2014-03-26 20:15:23 @creffett|irssi WilliamH: I think this was yours
+2014-03-26 20:15:26 @creffett|irssi (the vapier thing)
+2014-03-26 20:15:29 @TomWij +1 on whenisgood
+2014-03-26 20:15:29 @Tommy[D] any update from council wrt those arches?
+2014-03-26 20:15:37 @WilliamH creffett|irssi: Well, if the archs have exp in their profiles we don't have to care.
+2014-03-26 20:15:56 @Zero_Chaos oh experimental arches?
+2014-03-26 20:15:59 @Zero_Chaos +1 for don't care
+2014-03-26 20:16:28 @WilliamH That's the point of the status in profiles.desc
+2014-03-26 20:16:34 @Zero_Chaos very much so
+2014-03-26 20:16:41 * WilliamH isn't sure about dev status
+2014-03-26 20:16:47 @Zero_Chaos if you are using an experimental profile you get to keep the pieces.
+2014-03-26 20:17:01 @zlogene what should we do if vapier still stabilize for this?
+2014-03-26 20:17:09 @Zero_Chaos and if it ever moves up to a stable profile, less work if they were already following a stabilization policy (of some kind)
+2014-03-26 20:17:11 @zlogene revert, or no?
+2014-03-26 20:17:17 @WilliamH zlogene: nothing if the profiles are in the right status
+2014-03-26 20:17:20 @creffett|irssi zlogene: I'm still unclear if it even matters to us
+2014-03-26 20:17:26 @Pinkbyte zlogene, as said - if the whole arch profiles are 'exp' - just do not care
+2014-03-26 20:17:34 @zlogene okay
+2014-03-26 20:17:39 @Pinkbyte if repoman -d does not throw warnings - forget about this
+2014-03-26 20:17:48 @TomWij +1 for don't care; I think I've said earlier that the lack of stage3 makes it experimental to users anyway, and when it gets out of experimental we expect the arch team to properly make sure it is stable.
+2014-03-26 20:18:12 @Pinkbyte TomWij, the culprit is that some of those arches are not exp, they are dev
+2014-03-26 20:18:13 @Zero_Chaos sounds like TomWij summed up the majority favor
+2014-03-26 20:18:16 @zlogene +1 for don't care then
+2014-03-26 20:18:22 @Zero_Chaos Pinkbyte: dev we care.
+2014-03-26 20:18:26 @Pinkbyte i mean arch profiles of course
+2014-03-26 20:18:29 @Zero_Chaos I think we have to care on dev
+2014-03-26 20:18:33 @creffett|irssi then what do we do about dev?
+2014-03-26 20:18:44 @Zero_Chaos creffett|irssi: what specifically was done?
+2014-03-26 20:18:52 @TomWij Pinkbyte: Some of which arches, did vapier stabilize something like that on dev?
+2014-03-26 20:18:54 @creffett|irssi Zero_Chaos: ask WilliamH, this was his issue
+2014-03-26 20:19:09 @Zero_Chaos WilliamH: can you please provide some background on this? I am unfamiliar.
+2014-03-26 20:19:14 @Pinkbyte TomWij, sh is still in dev, right?
+2014-03-26 20:19:21 @Pinkbyte and s390
+2014-03-26 20:19:26 @WilliamH Zero_Chaos: council declared some archis to be unstable then vapier continued stabilizing packages..
+2014-03-26 20:19:34 @zlogene Pinkbyte: yes
+2014-03-26 20:20:14 @WilliamH s390, sh and (I can't find the other one right now)...
+2014-03-26 20:20:16 @Pinkbyte to be 'unstable only' if i understand right
+2014-03-26 20:20:21 @Pinkbyte WilliamH, m68k
+2014-03-26 20:20:22 @Zero_Chaos WilliamH: the profiles have ACCEPT_KEYWORDS="~arch" right?
+2014-03-26 20:20:29 @Pinkbyte Zero_Chaos, yep
+2014-03-26 20:20:42 @TomWij Pinkbyte: Right, I perceived this issue to be about exp only; and the other part, as said above, handled by Council.
+2014-03-26 20:20:54 @ulm Zero_Chaos: is it enough to have ~arch?
+2014-03-26 20:20:55 @WilliamH Zero_Chaos: vapier's point was we shouldn't do that but bump the profiles to exp status in profiles.desc
+2014-03-26 20:21:03 @zlogene Zero_Chaos: ACCEPT_KEYWIRDS="arch ~arch"
+2014-03-26 20:21:06 @ulm Zero_Chaos: for repoman -d not to complain?
+2014-03-26 20:21:08 @zlogene *KEYWORDS
+2014-03-26 20:21:10 @Zero_Chaos then in my head it's masturbation. If you are stabilizing on an arch which lists ACCEPT_KEYWORDS="~arch" then the users will always get ~arch anyway so who cares?
+2014-03-26 20:21:41 @Pinkbyte Zero_Chaos, well, vapier keeps some machines with overrided ACCEPT_KEYWORDS
+2014-03-26 20:21:56 @Zero_Chaos ulm: the council said those arches were not stable, so in my head, it's enough that the profiles list ~arch and that we don't wait on them to stabilize.
+2014-03-26 20:22:01 @Pinkbyte Zero_Chaos, ACCEPT_KEYWORDS="-~s390 s390"
+2014-03-26 20:22:14 @Pinkbyte that's how he do things :-)
+2014-03-26 20:22:15 @WilliamH I tend to agree that the status of theprofile should be switched instead of fooling with accept_keywords.
+2014-03-26 20:22:15 @Zero_Chaos Pinkbyte: that is his choice, and it doesn't affect anyone else in any way.
+2014-03-26 20:22:41 @TomWij Pinkbyte: If he's still doing it on dev profiles after 20130917 council decision (per then I think we can enforce the policy here; but, I'm in doubt whether this is to be considered part of this agenda item.
+2014-03-26 20:22:50 @Pinkbyte WilliamH, then - let's do this
+2014-03-26 20:22:52 @Zero_Chaos WilliamH: making the profile exp instead of dev or stable means that there will be much more inadvertant breakage which we can avoid.
+2014-03-26 20:23:21 @Tommy[D] Who about moving those testing-only arches per council decision to exp profile status or, if preferred, ask council for such decision?
+2014-03-26 20:23:25 @Tommy[D] *how about
+2014-03-26 20:23:27 @Pinkbyte Zero_Chaos, we are talking about arches, that basically have only vapier in arch team
+2014-03-26 20:23:32 @Pinkbyte so, it depends...
+2014-03-26 20:23:45 @Zero_Chaos Pinkbyte: we are here to fight for the users, not to battle vapier for fun.
+2014-03-26 20:23:55 @Zero_Chaos Pinkbyte: I don't care what vapier does if it doesn't affect the users.
+2014-03-26 20:23:59 @creffett|irssi so the choices as I see them are "do nothing" "mark exp ourselves" "punt to council"
+2014-03-26 20:24:01 @WilliamH Zero_Chaos: it also ties in with being able to remove old versions.
+2014-03-26 20:24:03 @creffett|irssi did I miss anything?
+2014-03-26 20:24:30 dilfridge about the arches
+2014-03-26 20:24:33 @Zero_Chaos WilliamH: we don't have to respect his stable keywords since council said those arches do not have stable keywords. so again, who cares.
+2014-03-26 20:24:36 * WilliamH votes punt to council
+2014-03-26 20:24:36 @zlogene i'm interested why vapier still stabilize it
+2014-03-26 20:24:47 @creffett|irssi dilfridge: go ahead
+2014-03-26 20:24:49 dilfridge we had a council decision that all these arches should go exp (suggested by vapier)
+2014-03-26 20:24:56 @Zero_Chaos punting to council is worthless, they haven't enforced anything for years and won't
+2014-03-26 20:24:58 @zlogene make it sense ? If profile have arch ~arch?
+2014-03-26 20:24:58 @Pinkbyte Zero_Chaos, it's a question of support. If only vapier cares about them, then we can not enforce decision that he does not like
+2014-03-26 20:24:59 @Tommy[D] creffett|irssi: additionally would be "force testing keywords, drop stable keywords again"
+2014-03-26 20:25:06 @Zero_Chaos we either make a choice ourselves or stop pretending we care.
+2014-03-26 20:25:06 dilfridge nah,
+2014-03-26 20:25:26 dilfridge the agreement was "all these arches become exp profiles, and noone cares about the stable or not keywords"
+2014-03-26 20:25:27 @TomWij creffett|irssi: It depends on what we consider to be the agenda item: If it's just 'experimental' as listed on the wiki, the choices are limited; if we include 'dev' in that, additional choices come in.
+2014-03-26 20:25:33 @Pinkbyte zlogene, as i said - he maintains his own machines with some like of 'stable' branch
+2014-03-26 20:25:34 @WilliamH wait hold on a second all
+2014-03-26 20:25:38 @ulm dilfridge: right
+2014-03-26 20:25:43 @creffett|irssi Zero_Chaos: what, and you think they'll listen to us? out of the existing decisions we've made, which have actually been listened to?
+2014-03-26 20:25:49 @ulm so we should simply mark them as exp
+2014-03-26 20:26:00 @Zero_Chaos creffett|irssi: nut up man. they can't throw us all out ;-)
+2014-03-26 20:26:18 @WilliamH dilfridge: ok, we had a council decision that the arch's should go exp... we just flip that switch and don't care otherwise...
+2014-03-26 20:26:27 @Tommy[D] dilfridge: have a summay link containing that agreement?
+2014-03-26 20:26:45 @Zero_Chaos again, things are black and white to me. If the profiles are correct and he isn't affecting the users he can stabilize whatever he wants. I'm here to protect users not battle for good form.
+2014-03-26 20:26:47 dilfridge vapier uses the stable keywords for e.g. stage building, and imho as long as they are not annoucned anywhere and the profiles default to ACCEPT_KEYWORDS="arch ~arch", who cares
+2014-03-26 20:27:02 @Zero_Chaos dilfridge: ++
+2014-03-26 20:27:11 @WilliamH bump the profiles to exp and we're done with this item. ;-)
+2014-03-26 20:27:14 @Zero_Chaos this doesn't affect us. this doesn't affect users. I say vote.
+2014-03-26 20:27:25 dilfridge Tommy[D]: I think that's one of the summaries that donnie still has to make
+2014-03-26 20:27:26 @Pinkbyte Zero_Chaos, the key point ' if the profiles are correct'. They are marked 'dev' right now, but it does not reflect the reality.
+2014-03-26 20:27:33 @Pinkbyte let's vote
+2014-03-26 20:27:37 @Zero_Chaos Pinkbyte: dev is fine with me.
+2014-03-26 20:27:38 @creffett|irssi dilfridge: to clarify, the profiles _should_ be marked exp?
+2014-03-26 20:27:45 dilfridge will be marked exp
+2014-03-26 20:27:47 @WilliamH There's nothing to vote on since council made the decision.
+2014-03-26 20:27:54 @Zero_Chaos creffett|irssi: let's try a vote and see where it lands....
+2014-03-26 20:27:55 dilfridge exactly.
+2014-03-26 20:27:56 @Tommy[D] i vote for setting those profiles to exp, allowing everyone to drop stable keywords, let vapier do his keywording and noone gets repoman warnings
+2014-03-26 20:28:19 @Zero_Chaos Tommy[D]: are there repoman warnings now?
+2014-03-26 20:28:33 dilfridge I'm still busy with bumping the whole profile tree to eapi=5, otherwise I'd possbly have done it in the meantime
+2014-03-26 20:28:34 @Tommy[D] Zero_Chaos: should be for dev profiles with repoman -d
+2014-03-26 20:28:49 @Zero_Chaos Tommy[D]: I know how to scan thanks, I said, "Are there warnings now"?
+2014-03-26 20:28:49 @zlogene Tommy[D]: heh, even we'll drop stable keywords vapier will revert us
+2014-03-26 20:28:53 @WilliamH all the council already made the decision on this ;-)
+2014-03-26 20:29:05 @creffett|irssi I vote EDONTCARE, the profiles are set to be marked exp so nothing to do.
+2014-03-26 20:29:15 @Zero_Chaos creffett|irssi: who is marking them exp?
+2014-03-26 20:29:22 @Zero_Chaos creffett|irssi: and on what authority?
+2014-03-26 20:29:24 dilfridge in case of doubt me
+2014-03-26 20:29:34 dilfridge on council decision authority
+2014-03-26 20:29:35 @creffett|irssi Zero_Chaos: sounded like dilfridge either is planninng on it or knows who will be, and on council authority
+2014-03-26 20:29:38 @WilliamH Zero_Chaos: the authority of council
+2014-03-26 20:29:40 @TomWij creffett|irssi: +1 For the original 'experimental' agenda item, my vote is "don't care"; for the 'dev' discussion as above, my vote is "enforce what council decided or let council enforce it if they wish to do so" (which boils down to "don't care" unless council wants us to enforce).
+2014-03-26 20:29:48 @WilliamH Zero_Chaos: as already said
+2014-03-26 20:29:48 @ulm dilfridge: please do
+2014-03-26 20:29:53 @Tommy[D] zlogene: i mean, if we remove an old version (last stable version on that arch), we dont have to wait for that arch and he is free to stable a newer version
+2014-03-26 20:29:57 @Pinkbyte TomWij, +1
+2014-03-26 20:30:03 dilfridge soon... (we have dpg meeting next week... argh...)
+2014-03-26 20:30:09 @Zero_Chaos if the council already said that is what's happening then I'd like to raise creffett|irssi's EDONTCARE with a EWHYAREWEEVENTALKINGABOUTTHIS
+2014-03-26 20:30:22 dilfridge hehe
+2014-03-26 20:30:26 @ulm dilfridge: it's just profiles.desc?
+2014-03-26 20:30:29 dilfridge yes
+2014-03-26 20:30:41 @Pinkbyte Zero_Chaos, as Tommy[D] said - those 'stable' things on sh/s390/m68k slows closing bugs dramatically
+2014-03-26 20:30:44 @Pinkbyte even security ones
+2014-03-26 20:30:53 @Zero_Chaos dilfridge: is there a way to make repoman scan experimental profiles?
+2014-03-26 20:30:56 dilfridge yes
+2014-03-26 20:30:57 @ulm dilfridge: m68k s390 sh?
+2014-03-26 20:31:00 @creffett|irssi Zero_Chaos: repoman -e iirc
+2014-03-26 20:31:05 @Zero_Chaos then yeah, this is super closed for me.
+2014-03-26 20:31:07 dilfridge ulm: yes but better check
+2014-03-26 20:31:13 @creffett|irssi okay, glad we all agree.
+2014-03-26 20:31:15 @creffett|irssi next topic.
+2014-03-26 20:31:40 @Zero_Chaos dilfridge: thanks for the input.
+2014-03-26 20:31:41 @creffett|irssi Zero_Chaos: you're on, issues with dropping-last-stable policy and what you want us to do
+2014-03-26 20:32:03 * ulm reading council log
+2014-03-26 20:32:06 @Zero_Chaos I sent a short mail in response to TommyD, but I can summarize here
+2014-03-26 20:32:23 @zlogene Zero_Chaos: please do it
+2014-03-26 20:32:36 @Zero_Chaos Dropping a keyword from a package, stable or otherwise, will NOT prevent any issues since the user will still have the package installed.
+2014-03-26 20:32:38 @Tommy[D] based on the input from the mail, i suggest the following addition: "if there is no urgency (like security bugs), the developer should follow the policy for removing a package when removing the last stable version or stable keyword from a package"
+2014-03-26 20:32:52 @Zero_Chaos Moreover, the user gets no warning of the issue and still reports bugs, etc.
+2014-03-26 20:32:56 @TomWij (For reference,
+2014-03-26 20:33:24 @Zero_Chaos So I say, follow the package removal policies (since we are removing the package for a given arch) and use the normal masking practice.
+2014-03-26 20:33:43 @Zero_Chaos simply removing keywords *will* cause more issues, not make them go away
+2014-03-26 20:34:04 @creffett|irssi concern: masking drops visibility even lower than dropping to ~
+2014-03-26 20:34:16 @Zero_Chaos masking properly, listing a bug, it might get fixed, or it might get keyword removed, either way, it will stop us from getting bug reports, etc, and the users won't be caught be surprise.
+2014-03-26 20:34:59 @Tommy[D] creffett|irssi: masking will show a warning to users including the mask message, so he has additional 30 days to react / adjust himself to the situation, so that sounds fine with me
+2014-03-26 20:35:03 @ulm m68k/s390/sh dropped to exp
+2014-03-26 20:35:12 @Zero_Chaos creffett|irssi: if a user of a stable system has foobar-1.2 installed and we remove stable keywords from it, the result is invisible if we do not mask it.
+2014-03-26 20:36:00 @Zero_Chaos creffett|irssi: and since this would only happen in the case of extreme situations like security bugs etc, I think the mask will be needed either way.
+2014-03-26 20:36:02 @ulm dilfridge: we really should have timely council summaries
+2014-03-26 20:36:04 @TomWij creffett|irssi: Maybe we need package.stable.mask; though, I think the goal was removal of the ebuild, so package.mask may just work as well and therefore the increased drop in visibility a mask brings is not of concern.
+2014-03-26 20:36:05 @WilliamH If we are going to mask, I would say s/0/60/ for when the policy can start happening.
+2014-03-26 20:36:14 @creffett|irssi Zero_Chaos: good enough for me
+2014-03-26 20:36:16 @WilliamH s/90/60/
+2014-03-26 20:36:47 @WilliamH hrm maybe package.stable.mask...
+2014-03-26 20:36:53 @Tommy[D] WilliamH: i see no point for that, but no real feelings against it either
+2014-03-26 20:36:54 @Zero_Chaos TomWij: I believe package.mask is better, since some users run mixed systems
+2014-03-26 20:37:05 @creffett|irssi Zero_Chaos: did you like Tommy[D]'s suggested wording, or do you have a different preferred way to amend the policy
+2014-03-26 20:37:07 @Pinkbyte WilliamH, no-no-no, please do not
+2014-03-26 20:37:11 @Pinkbyte package.mask
+2014-03-26 20:37:52 * WilliamH reads again
+2014-03-26 20:37:59 @Zero_Chaos creffett|irssi: I don't like his wording, even if there is urgency an entry in package.mask doesn't take much time.
+2014-03-26 20:38:02 @Pinkbyte not package.stable.mask
+2014-03-26 20:38:49 @creffett|irssi Zero_Chaos: then please suggest a wording to vote on
+2014-03-26 20:38:53 @TomWij Zero_Chaos: So, if I understand it right, your suggestion is like replacing "The maintainer may drop ..." by something (we can decide on exact wording) like "The maintainer may mask (to inform the user) and then after 30 days drop ..."?
+2014-03-26 20:38:54 @Zero_Chaos Tommy[D]: can you give an example for something so critical you must remove keywords now instead of adding a package.mask? the effect is the same imho.
+2014-03-26 20:38:59 @Tommy[D] Zero_Chaos: i dont mind a package.mask entry, but for security reasons i would prefer removing that version as fast as possible, especially since it has been around for at least 90 days
+2014-03-26 20:39:31 @Zero_Chaos Tommy[D]: masked is masked though, and you can already remove all other keywords once those arches have newer versions stabilized.
+2014-03-26 20:39:46 @Tommy[D] Zero_Chaos: i dont talk about removing stable keyword in this context, but removing an outdated version, which is last stable version for an unresponsive arch
+2014-03-26 20:39:48 @TomWij Pinkbyte: Yeah, no need for package.stable.mask until there is a real need for that; package.mask suffices after thinking it through.
+2014-03-26 20:39:51 @Zero_Chaos creffett|irssi: one more min to discuss with Tommy[D]
+2014-03-26 20:39:53 @creffett|irssi Tommy[D]: security team has no issue with masking before removal when absolutely necessary
+2014-03-26 20:39:56 @creffett|irssi Zero_Chaos: certainly
+2014-03-26 20:40:04 @Pinkbyte Tommy[D], some core packages i(and base-system) prefer to see masked, rather then removed immediately
+2014-03-26 20:40:22 @Zero_Chaos Tommy[D]: certainly if the vulnerable version only has keywords for one arch, and it's masked on that arch, the user is protected enough?
+2014-03-26 20:40:33 @Pinkbyte Zero_Chaos, definitely
+2014-03-26 20:40:36 @Zero_Chaos Tommy[D]: removing the ebuild won't help the user any further, will it?
+2014-03-26 20:40:45 @Pinkbyte if user unmasks package, than - he knows what he is doing
+2014-03-26 20:40:59 @Pinkbyte and he reads mask message
+2014-03-26 20:41:01 @Zero_Chaos "the developer should follow the policy for removing a package when removing the last stable version or stable keyword from a package"
+2014-03-26 20:41:09 @Zero_Chaos creffett|irssi: ^^
+2014-03-26 20:41:11 @Tommy[D] What is the point in keeping a vulnerable package around? Removal wont affect those, that have it installed and for those installing newly, they should not even think about installing a vulnerable version
+2014-03-26 20:41:12 @TomWij Tommy[D]: I think security migration is faster dealt with by the user if they get a mask message explaining the reason (or pointing to a GLSA) than when it is masked by missing keyword.
+2014-03-26 20:41:40 @Zero_Chaos Tommy[D]: removing a package affects dep calculation with things like dynamic deps, it's a critical issue honestly.
+2014-03-26 20:41:42 @WilliamH Hmm,
+2014-03-26 20:42:00 @Tommy[D] TomWij: as i said: i dont mind an additional mask entry, but see no reason to keep an outdated and vulnerable version around
+2014-03-26 20:42:01 @TomWij Zero_Chaos: That's vague to me, if that's taken literal it would mean a lastrite message; can we avoid like-the-package-removal constructs?
+2014-03-26 20:42:01 @Pinkbyte Tommy[D], look at glibc. Old versions are preserved for some exotic software that breaks with newer glibc(yeah, that shit happens, blame code monkeys that wrote proprietary software)
+2014-03-26 20:42:10 @WilliamH Wouldn't developers be touching profiles/<arch>/package.mask in this case though?
+2014-03-26 20:42:16 @Zero_Chaos WilliamH: yes
+2014-03-26 20:42:21 @Zero_Chaos WilliamH: and I see no issue with that.
+2014-03-26 20:42:24 @Pinkbyte Tommy[D], and base-system guys are strongly against removing glibc ebuilds
+2014-03-26 20:42:37 @WilliamH current policy doesn't allow that; you have to get an arch team member to do it iirc.
+2014-03-26 20:42:40 @Zero_Chaos TomWij: agreed, I think we can safely drop that part...
+2014-03-26 20:42:59 @creffett|irssi WilliamH: but at this point the arch team has been unresponsive
+2014-03-26 20:43:04 @Zero_Chaos WilliamH: our policy is above arch team policy, they will like our improvements.
+2014-03-26 20:43:08 @Tommy[D] Pinkbyte: any existing glibc ebuild has a security issue?
+2014-03-26 20:43:08 @zlogene Pinkbyte: and against bash removing too
+2014-03-26 20:43:09 @creffett|irssi which is why we're dropping last stable in the first place.
+2014-03-26 20:43:15 @creffett|irssi Tommy[D]: several, actually
+2014-03-26 20:43:26 @Pinkbyte Tommy[D], all <2.17 - yes
+2014-03-26 20:44:00 @Zero_Chaos "The developer should follow the policy for removing a package, except for last rites emails, when removing the last stable version or stable keyword from a package."
+2014-03-26 20:44:01 @Tommy[D] for masking: masking in base profile(s) should be enough, any need to do it in specific arch profiles?
+2014-03-26 20:44:07 @TomWij Zero_Chaos: Think you missed it, but I asked earlier whether you meant something like "The maintainer may mask (to inform the user) and then after 30 days drop ..." (instead of "The maintainer may drop ..."), does that miss anything?
+2014-03-26 20:44:55 @Zero_Chaos TomWij: I was trying to not be so wordy, the official removal policy includes a bit more like closing bugzie entries, etc.
+2014-03-26 20:45:29 @Zero_Chaos Tommy[D]: depends if we determine multiple arches slacker at different times. I see no reason why we would so profiles/package.mask should be enough.
+2014-03-26 20:45:40 @TomWij Zero_Chaos: Hmm, okay, without last rites that seems to make sense; I think the reader is smart enough to s/package/ebuild/ for the rest of it.
+2014-03-26 20:45:52 @WilliamH Tommy[D]: let me think about that...
+2014-03-26 20:45:54 @Zero_Chaos TomWij: I sure hope so :-)
+2014-03-26 20:45:57 @TomWij Zero_Chaos: So, if I understand correctly; to fit it in with the current policy, that would be added as a sentence to the end?
+2014-03-26 20:46:04 @Zero_Chaos TomWij: yes
+2014-03-26 20:46:17 @Zero_Chaos creffett|irssi: "The developer should follow the policy for removing a package, except for last rites emails, when removing the last stable version or stable keyword from a package."
+2014-03-26 20:46:26 @creffett|irssi all right.
+2014-03-26 20:46:32 @Zero_Chaos creffett|irssi: I believe we can vote on adding this wording to the end and removing the contest on the page.
+2014-03-26 20:46:36 @creffett|irssi yes
+2014-03-26 20:46:39 @Tommy[D] looks ok to me as an addition
+2014-03-26 20:46:44 @Zero_Chaos Tommy[D]: yessir.
+2014-03-26 20:46:48 @creffett|irssi @all: please vote on Zero_Chaos's amendment
+2014-03-26 20:46:49 * creffett|irssi yes
+2014-03-26 20:46:52 @TomWij (That goes behind the original "The maintainer may drop stable keyword or last stable version, if arch team does not respond within 90 days; if it breaks the dependency tree, then the maintainer has to work with maintainers of depending packages before dropping keyword/last stable version.")
+2014-03-26 20:46:52 * Zero_Chaos is obviously in favor
+2014-03-26 20:47:14 @TomWij +1 on Zero_Chaos amendment.
+2014-03-26 20:47:17 * Pinkbyte votes 'yes'
+2014-03-26 20:47:17 * ulm yes
+2014-03-26 20:47:23 * zlogene yes
+2014-03-26 20:47:23 * WilliamH yes
+2014-03-26 20:47:47 @Zero_Chaos woohoo. thanks for the patience guys, I've been very underwater.
+2014-03-26 20:48:02 @creffett|irssi Zero_Chaos: amend the page at your convenience
+2014-03-26 20:48:09 @Zero_Chaos creffett|irssi: immediately your highness
+2014-03-26 20:48:23 @creffett|irssi next item on the agenda is the gtk email; WilliamH just sent out a draft email, any feedback on that?
+2014-03-26 20:48:49 @Tommy[D] didnt read it yet, i suggest we discuss that mail via mail
+2014-03-26 20:48:59 @Tommy[D] (if there is discussion needed)
+2014-03-26 20:49:10 * creffett|irssi shrugs
+2014-03-26 20:49:15 @creffett|irssi any objections to mail discussion?
+2014-03-26 20:49:35 @WilliamH creffett|irssi: I was a little confused on your last point, I think I got it right though.
+2014-03-26 20:49:37 @Zero_Chaos not I
+2014-03-26 20:49:41 @zlogene no
+2014-03-26 20:49:57 @WilliamH no objections here either.
+2014-03-26 20:50:17 @creffett|irssi good enough for me
+2014-03-26 20:50:20 @TomWij No objections to do discussion on mail, too long to stall meeting.
+2014-03-26 20:50:34 @Pinkbyte creffett|irssi, fine by me. I have read email and see no problems with it. It describes the whole problem and our actions pretty well
+2014-03-26 20:50:56 @ulm e-mail draft looks good to me
+2014-03-26 20:50:58 @creffett|irssi next up: getting other people to help out
+2014-03-26 20:51:01 * zlogene reads now
+2014-03-26 20:51:17 @creffett|irssi the general idea here is a) we're not doing so well in the PR department and b) there are a lot of small issues that could be tackled
+2014-03-26 20:51:43 @Zero_Chaos creffett|irssi: page updated.
+2014-03-26 20:51:57 @creffett|irssi (fixing maintainer-needed bugs, fixing bitrotting bugs that never got a patch applied, hunting some of the existing QA issues like ignored CFLAGS, etc.)
+2014-03-26 20:52:17 @Tommy[D] for a): unless you want to pay some PR agency, probably not much we can do about it :)
+2014-03-26 20:52:46 @creffett|irssi Tommy[D]: well, we could try to stop making decisions that piss off a quarter of the dev community each
+2014-03-26 20:52:50 @TomWij creffett|irssi: Well, I think that overall this boils down to needing more manpower in Gentoo.
+2014-03-26 20:52:59 @creffett|irssi but then we're doing less useful stuff
+2014-03-26 20:53:03 @Pinkbyte and about maintainer-needed... well, they are 'maintainer needed' - everybody can touch them. If nobody did - what we can do? :-)
+2014-03-26 20:53:19 @Tommy[D] the only idea for the small things: a page within QA wiki listing the things any dev could do and maybe seperated, what a user could do to help
+2014-03-26 20:53:35 @Pinkbyte creffett|irssi, the problem is that we do not have easy problems
+2014-03-26 20:53:38 @creffett|irssi Pinkbyte: yes, but nobody does.
+2014-03-26 20:53:39 @TomWij So, (b) is non-QA, unless we, as QA team, want to work on getting more contributors, perhaps QA contributors.
+2014-03-26 20:53:42 @creffett|irssi Pinkbyte: indeed.
+2014-03-26 20:53:47 @WilliamH creffett|irssi: about pissing people off, I don't think we are going to win that battle...
+2014-03-26 20:53:52 @Pinkbyte and serious problems when solved usually hurt somebody
+2014-03-26 20:53:54 @creffett|irssi TomWij: QA contributors would be nice
+2014-03-26 20:53:57 @Tommy[D] creffett|irssi: well, still better then to piss 3 quarter of the dev community :D
+2014-03-26 20:54:07 @TomWij But given a lot of developers are overworked, I don't see us convincing them; it's already a surprise we have ~10 people in the QA team.
+2014-03-26 20:54:09 @WilliamH creffett|irssi: no matter what we do someone is going to be upset.
+2014-03-26 20:54:15 @creffett|irssi WilliamH: correct!
+2014-03-26 20:54:39 @TomWij Hmm ... is it possible to crowd source QA efforts?
+2014-03-26 20:54:56 @TomWij Like not to Gentoo Developers, but extend it to users.
+2014-03-26 20:54:58 @creffett|irssi TomWij: entirely possible, get a few trusted users to bug hunt
+2014-03-26 20:55:36 @creffett|irssi anyway, not expecting results this meeting, just want to get people thinking
+2014-03-26 20:55:38 @Tommy[D] as i said: only option i see is some page listing the simple and open work seperated for devs and users and announcing that page, so that anyone with some free time and willing can open that page and fix some of those things
+2014-03-26 20:55:49 @TomWij The last few bug days (and to small extent bug cleaners project) don't reveal much interest; outside of that, we've got some regulars doing things here and there.
+2014-03-26 20:56:11 @Zero_Chaos I apologize, I have a flight to catch. I also have no ideas how to get us better PR or more help, so see you all later ;-)
+2014-03-26 20:56:18 @creffett|irssi Zero_Chaos: see ya
+2014-03-26 20:56:25 @Tommy[D] see you zero
+2014-03-26 20:57:08 @creffett|irssi actually, I have to run in a few too, so one thing I had to bring up: Pinkbyte, since you were running the multislot issue, would you mind filing bugs against toolchain to give them a friendly reminder?
+2014-03-26 20:57:08 @Pinkbyte Zero_Chaos, ciao
+2014-03-26 20:57:10 * antarus mutters something abuot more automation
+2014-03-26 20:57:10 antarus ;p
+2014-03-26 20:57:33 @WilliamH antarus: heh
+2014-03-26 20:57:43 ssuominen TomWij: system wide use of lto is not supported yet in sense that the toolchain maintainers know it to be broken and not ready for gentoo-x86
+2014-03-26 20:57:53 @Tommy[D] antarus: do it :p
+2014-03-26 20:58:05 @Pinkbyte creffett|irssi, sure. There quite a few of them, i will dig the entire tree, maybe i missed some of them and file apropriate bugs
+2014-03-26 20:58:26 @TomWij creffett|irssi: ^ Tinderbox was also on the agenda; not sure how, but it was skipped; unless we decided out of the meeting to not meet about that, I think it boils down to needing the hardware to do it (and someone to get it automated)?
+2014-03-26 20:58:33 ssuominen TomWij: lto in compiler is just fine but the rest of portage (ie. packages) are not :/
+2014-03-26 20:58:37 @creffett|irssi Pinkbyte: just need three--glibc, gcc, and binutils(?) iirc
+2014-03-26 20:58:40 @creffett|irssi TomWij: whoops
+2014-03-26 20:58:54 @creffett|irssi that one boils down to "no hardware"
+2014-03-26 20:59:00 antarus Tommy[D]: less is more!
+2014-03-26 20:59:11 @creffett|irssi so unless someone plans to give us hardware in the near future, CANTFIX
+2014-03-26 20:59:26 @Pinkbyte creffett|irssi, well, maybe i can
+2014-03-26 20:59:27 @Pinkbyte )))
+2014-03-26 20:59:32 ssuominen TomWij: plus the user has other flags that simply generate invalid code (like -ftree-vectorize for sys-libs/zlib, just to name one example)
+2014-03-26 20:59:33 antarus I have 12 cores and 32GB of ram
+2014-03-26 20:59:36 antarus thats about it
+2014-03-26 20:59:45 ssuominen TomWij: -fweb breaks x264, at least
+2014-03-26 20:59:59 ssuominen TomWij: just treat him as -O3 user :PP
+2014-03-26 21:00:00 @TomWij Better PR can boils down to 1) make sure we take everyone into consideration and 2) making clear we revisit our choices if needed.
+2014-03-26 21:00:16 @TomWij It's not like if we say "tomorrow the tree is pink" that it'll be pink tomorrow. :D
+2014-03-26 21:00:17 @Pinkbyte but it would be VM, 4 cores, 16Gb of RAM
+2014-03-26 21:00:31 @creffett|irssi Pinkbyte: if you want to look into it, feel free :P
+2014-03-26 21:01:01 @Pinkbyte creffett|irssi, well, i can donate resources(that's not the problem). Setting up tinderbox is a different issue
+2014-03-26 21:01:04 antarus if you can design your workloads for the cloud
+2014-03-26 21:01:10 @Pinkbyte even with flameeyes scripts...
+2014-03-26 21:01:10 antarus we have space at rackspace
+2014-03-26 21:01:19 antarus but we pay by the hour
+2014-03-26 21:01:26 antarus and running a big vm 24/7 will eat the budget
+2014-03-26 21:01:39 * creffett|irssi out
+2014-03-26 21:01:44 antarus so you have to do stuff like 'turn vm on, start job, write output to storage, turn vm off'
+2014-03-26 21:01:47 antarus so you are not paying for idle hours
+2014-03-26 21:01:52 @wired hey :p
+2014-03-26 21:02:14 @Tommy[D] wired: that was the last word of the meeting :p
+2014-03-26 21:02:29 @wired heheh
+2014-03-26 21:02:35 @wired meh, sorry
+2014-03-26 21:02:55 @WilliamH wired: lol
+2014-03-26 21:03:09 @zlogene wired, too late:p but hi there :p
+2014-03-26 21:03:24 @TomWij Did someone want to open floor something?
+2014-03-26 21:03:26 @Tommy[D] so summary for the "get more people to work": no fixed content to decide on, feel free to add content via mail on the alias
+2014-03-26 21:04:11 @Tommy[D] summary for the "QA tinderbox": we need the hardware, a concept to use it and someone doing the work for it, so until we got those donated, nothing to vote/discuss on
+2014-03-26 21:04:27 antarus I think you have a fairly annoying catch-22 there
+2014-03-26 21:05:06 @Tommy[D] no openfloor content from me
+2014-03-26 21:05:07 @TomWij Tommy[D]: "get more people to work" I think making things more accessible (a list of all QA work users can help with, and not just autorepoman) is one way to do it; the other I agree.
+2014-03-26 21:05:36 @Pinkbyte Tommy[D], as i said - i can give resources
+2014-03-26 21:05:54 @Pinkbyte but about other things - no idea
+2014-03-26 21:06:16 @Tommy[D] TomWij: as i said: we could look into creating a page listing possible work specific groups (devs/users) can do, beside that we currently dont have anything specific
+2014-03-26 21:07:09 @TomWij Tommy[D]: Yeah, even for ourselves I think it can help; for example, I have a search that does something like:
+2014-03-26 21:07:12 @TomWij Resolution: --- Keywords: (contains none of the words) Tracker Assignee: Severity: QA CC:
+2014-03-26 21:07:39 @TomWij (The Keywords is wrong, it checks for QA.)
+2014-03-26 21:08:22 @Tommy[D] Pinkbyte: i suggest you write that via mail to the alias, so we have a starting point for our further discussion/planning
+2014-03-26 21:08:31 @TomWij The idea being that {assignee,cc} alone doesn't suffice; there's like a lot where severities get said to QA or something QA is put in another field or so (eg. QAcanfix).
+2014-03-26 21:09:23 * TomWij gets scared thinking about the amount of QA bugs that have none of these bug parameters indicate that it is a QA bug.
+2014-03-26 21:10:41 @Tommy[D] dont think too much about it, just gets you less/grey hair quicker :)
+2014-03-26 21:10:58 @TomWij Does someone know when the first QA team was formed?
+2014-03-26 21:10:59 @Tommy[D] as there is no new input, i suggest, we close the meeting for today
+2014-03-26 21:11:33 @TomWij Tommy[D]: +1
+2014-03-26 21:11:47 @TomWij Just for fun, I'm even thinking there might even still be QA bugs lingering around from before that time.
+2014-03-26 21:12:13 @Pinkbyte TomWij, try not to thing about unreported QA bugs too ;-)
+2014-03-26 21:13:00 @Tommy[D] so i assume meeting closed, have a good evening everyone
+2014-03-26 21:13:15 * TomWij feels that his hair changes color.
+2014-03-26 21:13:32 @TomWij good evening
+2014-03-26 21:22:34 @creffett|irssi TomWij: at the rate we're going, I will be gray-haired by the time my term is up
diff --git a/meeting-logs/20140416.txt b/meeting-logs/20140416.txt
new file mode 100644
index 0000000..5b84035
--- /dev/null
+++ b/meeting-logs/20140416.txt
@@ -0,0 +1,621 @@
+2014-04-16 19:34:46 * WilliamH is here just hanging around
+2014-04-16 19:38:15 * zlogene around
+2014-04-16 19:43:41 @zlogene !away Pinkbyte
+2014-04-16 19:43:42 willikins zlogene: pinkbyte: Limited development activity till June 1, 2014. Available via e-mail, feel free to contact on urgent stuff or fix things yourself. But do not break anything ;-) @ 2014/04/05 15:04Z
+2014-04-16 19:52:55 @WilliamH fire alarm going off, I'll be back asap
+2014-04-16 20:02:52 @creffett|irssi all right, it's 1800, let's get going
+2014-04-16 20:03:39 @creffett|irssi DrEeevil, Pinkbyte, TomWij, Tommy[D], ulm, WilliamH, wired, Zero_Chaos, zlogene: meeting time
+2014-04-16 20:03:46 * TomWij here
+2014-04-16 20:03:58 @Zero_Chaos oh dear god
+2014-04-16 20:04:00 * ulm here
+2014-04-16 20:04:05 @Zero_Chaos two meetings in a row, YES
+2014-04-16 20:04:07 * Zero_Chaos here
+2014-04-16 20:05:33 @zlogene as usual
+2014-04-16 20:05:48 @creffett|irssi that's 5, would be nice to get one more at least
+2014-04-16 20:05:58 @wired I'm here as well
+2014-04-16 20:06:24 @creffett|irssi excellent, that's enough to get started, and I expect that WilliamH will join us once he's done dealing with whatever's on fire
+2014-04-16 20:06:40 * WilliamH is back, false alarm
+2014-04-16 20:07:18 @Zero_Chaos WilliamH: always preferred.
+2014-04-16 20:07:23 @Zero_Chaos well... not always
+2014-04-16 20:07:25 @Zero_Chaos :-)
+2014-04-16 20:07:30 @WilliamH he
+2014-04-16 20:07:32 @WilliamH heh
+2014-04-16 20:07:59 @creffett|irssi first on the agenda: after discussion with antarus, we're going to be backing off a little on the "enforcement" of policies and leaving that to comrel
+2014-04-16 20:08:14 @creffett|irssi the general idea is that if someone's breaking policy, we ask them nicely, and if they refuse, we pass it to comrel
+2014-04-16 20:08:59 @wired 1900 utc should be in 50 m btw
+2014-04-16 20:09:02 @Zero_Chaos creffett|irssi: can you please explicitly state historical samples of why? don't need specifics of each incident, but I'd like to know which incidents specifically.
+2014-04-16 20:09:14 @zlogene it seems we have really long list of topics, no?
+2014-04-16 20:09:18 @Zero_Chaos zlogene: yes
+2014-04-16 20:09:21 @TomWij zlogene: Most are short.
+2014-04-16 20:09:25 @WilliamH wired: the meeting is at 1800
+2014-04-16 20:09:33 @TomWij And we can skip whatever's not important if we go over time.
+2014-04-16 20:09:41 @wired the mail said 1900
+2014-04-16 20:09:48 @wired no worries on my side
+2014-04-16 20:10:05 @creffett|irssi we don't need to be reaching in and changing things when someone's ignoring policy, unless it is presently causing breakage (and by breakage I'm talking "unbootable user system" or "unusable portage tree")
+2014-04-16 20:10:18 @creffett|irssi wired: I forgot to check our agreed-upon time before sending the email, it was my bad
+2014-04-16 20:11:01 @Zero_Chaos creffett|irssi: I'm not trying to be difficult but I'd like to know if this is specifically incited by the udev virtuals being masked.
+2014-04-16 20:11:34 @creffett|irssi Zero_Chaos: that was the impetus for this, yes, but it's been something I've been thinking over for a while
+2014-04-16 20:11:56 @Zero_Chaos creffett|irssi: there is no arguement, I just need to understand the resolutions which come out of my actions.
+2014-04-16 20:12:01 @Zero_Chaos creffett|irssi: please continue.
+2014-04-16 20:12:02 @creffett|irssi Zero_Chaos: okay
+2014-04-16 20:12:39 @creffett|irssi basically, the problem I'm addressing here is twofold: inconsistent handling of when someone is ignoring policy, and accusations of us being quick to flash the QA badge without cause
+2014-04-16 20:13:19 @Tommy[D] creffett: so if someone violates a qa policy, you want us to basicly ask "please dont" and next step "comrel, your case"?
+2014-04-16 20:13:33 @Zero_Chaos or a tree policy in general.
+2014-04-16 20:13:35 @TomWij creffett|irssi: So; policy violations => ComRel, user visible breakage => QA. And the gray area goes through discussion with proper step-by-step escalation?
+2014-04-16 20:14:04 @creffett|irssi Tommy[D]: basically, yes, because when they are willfully ignoring tree policy, it's then comrel's problem
+2014-04-16 20:14:14 @wired I thought the original idea was to only touch the tree when breakage is involved, otherwise try to talk with the devs first
+2014-04-16 20:14:23 @creffett|irssi wired: that is the idea
+2014-04-16 20:14:46 @creffett|irssi we're just expanding a bit on that
+2014-04-16 20:14:59 @WilliamH wired: I think the problem is some people's definition of what breakage is is very arbitrary
+2014-04-16 20:15:11 @creffett|irssi the first step should always be to politely message the dev in question and let them know about the issue
+2014-04-16 20:15:20 @wired so nothing needs to change, we only need to be more specific on how to handle devs who don't want to listen to us
+2014-04-16 20:15:25 @creffett|irssi wired: affirmative
+2014-04-16 20:15:34 @Zero_Chaos creffett|irssi: just to further clarify, impending breakage due to policy violation is comrel's problem, current breakage is under the jurisdiction of QA?
+2014-04-16 20:16:00 @wired I'd say that this is not our job, comrel sounds good to me in those cases
+2014-04-16 20:16:01 @creffett|irssi Zero_Chaos: current breakage that is actually user-visible
+2014-04-16 20:16:18 mgorny i'd say it would be good if QA action would result in less visible breakage than there was before the action
+2014-04-16 20:16:22 @WilliamH Zero_Chaos: What I'm getting is willful ignoring of tree policy after we contact the dev is under the jurisdiction of comrel.
+2014-04-16 20:16:28 @Zero_Chaos creffett|irssi: so QA is not to intervene on incipient breakage. understood.
+2014-04-16 20:16:58 @creffett|irssi Zero_Chaos: there will be judgment calls here, but someone using a USE flag against some policy or other isn't a reason for us to jump in
+2014-04-16 20:17:09 @Zero_Chaos WilliamH: the concern is that we are creating a policy that literally binds our hands to prevent breakage until the damage is done.
+2014-04-16 20:17:44 @Zero_Chaos creffett|irssi: stabilizing something that gets pulled into the system set with known breakage is not to be blocked until AFTER it's been done. I fully understand the policy.
+2014-04-16 20:18:03 @Zero_Chaos creffett|irssi: I fully disagree with the policy mind you, but I understand it.
+2014-04-16 20:18:12 @creffett|irssi I appreciate your candor
+2014-04-16 20:18:37 @WilliamH creffett|irssi: I don't quite get it. Here's what I'm thinking, tell me if I'm right.
+2014-04-16 20:18:46 @Zero_Chaos creffett|irssi: well that is the example most fresh in my head. open stabilization bug for items in the system set, pulling in new undiscussed virtuals with circular deps.
+2014-04-16 20:18:55 @Zero_Chaos creffett|irssi: I prevented user visible breakage and that was wrong.
+2014-04-16 20:18:58 @Zero_Chaos I follow
+2014-04-16 20:19:02 @WilliamH creffett|irssi: 1. dev violates policy. 2. we advise him that he is in violation. 3. he says ok, but I'm not fixing it. 4. comrel.
+2014-04-16 20:19:26 @creffett|irssi WilliamH: correct
+2014-04-16 20:19:29 @wired assuming the violation does not visibly break the tree
+2014-04-16 20:20:10 @WilliamH I think the problem is, how do we define what breaks the tree?
+2014-04-16 20:20:14 @ulm glep 48 says that we can take action if devs don't cooperate
+2014-04-16 20:20:19 @TomWij also assuming advise would mean you properly discuss and escalate it in steps.
+2014-04-16 20:20:44 @creffett|irssi ulm: yes, we can, but I would like that to be limited to when things actually break.
+2014-04-16 20:20:44 @TomWij (There's a difference between one QA dev stepping to ComRel and the QA team stepping to ComRel)
+2014-04-16 20:20:54 @ulm creffett|irssi: sure
+2014-04-16 20:21:19 @creffett|irssi Zero_Chaos: which was your main issue with the new udev virtuals, the "undiscussed" part or the "circular deps" part?
+2014-04-16 20:21:36 @Zero_Chaos I am greatly concerned that we are *requiring* ourselves to wait for the breakage to be "user visible". Although again, in my case you could say the breakage was user visible since it would have broken releng for ~arch.
+2014-04-16 20:21:57 @Zero_Chaos creffett|irssi: my main issue is the attempt to bind our hands to not act when we see impending failure.
+2014-04-16 20:22:04 @WilliamH creffett|irssi: he told me at the time that his main issue was the undiscussed part.
+2014-04-16 20:22:08 mgorny Zero_Chaos: did you confirm that it would, or are you assuming that it would?
+2014-04-16 20:22:16 @creffett|irssi mgorny: enough.
+2014-04-16 20:22:18 @Zero_Chaos creffett|irssi: as of this moment my actions still meet the new policy. There was user visible breakage in ~arch, I acted accordingly.
+2014-04-16 20:22:32 @creffett|irssi Zero_Chaos: I am still not clear on what the breakage was
+2014-04-16 20:22:43 @TomWij Zero_Chaos: I'm also concerned with breakage-by-default type of actions happening these days (VS working-by-default).
+2014-04-16 20:22:55 @Zero_Chaos creffett|irssi: circular deps between udev and the new virtuals would make it impossible to bootstrap.
+2014-04-16 20:23:08 @Zero_Chaos TomWij: agreed.
+2014-04-16 20:23:24 @creffett|irssi Zero_Chaos: then that is almost certainly issue that we would want to act on.
+2014-04-16 20:23:38 @creffett|irssi but it came off to me as you masking because it was not discussed prior to introductin
+2014-04-16 20:23:42 @creffett|irssi *introduction
+2014-04-16 20:23:45 @Zero_Chaos creffett|irssi: as I said, even by the new standards my actions followed policy.
+2014-04-16 20:23:51 @WilliamH It came off that way to me too.
+2014-04-16 20:24:02 @creffett|irssi and that is explicitly what I am trying to deal with with the new policy
+2014-04-16 20:24:40 @Zero_Chaos creffett|irssi: yes, I understand, but what you are saying is that we need to wait for user visible breakage before we can act. This is in no way an improvement, it's the opposite.
+2014-04-16 20:24:51 @WilliamH I think it was even stated on the ml that the masking was done to force discussion.
+2014-04-16 20:25:07 @creffett|irssi Zero_Chaos: ~arch breakage is still breakage
+2014-04-16 20:25:15 @Zero_Chaos WilliamH: by the time that post hit the mailing list some of the fixes had been made.
+2014-04-16 20:25:30 @creffett|irssi so unless you are able to read minds, every issue is going to have to hit the tree in some way before we act
+2014-04-16 20:25:53 @WilliamH creffett|irssi: ~arch breakage is breakage, but ~arch users are supposed to understand that they may get breakage from time to time.
+2014-04-16 20:26:08 @Zero_Chaos creffett|irssi: right, but by that standard everything in the tree affects users so this policy may as well require oxygen nearby the QA member before he is allowed to act.
+2014-04-16 20:26:18 @TomWij creffett|irssi: Yep, the lack of discussion is a ComRel matter; it's of concern when people want to raise something after they introduce and stabilize it (as it can break due to unawareness, assumptions, lack of thoughts, ...), but it's not our terrain if you think about the scope of QA and ComRel.
+2014-04-16 20:26:24 @Zero_Chaos creffett|irssi: so we are making a pointless policy here.
+2014-04-16 20:26:37 @Zero_Chaos "QA isn't allowed to mask things not in the tree"
+2014-04-16 20:27:05 @TomWij Zero_Chaos: Reiterating it; I've not seen something new here, just learning from what happened and what could happen.
+2014-04-16 20:27:06 @creffett|irssi Zero_Chaos: disagree, there are a lot of policies that are nice-to-follow but won't break peoples' systems
+2014-04-16 20:27:37 @creffett|irssi so let me try giving an example to see if I can make clear what I'm imagining
+2014-04-16 20:27:43 @Zero_Chaos creffett|irssi: I suppose I'm still lacking an example then.
+2014-04-16 20:27:48 @creffett|irssi I introduce an eclass without discussing it on the ML
+2014-04-16 20:28:04 @Zero_Chaos creffett|irssi: if that eclass is in use that's user visible breakage.
+2014-04-16 20:28:07 @creffett|irssi someone from QA masks packages that are using it because it wasn't discussed -> bad.
+2014-04-16 20:28:12 @wired I tend to consider testing as current, not as a playground, I would prefer to avoid breakage of possible
+2014-04-16 20:28:33 @creffett|irssi someone from QA masks packages using it because it runs rm -rf / in pkg_postinst -> okay \
+2014-04-16 20:28:52 @creffett|irssi Zero_Chaos: it is not breakage, because nothing is broken; someone just ignored part of the policy, and we should talk to them about it
+2014-04-16 20:28:58 @Zero_Chaos creffett|irssi: sorry but how is a new undiscussed eclass IN USE not user visible breakage?
+2014-04-16 20:29:06 @WilliamH wired: the reason for that is slow stabilizations.
+2014-04-16 20:29:11 @Zero_Chaos creffett|irssi: how do we know the eclass works? it wasn't reviewed at all, by anyone.
+2014-04-16 20:29:35 @Zero_Chaos creffett|irssi: you want us to pour over every single thing looking for bugs before we are allowed to follow policy?
+2014-04-16 20:29:43 @creffett|irssi no
+2014-04-16 20:29:55 @creffett|irssi but if it is not actively hurting somebody, then there is no reason to take immediate action
+2014-04-16 20:30:01 @Zero_Chaos creffett|irssi: try reading /usr/portage/eclass/python* "real quick" to make sure there is no breakage.
+2014-04-16 20:30:22 @Zero_Chaos creffett|irssi: so again, you are specifically saying we must wait for users to be harmed by the policy breakage, is that correct?
+2014-04-16 20:30:42 @creffett|irssi no, I'm saying there needs to be something wrong, not that the users need to be harmed
+2014-04-16 20:30:42 @Zero_Chaos creffett|irssi: because that isn't "Quality Assurance" that's "Custodial Engineering"
+2014-04-16 20:31:00 @TomWij creffett|irssi: I think bug #435094 (comment #11) is an example of how we can address things.
+2014-04-16 20:31:01 willikins TomWij: "Optional multilib USE flag could cause problems, devs and users could be unaware (was: Force multilib USE flag only on core packages)"; Gentoo Linux, Eclasses and Profiles; RESO, FIXE; mattst88:toolchain
+2014-04-16 20:31:01 @Zero_Chaos creffett|irssi: fixing something BEFORE it affects users is QA, cleaning up after is janitorial.
+2014-04-16 20:31:10 @creffett|irssi I would like to assume basic competence on the part of the developer base
+2014-04-16 20:31:32 @Zero_Chaos creffett|irssi: I'd like to assume I can get any girl I like and I'll be 6 feet tall someday.
+2014-04-16 20:31:52 @Zero_Chaos creffett|irssi: people make mistakes, honest mistakes, it happens.
+2014-04-16 20:31:56 @wired I think what creffet is trying to say is that there are qa violations that don't have significant impact to users and we can delay actions on those cases
+2014-04-16 20:32:26 @TomWij Zero_Chaos: Even better is if you can prevent it from existing; as that is true QA, but of course often hard to do.
+2014-04-16 20:32:26 @Zero_Chaos wired: and what I'm saying is that very specifically we wouldn't be the Quality ASSURANCE team in that case.
+2014-04-16 20:33:07 @wired well it is not always easy to enforce policy in a large group of developers
+2014-04-16 20:33:09 @Zero_Chaos TomWij: I agree, but to specficially bind QA from preventing problems before they occur is moving the assumption of perfection from us to the developer community.
+2014-04-16 20:33:46 @Zero_Chaos creffett|irssi: no matter what we do, some assumptions must be made about the developers at large, and QA itself. First we assume niether side has no malice, and both sides make mistakes.
+2014-04-16 20:33:57 @creffett|irssi Zero_Chaos: I am not disagreeing with that
+2014-04-16 20:34:27 @Zero_Chaos creffett|irssi: now all that is left is do we want to assume it's more likely QA will make mistakes, or the developers will make mistakes? Further we need to see what the negative impact of those mistakes are.
+2014-04-16 20:34:44 @creffett|irssi right now? QA's making the mistakes.
+2014-04-16 20:34:53 @Zero_Chaos creffett|irssi: if a dev screws up, people can lose everything. if QA screws up, a perfectly good package isn't in use for a few days while we discuss.
+2014-04-16 20:35:20 @Zero_Chaos creffett|irssi: I'd rather have QA have the power to prevent breakage, and admit sometimes they are wrong, rather than wait for breakage to be assured and damage the users.
+2014-04-16 20:35:45 @Zero_Chaos creffett|irssi: I realize everyone wants to be in charge, but sadly, we are harming our users, here and now.
+2014-04-16 20:35:55 @TomWij A mask is just a mask.
+2014-04-16 20:36:00 @Zero_Chaos exactly
+2014-04-16 20:36:18 @Zero_Chaos worst case, we masked something improperly, remove the mask, users didn't get a change for a few days
+2014-04-16 20:36:22 @Zero_Chaos no harm, no foul.
+2014-04-16 20:36:25 @TomWij It sits there between Gentoo and the users; it even allows the developers to continue their work, although in a way that the users won't get their updates.
+2014-04-16 20:36:39 @TomWij It's perceived as a weapon by some; however, it isn't. It's just a temporary measure.
+2014-04-16 20:37:05 @Zero_Chaos if there is malice in a QA mask that's an entirely different matter, what we are dicussing here is trying to help the users before injury vs digging them out of the hole we let them fall in.
+2014-04-16 20:38:08 @wired I need to relocate, I'll be back in 10m
+2014-04-16 20:38:09 * antarus lurks
+2014-04-16 20:38:14 @Zero_Chaos I don't see how we expect the QA team to Assure Quality if we are not allowed to attempt to prevent breakage.
+2014-04-16 20:38:18 @creffett|irssi antarus: oh, hi there.
+2014-04-16 20:38:23 @creffett|irssi antarus: any input on the discussion so far?
+2014-04-16 20:38:26 @Zero_Chaos WORST CASE, we mask something, remove it, no big deal.
+2014-04-16 20:38:34 @TomWij creffett|irssi: This all then boils down to "what is perceived as breakage?" and the whole way the GLEP addresses that.
+2014-04-16 20:38:40 @Zero_Chaos vs an undiscussed change that causes massive breakage.
+2014-04-16 20:38:59 @creffett|irssi TomWij: the glep does not address it sufficiently, thus the problem.
+2014-04-16 20:39:01 * Tommy[D] will be back in some minutes
+2014-04-16 20:39:07 @Zero_Chaos TomWij: this really boils down to people understanding a mask isn't a weapon.
+2014-04-16 20:39:15 @creffett|irssi Zero_Chaos: but most undiscussed changes will _not_ cause breakages
+2014-04-16 20:39:21 @creffett|irssi and there can be discussed changes which do
+2014-04-16 20:39:38 @TomWij Iotw "Ukraine and Russia are starting a war. Do you want to mask? [Y/N]"
+2014-04-16 20:39:43 @creffett|irssi your assumption seems to be something down the lines of "if it's not discussed, it's going to break things"
+2014-04-16 20:39:48 @Zero_Chaos creffett|irssi: I agree with you 100%, BUT 100% of masks won't cause breakage. So masking something is much safer than not if there is a question.
+2014-04-16 20:40:16 @Zero_Chaos creffett|irssi: no, I'm saying there is a ZERO percent chance of a QA mask hurting the users, and a slim chance not masking something will.
+2014-04-16 20:40:30 * creffett|irssi sighs
+2014-04-16 20:40:48 @creffett|irssi fine, we will remain as-is, and revisit this later if the issue comes up again
+2014-04-16 20:40:54 @Zero_Chaos creffett|irssi: we cannot possibly hurt the users by masking something we feel breaks policy, et al. The reverse cannot be said.
+2014-04-16 20:41:22 antarus creffett|irssi: I think generally I expect masks to be backed up by some sort of policy
+2014-04-16 20:41:28 @Zero_Chaos creffett|irssi: honestly, comrel needs to be there when the devs cannot discuss like people (it happens to us all) or when there is direct and obvious malice.
+2014-04-16 20:41:36 antarus I don't think actual user breakage is necessary
+2014-04-16 20:41:37 @Zero_Chaos creffett|irssi: past that, it's not their job.
+2014-04-16 20:41:40 @TomWij (Answer: If you don't mask, they'll have their resolution and/or fight, hard to tell which; if you mask, they perceive it as a weapon and you get world war until we understand a world war isn't the most efficient way to become powerful and/or solve problems.)
+2014-04-16 20:41:51 antarus creffett|irssi: if you want comrel to mask for policy violations (rather than user breakages)
+2014-04-16 20:41:55 antarus I'm happy to discuss
+2014-04-16 20:41:57 @creffett|irssi I suggest we adjourn until 1850, since wired and Tommy[D] are both out, and I need to run to my next class anyway
+2014-04-16 20:42:14 @Zero_Chaos heh
+2014-04-16 20:42:18 * WilliamH agrees with antarus, if we qa mask something we should cite the policy that we are using in the mask message.
+2014-04-16 20:42:51 @Zero_Chaos antarus:
+2014-04-16 20:42:52 @Zero_Chaos @creffett|irssi> first on the agenda: after discussion with antarus, we're going to be backing off a little on the "enforcement" of policies and leaving that to comrel
+2014-04-16 20:42:56 @Zero_Chaos 14:09 <@creffett|irssi> the general idea is that if someone's breaking policy, we ask them nicely, and if they refuse, we pass it to comrel
+2014-04-16 20:43:04 @Zero_Chaos antarus: to catch you up, that was the start of this discussion.
+2014-04-16 20:43:30 @Zero_Chaos antarus: I am against this, as we have policies to prevent breakage, ignoring them isn't a matter for comrel, it's a matter for Quality Assurance, imho.
+2014-04-16 20:44:06 @Zero_Chaos antarus: comrel is for personal inability to discuss something technically (like how for instance Samuli and I both got a bit heated) or direct malice.
+2014-04-16 20:44:23 @Zero_Chaos antarus: unless I'm missing something, technical policy enforcement is our charter, not comrels.
+2014-04-16 20:44:26 @zlogene oops i have a hard problem, should be back ASAP, (but not sure right now).On line anyway.
+2014-04-16 20:44:38 @Zero_Chaos zlogene: I think we are on break for a few anyway.
+2014-04-16 20:45:03 antarus Zero_Chaos: well the aforementioned eclass policy could be construed as a policy issue (but not a user-affecting issue)
+2014-04-16 20:45:10 @WilliamH Zero_Chaos: what about willful violation of policy?
+2014-04-16 20:45:12 antarus so who owns that one?
+2014-04-16 20:45:23 @TomWij WilliamH: Willful / repeated is ComRel.
+2014-04-16 20:45:31 @Zero_Chaos antarus: eclasses are technical issues not personal, QA does.
+2014-04-16 20:45:38 @Zero_Chaos antarus: that's not even blurry to me.
+2014-04-16 20:46:04 @Zero_Chaos WilliamH: willful violation of policy is both, QA corrects things technically and comrel deals with the malice since we lack the power to do so.
+2014-04-16 20:46:06 antarus to speak bluntly
+2014-04-16 20:46:11 @Zero_Chaos antarus: please :-)
+2014-04-16 20:46:34 @WilliamH Zero_Chaos: but if the eclass doesn't break things there is no breakage.
+2014-04-16 20:46:47 antarus I don't mind if qa members mask things if they communicate clearly what they did, why they did it, and what the remediation is, and they cite the relevant policies
+2014-04-16 20:46:50 @WilliamH Zero_Chaos: so that the dev didn't discuss it isn't our issue really.
+2014-04-16 20:46:56 antarus becuase you are in essence utilizing your authority over other people
+2014-04-16 20:47:03 antarus and it needs to be clear to them why
+2014-04-16 20:47:57 @Zero_Chaos WilliamH: sorry that's not how that works. If a new "whatever" is introduced and there is supposed to be policy requiring discussion then to not discuss it is violating policy and has the potential to affect users. we are here to PREVENT breakage not to pour over undiscussed code looking for mistakes before we can act.
+2014-04-16 20:48:16 antarus (I will avoid making the qa-as-cops comparison)
+2014-04-16 20:48:23 antarus but I think there are similarities there
+2014-04-16 20:48:36 @Zero_Chaos WilliamH: again, if QA masks something the worst case is we are wrong and the users get is in a few days. If we don't mask something and it turns out to break, much worse things can happen.
+2014-04-16 20:48:58 @Zero_Chaos WilliamH: I'm going to introduce a new kernel-builder.eclass soon, and move all kernel sources to using it.
+2014-04-16 20:49:15 @Zero_Chaos WilliamH: when I do that without any discussion, do you think ANYONE will let that stand until breakage is reported?
+2014-04-16 20:49:37 @TomWij antarus: And ComRel is Committee P?
+2014-04-16 20:49:41 @TomWij (:P)
+2014-04-16 20:50:00 dilfridge nope, just shady conspiracy :D
+2014-04-16 20:50:23 * wired back
+2014-04-16 20:50:33 @Zero_Chaos antarus: expecting either side to be perfect is irrational, but when QA messes up, no one is really "hurt". In my opinion anyway.
+2014-04-16 20:50:49 antarus TomWij: not getting it
+2014-04-16 20:51:01 antarus Zero_Chaos: being wrongfully arrested is a crime
+2014-04-16 20:51:06 @Zero_Chaos antarus: take my most recent example. barring the rampant asshattery (on both sides), the changes were discussed, the bugs were fixed, and the mask was removed inside of a day.
+2014-04-16 20:51:12 @Zero_Chaos antarus: not in my country buddy.
+2014-04-16 20:52:00 @TomWij (Not a joke, just further comparing; because as they say here, the police is your friend)
+2014-04-16 20:52:01 @Zero_Chaos antarus: now if there were no QA mask, ~arch was broken with circular deps, and there was an open stable bug which means that stable would have been affected shortly. I see a lot of harm there.
+2014-04-16 20:52:24 @TomWij antarus: A mask is hardly an arrest though.
+2014-04-16 20:52:57 antarus TomWij: legally, the police are not your friends
+2014-04-16 20:52:58 @Zero_Chaos a mask isn't "OMG you are a terrible person and must die!" it's more like "whoa, hold on, let's look at this"
+2014-04-16 20:53:07 antarus but I digress ;)
+2014-04-16 20:53:13 @Zero_Chaos removing things from the tree is "DIE DIE DIE"
+2014-04-16 20:53:28 @Zero_Chaos a mask is just a "this needs review/discussion/majorfix/etc"
+2014-04-16 20:53:55 antarus TomWij: I use them here as they are both 'uses of authority'
+2014-04-16 20:54:00 @Zero_Chaos we need to either assume both parties are acting without malice or we need to involve comrel like they should be involved when there is malice.
+2014-04-16 20:54:14 @Zero_Chaos masks aren't a punishment.
+2014-04-16 20:54:29 @Zero_Chaos I've masked my own packages before, I didn't take any offense :-)
+2014-04-16 20:56:16 antarus as I said, in the past things were not...on the level?
+2014-04-16 20:56:46 @Zero_Chaos antarus: go back to speaking bluntly, clarity is important here.
+2014-04-16 20:57:29 @ulm do I see it right, we are at one hour and haven't finished with any agenda topic yet? ;)
+2014-04-16 20:57:43 @wired yup
+2014-04-16 20:57:45 antarus hehe
+2014-04-16 20:57:52 @wired you could say the meeting starts now
+2014-04-16 20:57:53 @creffett|irssi let's get going
+2014-04-16 20:57:54 @ulm well, roll call is done ;)
+2014-04-16 20:58:11 @creffett|irssi someone got the agenda up? what's next? /me mobile right now, so a pain to switch back and forth
+2014-04-16 20:58:17 antarus Zero_Chaos: so using the samuli as an example
+2014-04-16 20:58:24 @TomWij Masks are like "It is fine for the Portage tree where ~200 devs can test if it's not broken, but it needs at least a bit of peer review before releasing this (possible / actual) breakage to OVER 9000 users".
+2014-04-16 20:58:27 antarus it looked as though you tackled him to the ground
+2014-04-16 20:58:33 antarus and then beat him repeatedly
+2014-04-16 20:58:38 @ulm creffett|irssi: GTK flags is next, I think
+2014-04-16 20:58:39 antarus and then masked his package ;p
+2014-04-16 20:58:55 @Zero_Chaos creffett|irssi: we hadn't really finished with the first topic yet... or had we?
+2014-04-16 20:58:59 @creffett|irssi okay, I think that one gets pushed back since we just send the mail
+2014-04-16 20:59:09 @creffett|irssi Zero_Chaos: I said that we'll just stay as-is and revisit if we have further issues
+2014-04-16 20:59:10 @TomWij (
+2014-04-16 20:59:25 @Zero_Chaos antarus: moving to pm to avoid disrupting the meeting
+2014-04-16 20:59:39 @wired 15m => 1h, yeah, nailed that first topic :p
+2014-04-16 21:00:01 antarus sure
+2014-04-16 21:00:20 @TomWij creffett|irssi: Yes, let's keep things as-is; several of us have a different view of this, both you and me have thought about ways to steer it when it happens, it'll happen different (and hopefully better) next time.
+2014-04-16 21:00:51 @wired * Where are the GNOME and QA team at with the GTK flag issue? [~ 5 min] (Mail was sent, either defer agenda item or ask leio or eva [were working on something])
+2014-04-16 21:01:27 @TomWij I know that weeks before the mail, Eva was working on reviewing all the gtk* packages in the tree; not sure what the progress on that is, other than that I guess we'll await response to the mail?
+2014-04-16 21:01:37 * WilliamH hasn't heard a word from the gnome guys
+2014-04-16 21:01:56 @TomWij We could ask; but given the mail went out late, that might be too early.
+2014-04-16 21:01:59 leio We have heard absolutely nothing from the QA people, so eva deferred finishing the work until useful stuff is done, like getting gnome 3.12 to the tree.
+2014-04-16 21:02:01 @WilliamH I guess my question is, how long do we wait?
+2014-04-16 21:02:02 @creffett|irssi we'll push that one back
+2014-04-16 21:02:15 @TomWij leio: Did you receive the mail WilliamH has sent out?
+2014-04-16 21:02:17 leio QA people haven't even contacted us, at all, sans that possible mail you are talking about now.
+2014-04-16 21:02:27 @creffett|irssi leio: we sent a mail a few days ago
+2014-04-16 21:02:37 @WilliamH leio: you didn't get the mail to gnome@g.o that was sent a few days ago?
+2014-04-16 21:02:39 @creffett|irssi check your spam folder :)
+2014-04-16 21:03:01 leio I was busy with work and just got back from abroad, so no, I haven't seen that yet
+2014-04-16 21:03:16 @WilliamH leio: it was sent a few days back.
+2014-04-16 21:03:25 leio was eva's working sheet
+2014-04-16 21:03:40 * WilliamH looks for the date
+2014-04-16 21:03:43 @TomWij (Date: Sat, 12 Apr 2014 21:49:43 -0500 From: William Hubbs <> To: Cc: Subject: gtk use flag situation)
+2014-04-16 21:03:46 @creffett|irssi leio: we don't need a response, but could you verify that you got the mail?
+2014-04-16 21:04:03 leio ok, but I need to find my mouse :)
+2014-04-16 21:04:10 @creffett|irssi leio: sounds good
+2014-04-16 21:04:20 @wired mouse? you still use that thing? xD
+2014-04-16 21:04:27 @WilliamH heh
+2014-04-16 21:04:48 leio I haven't found a good brain to computer interface yet, that would be open source
+2014-04-16 21:04:55 leio that would be more effective than keyboard and mouse
+2014-04-16 21:05:14 @zlogene wired: now about pc :P
+2014-04-16 21:05:22 * WilliamH thinks brain-computer interfaces are sort of scary... well not them specifically, but the implications...
+2014-04-16 21:05:23 @zlogene *how
+2014-04-16 21:05:37 @creffett|irssi while we wait, next topic: dynamic-deps, revbumps, etc.
+2014-04-16 21:05:37 @WilliamH if/when that tech falls into the wrong hands
+2014-04-16 21:05:42 @wired * Rely on dynamic dependencies (has binpkg and subslot problems), revision bumps (causes some unnecessary rebuilds) or keep status quo when changing dependencies in an existing ebuild? [~ 10 min]
+2014-04-16 21:05:46 @creffett|irssi wired++
+2014-04-16 21:06:03 @zlogene wired: what you will do there without mouse? :p
+2014-04-16 21:06:06 @creffett|irssi so basically, we need to produce a recommendation for this (or no change)
+2014-04-16 21:06:18 @TomWij (leio: Thank you for the link.)
+2014-04-16 21:06:31 @creffett|irssi since right now, if you revbump after changing deps, it breaks binpkgs but dynamic-deps for normal packages handles things fine
+2014-04-16 21:06:34 @creffett|irssi er
+2014-04-16 21:06:36 @wired zlogene: mouse exists for games and design apps, but lets leave that for another time :P
+2014-04-16 21:06:38 @creffett|irssi if you _don't_ revbump
+2014-04-16 21:07:03 @creffett|irssi opinions? thoughts? edontcare?
+2014-04-16 21:07:11 @Zero_Chaos creffett|irssi: honestly this topic is above QA. PMS doesn't specifiy how things should be handled.
+2014-04-16 21:07:12 @ulm dynamic dependencies are a hack and not always working
+2014-04-16 21:07:32 @ulm e.g. they aren't working if the ebuild has been removed
+2014-04-16 21:07:43 @Zero_Chaos dynamic deps are indeed a hack and cause all kinds of issues but the flip side is rebuilding libreoffice daily.
+2014-04-16 21:07:46 @ulm and they are portage specific
+2014-04-16 21:07:48 @WilliamH Well, if we force a revbump for this, we are adding another stable req to arch teams too just for changing deps.
+2014-04-16 21:07:56 @creffett|irssi so what do we do? punt it to PMS?
+2014-04-16 21:08:07 @TomWij Zero_Chaos: The PMS does say dependencies should be merged before certain moments; and thus, by PMS dynamic deps shouldn't even be possible.
+2014-04-16 21:08:14 @ulm creffett|irssi: we cannot
+2014-04-16 21:08:30 @creffett|irssi ulm: why not?
+2014-04-16 21:08:45 @ulm that would mean to keep metadata of removed ebuilds indefinitely
+2014-04-16 21:08:58 @ulm otherwise it's not guaranteed to work
+2014-04-16 21:08:59 @Zero_Chaos TomWij: you are saying that dynamic deps specifically violates pms?
+2014-04-16 21:09:14 @creffett|irssi ulm: I meant "can we punt this question to the PMS team"
+2014-04-16 21:09:18 @TomWij So, we need to decide on either the PMS (rev bump) or Portage (dyn deps) approach and correct the other; that is, unless we keep the status quo.
+2014-04-16 21:09:29 @Zero_Chaos creffett|irssi: fyi this is a VERY long standing issue, I wouldn't expect resolution, just direction of travel.
+2014-04-16 21:09:49 leio latest e-mail from WilliamH that I see is from 5th April, and only gentoo-commits of him after that. But I found it from spam...
+2014-04-16 21:10:19 @Zero_Chaos TomWij: I'm okay with either one, leaning towards extending the hack of dynamic deps to binpkgs and PMS
+2014-04-16 21:10:28 @ulm I'd say always revbump if necessary
+2014-04-16 21:10:29 @creffett|irssi Zero_Chaos: we can't solve long-standing issues in one meeting? /me removes "cure cancer" from the agenda
+2014-04-16 21:10:56 @TomWij Zero_Chaos: "Build dependencies (DEPEND). These must be installed and usable before any of the ebuild src_* phase functions is executed. [...] Runtime dependencies (RDEPEND). These must be installed and usable before the results of an ebuild merging are treated as usable. [...] Post dependencies (PDEPEND). These must be installed at some point before
+2014-04-16 21:10:56 @TomWij the package manager finishes the batch of installs."
+2014-04-16 21:11:04 @ulm maybe introduce an exception that the new revision can go straight to stable if only dependencies are changed
+2014-04-16 21:11:20 dilfridge that does not solve the issue of libreoffice rebuilds
+2014-04-16 21:11:29 @creffett|irssi ^^ beat me to it
+2014-04-16 21:11:34 @Zero_Chaos ulm: that's going to piss off a lot of people for "unnessesary rebuilds"
+2014-04-16 21:12:09 @ulm well, there's libreoffice-bin for them :p
+2014-04-16 21:12:16 @Zero_Chaos honestly, and I've been on this issue since I became a dev, I think we need to keep the ugly hack of dynamic deps and correct binpkgs and PMS to define it better.
+2014-04-16 21:12:39 @Zero_Chaos it's too much to rebuild for every little thing but portage needs to know the deps properly, it's critical.
+2014-04-16 21:13:06 wired_ sorry
+2014-04-16 21:13:10 wired_ my vps died
+2014-04-16 21:13:34 @TomWij You can bend that RDEPEND definition in the PMS by claiming that usable in "results of an ebuild merging are treated as usable" to be usable after you've changed the dependencies; but well, that's quite a loophole. :D
+2014-04-16 21:13:45 @creffett|irssi so, for now, how abot we push this to portage/PMS teams?
+2014-04-16 21:13:47 wired_ I've missed everything on the last topic
+2014-04-16 21:14:12 @Zero_Chaos creffett|irssi: I agree with that, however, it should be noted that the portage team is understaffed for this kind of thing.
+2014-04-16 21:14:14 @WilliamH wired_: the topic is dynamic deps.
+2014-04-16 21:14:26 @TomWij creffett|irssi: +1 Push this off to both teams.
+2014-04-16 21:14:34 wired_ yeah, I dropped right after I pasted the topic
+2014-04-16 21:14:43 @creffett|irssi Zero_Chaos: the portage team has somewhere ~20 contributors, I owuld not call them understaffed
+2014-04-16 21:15:11 @Tommy[D] numbers are not everything ;)
+2014-04-16 21:15:22 @Zero_Chaos creffett|irssi: then you clearly don't discuss issues of this magnitude with them, because they have told me they do not have the man power to work this due to skill, and the one who could do it refuses.
+2014-04-16 21:15:37 @TomWij wired_:
+2014-04-16 21:15:41 @ulm creffett|irssi: I predict that neither of the teams will have a solution
+2014-04-16 21:15:57 @Zero_Chaos creffett|irssi: the only one would could fix this is few_ and he said if he touches dynamic-deps code at all it will only be to remove it.
+2014-04-16 21:15:58 dilfridge we'd need something like a revbump that only triggers update of metadata
+2014-04-16 21:15:59 wired_ TomWij, thanks
+2014-04-16 21:16:04 @ulm come up with one and we'll adopt it
+2014-04-16 21:16:06 @creffett|irssi ulm: then we stay at staus quo
+2014-04-16 21:16:21 * antarus is on few_'s side on this one, ftr ;)
+2014-04-16 21:16:24 @ulm dilfridge: yeah, but how?
+2014-04-16 21:16:27 @Zero_Chaos dilfridge: same problem as dynamic deps, once the ebuild is gone the information is gone.
+2014-04-16 21:16:38 @creffett|irssi the alternative of "revbump on all dep changes" is, to be blunt, stupid.
+2014-04-16 21:16:43 dilfridge i.e. introduce one more version level -r0-s1 (yes I know ugly)
+2014-04-16 21:16:56 @ulm sub-revisions ;) like sub-slots
+2014-04-16 21:16:59 @creffett|irssi dilfridge: could have it stored in the ebuild itself
+2014-04-16 21:17:11 @creffett|irssi METADATA_VERSION="0"
+2014-04-16 21:17:21 dilfridge but then portage has to read the file
+2014-04-16 21:17:26 @TomWij dilfridge, creffett|irssi: Sounds like overengineering to me somehow.
+2014-04-16 21:17:33 @Zero_Chaos creffett|irssi: then devs would need to bump it by hand
+2014-04-16 21:17:43 @creffett|irssi I'm just spitballing right now
+2014-04-16 21:17:54 @creffett|irssi so my ideas should be taken with a grain of salt
+2014-04-16 21:17:56 @TomWij Do we need dependency information in /var/db/pkg?
+2014-04-16 21:18:06 dilfridge yes.
+2014-04-16 21:18:07 @ulm TomWij: yes
+2014-04-16 21:18:10 @Zero_Chaos TomWij: YES
+2014-04-16 21:18:11 @Zero_Chaos :-)
+2014-04-16 21:18:35 dilfridge because if a package is removed otherwise things would really go down hard.
+2014-04-16 21:18:35 @TomWij I guess ... for the subslot information? Or are there other reasons?
+2014-04-16 21:18:56 @ulm TomWij: it reflects the state of installed packages
+2014-04-16 21:18:56 @Zero_Chaos TomWij: when ebuilds are removed the only information we have left are in /var/db/pkg
+2014-04-16 21:18:58 dilfridge (removed from portage)
+2014-04-16 21:19:06 @ulm including their dependencies
+2014-04-16 21:19:15 @TomWij dilfridge: But for what do you need to know the dependencies of a package?
+2014-04-16 21:19:17 @Zero_Chaos TomWij: that's the problem with all of this. when ebuilds are removed
+2014-04-16 21:19:31 @Zero_Chaos TomWij: if we never removed ebuilds, dynamic deps would be near perfect actually.
+2014-04-16 21:19:32 @ulm TomWij: for depcleaning, for example
+2014-04-16 21:19:56 @TomWij Hmm, right; it can't just pick another version from the Portage tree.
+2014-04-16 21:20:15 * dilfridge back later
+2014-04-16 21:20:20 @Zero_Chaos dilfridge: peace
+2014-04-16 21:21:15 @TomWij ulm: Before a depclean a full world upgrade should be done; and thus, that would ensure you don't have packages with no dependencies...
+2014-04-16 21:21:40 @creffett|irssi for now, can we agree on pushing this to PMS/portage teams?
+2014-04-16 21:21:44 @TomWij creffett|irssi: Yes.
+2014-04-16 21:21:46 @Zero_Chaos yes
+2014-04-16 21:21:49 wired_ yeah
+2014-04-16 21:22:02 @WilliamH yes
+2014-04-16 21:22:02 @creffett|irssi good enough for me
+2014-04-16 21:22:09 @creffett|irssi next topic: QA bugs
+2014-04-16 21:22:12 * TomWij still awaits an actual example for why dependencies are needed in /var/db/pkg, feel free to /query or mail me later.
+2014-04-16 21:22:44 @Tommy[D] by "pushing to PMS/portage team" you mean asking them for their input? or should they decide what to do?
+2014-04-16 21:22:44 @creffett|irssi the first one--nothing to do there, that's just Pinkbyte following up on our decision a couple months ago re: USE=multislot
+2014-04-16 21:22:53 @creffett|irssi Tommy[D]: their decision
+2014-04-16 21:23:35 @Tommy[D] ok with me
+2014-04-16 21:23:37 @creffett|irssi second bug, re: readme.gentoo.eclass: anyone have input on that?
+2014-04-16 21:24:03 * WilliamH doesn't think we can do much there, that eclass isn't part of policy...
+2014-04-16 21:24:29 @ulm any dev can help with that bug
+2014-04-16 21:24:34 @WilliamH Right.
+2014-04-16 21:24:42 @ulm e.g. file bugs for packages
+2014-04-16 21:24:44 @TomWij WilliamH: Yeah, I think it's somewhat less important than EAPI migration, "respecting *FLAGS" bugs, ...; it's nice to have, but it isn't really covered by policy / a big need / ...
+2014-04-16 21:24:55 @ulm so it's not a exclusive qa task
+2014-04-16 21:24:56 @TomWij ... but indeed, anyone can still help with it.
+2014-04-16 21:25:06 @creffett|irssi agreed, we can add it to the list of stuff anyone can help with vaguely QA-related
+2014-04-16 21:25:50 @TomWij creffett|irssi: And then I've put "..." for input on whether there were other bugs we should look into; because sometimes I see bugs pass on the alias, eg. pax-mark but I wonder if someone looks into them.
+2014-04-16 21:26:16 @creffett|irssi TomWij: they've been there for a while; whether they're our problem or not is something we can discuss later
+2014-04-16 21:26:22 @TomWij (Sometimes it's hard to tell what the QA involvement is and whether QA should be involved)
+2014-04-16 21:26:44 @TomWij Yeah, okay, let's move on them; just wanted to make sure we're not losing our view on open bugs, ... :)
+2014-04-16 21:26:49 @TomWij then*
+2014-04-16 21:28:01 @creffett|irssi kk
+2014-04-16 21:28:43 @creffett|irssi next: handling internal disagreements
+2014-04-16 21:29:18 @Zero_Chaos "I"ll kill you all!!!!"
+2014-04-16 21:29:36 @creffett|irssi sounds about right.
+2014-04-16 21:29:42 @TomWij creffett|irssi: That agenda item is based on rich0's mails to us.
+2014-04-16 21:29:43 @WilliamH lol
+2014-04-16 21:29:49 @creffett|irssi TomWij: I know
+2014-04-16 21:30:07 @Zero_Chaos I think it's important that we clarify that the team is allowed to act individually. Some people seem to think we need to vote on EVERY SINGLE LITTLE THING and that's just not useful.
+2014-04-16 21:30:23 @creffett|irssi my suggestion: even if you don't agree with a QA member's action, back them publicly, discuss privately
+2014-04-16 21:30:40 wired_ or don't say anything publicly
+2014-04-16 21:30:40 @Zero_Chaos I think using best judgement as when to ask others, and discussion when needed.
+2014-04-16 21:30:43 @Zero_Chaos creffett|irssi: great idea
+2014-04-16 21:30:53 @creffett|irssi and if there is an issue, we discuss, we vote, and then we make a change if needed--but we only change after discussion
+2014-04-16 21:31:01 wired_ you don't have to agree, just don't make a big deal of it in public
+2014-04-16 21:31:06 @TomWij wired_++, don't even back them
+2014-04-16 21:31:08 @creffett|irssi wired_: works for me
+2014-04-16 21:31:17 @creffett|irssi but don't disagree in public is the end goal
+2014-04-16 21:31:28 @TomWij creffett|irssi: What is considered public? :D
+2014-04-16 21:31:59 @ulm any public medium
+2014-04-16 21:32:00 @TomWij I mean, when the discussion is in #gentoo-qa; we have no #gentoo-qa-private.
+2014-04-16 21:32:07 @ulm mailing lists, irc etc.
+2014-04-16 21:32:08 @TomWij Or should we then move to the mail alias?
+2014-04-16 21:32:40 @TomWij Though the mail alias is slow.
+2014-04-16 21:33:08 @ulm TomWij: not sure
+2014-04-16 21:33:19 @Zero_Chaos TomWij: the mail alias is slow, but it actually gets the whole team, unlike irc.
+2014-04-16 21:33:20 @ulm reading long irc backlogs is slow, too
+2014-04-16 21:33:50 @creffett|irssi I'd suggest the alias for this
+2014-04-16 21:34:10 @TomWij Zero_Chaos, ulm: Good points, thanks.
+2014-04-16 21:34:50 * WilliamH is concerned still about the definition of "breakage", is that something we should discuss somewhere else?
+2014-04-16 21:35:04 @creffett|irssi WilliamH: I think we need a whole meeting for that argument.
+2014-04-16 21:35:06 @Zero_Chaos creffett|irssi: so official policy to not pull support of team members in public without consensus?
+2014-04-16 21:35:25 * Zero_Chaos fractures WilliamH's arm
+2014-04-16 21:35:25 @creffett|irssi Zero_Chaos: yes, and I acknowledge that I wasn't following that policy recently
+2014-04-16 21:35:28 @creffett|irssi and I'm sorry for that
+2014-04-16 21:35:36 @Zero_Chaos WilliamH: don't worry, it's not broken.
+2014-04-16 21:35:51 @WilliamH Zero_Chaos: heh
+2014-04-16 21:36:05 @Zero_Chaos creffett|irssi: some recent events were not handled in a cohesive manner. I look forward to all of us acting more like a team.
+2014-04-16 21:36:24 @Zero_Chaos creffett|irssi: i think this policy will help that. we can't all be countermanding each other in public.
+2014-04-16 21:36:37 @creffett|irssi mhm
+2014-04-16 21:37:02 @TomWij WilliamH: Would need you to make a full list of the user visible effects, categorize them in different categories and then mark them as not at all breakage, almost not at all breakage, might be breakage, somewhat breakage, half broken, ...
+2014-04-16 21:37:34 @creffett|irssi so, for an official policy: if a QA member takes an action other team members disagree with, it should be discussed privately within the team, and reverted only by team vote. Team members who disagree with the action should not discuss this until the vote is taken.
+2014-04-16 21:37:40 @creffett|irssi how's that sound?
+2014-04-16 21:38:02 @ulm not discuss this *in public*
+2014-04-16 21:38:09 @creffett|irssi right.
+2014-04-16 21:38:52 @wired ++
+2014-04-16 21:38:53 @creffett|irssi further additions/comments?
+2014-04-16 21:39:04 @creffett|irssi if not, I'd like to call a vote
+2014-04-16 21:39:25 @Zero_Chaos creffett|irssi: I believe the only part of this which is new is the "don't discuss in public". team vote isn't needed for lead/deputy action, so do not wish to tie hands with "only after vote"
+2014-04-16 21:39:33 @TomWij creffett|irssi: And leads can still override that? (but are accountable / responsible themselves when doing so)
+2014-04-16 21:39:35 @WilliamH Can any team member call another member's action up for a vote?
+2014-04-16 21:39:53 @Zero_Chaos creffett|irssi: specifically in the recent challenge to action, WilliamH and I agreed to talk to a lead/deputy instead of voting.
+2014-04-16 21:40:01 @Zero_Chaos WilliamH: YES
+2014-04-16 21:40:02 @TomWij Not in general, as a form of power; but rather, to prevent abuse.
+2014-04-16 21:40:07 @creffett|irssi WilliamH: yes
+2014-04-16 21:40:12 @creffett|irssi TomWij: clarify
+2014-04-16 21:40:12 @Zero_Chaos WilliamH: I'm 100% for that.
+2014-04-16 21:40:22 @Zero_Chaos WilliamH: but as for anything else, if possible discuss first.
+2014-04-16 21:40:24 @TomWij creffett|irssi: Clarify what you want me to clarify?
+2014-04-16 21:40:37 @creffett|irssi TomWij: I want you to clarify the things I want you to clarify. Clearly.
+2014-04-16 21:40:52 @creffett|irssi TomWij: what actions by leads would be exempt from this rule?
+2014-04-16 21:41:10 @wired IMO the lead/deputy has the power to overrule any action without vote if they deem it a serious mistake
+2014-04-16 21:41:20 @Zero_Chaos creffett|irssi: ALL.
+2014-04-16 21:41:21 @wired but they would be responsible for that action
+2014-04-16 21:41:37 @creffett|irssi does the rest of the team feel that way?
+2014-04-16 21:41:41 @Zero_Chaos creffett|irssi: power structure is member, vote of members, deputy overrule, lead overrule.
+2014-04-16 21:42:16 @ulm the lead cannot overrule a team vote
+2014-04-16 21:42:22 @wired well, no, lead is lead, but team > lead IMO, if you have 8/10 saying A and lead says B
+2014-04-16 21:42:25 @wired it's A, bot B
+2014-04-16 21:42:34 @wired not*
+2014-04-16 21:42:35 @TomWij creffett|irssi: Ah, "override" here means: QA dev does an action widely breaking a @system package but claims it to fix breakage as a form of abuse, QA lead reverts and takes the accountability / responsibility on him.
+2014-04-16 21:42:41 @Zero_Chaos okay, so "member, deputy, lead, team vote"?
+2014-04-16 21:42:59 @Zero_Chaos that seems fair to me ^^
+2014-04-16 21:43:40 @TomWij creffett|irssi: I was NOT saying "this is a rule affecting the team but not leads", but saying "if someone acts under this rule, can leads undo it without a vote if really necessary?".
+2014-04-16 21:43:49 * WilliamH agrees with wired
+2014-04-16 21:44:02 @wired I feel we are nitpicking this too much
+2014-04-16 21:44:09 @wired too much politics :p
+2014-04-16 21:44:37 @creffett|irssi so...someone give me a wording we can all agree on
+2014-04-16 21:44:38 @WilliamH The deputy then the lead are the highest authority on the team.
+2014-04-16 21:45:03 @TomWij wired, Zero_Chaos: Yes, "member, deputy, lead, team vote"; I'm talking about the action by the member, not about the vote of the team.
+2014-04-16 21:45:04 @WilliamH so they have the authority to override any actions.
+2014-04-16 21:45:26 @ulm it's outlined in glep 48
+2014-04-16 21:45:44 @WilliamH and remember the lead is approved by the council.
+2014-04-16 21:45:45 @Zero_Chaos A team member may act on their own. Any action by a member may be overruled by the deputy or lead without a vote if needed, however, the highest authority in the team will be a team vote.
+2014-04-16 21:45:47 @ulm if there's disagreement amongst members, a team vote is needed
+2014-04-16 21:45:53 @Zero_Chaos something like this ^^?
+2014-04-16 21:46:03 @ulm that includes disagreements between a member and the lead
+2014-04-16 21:46:55 @TomWij Zero_Chaos: Where did the discuss in private go? :D
+2014-04-16 21:47:55 @WilliamH ulm: ok, so if I do something and creffett removes me from the team for it, can the rest of the team force him to reinstate me?
+2014-04-16 21:48:30 @creffett|irssi that one I will object to; removing people from the team is the one power that is explicitly given to the team lead
+2014-04-16 21:48:37 @ulm WilliamH: can the lead actually remove members from the team?
+2014-04-16 21:48:42 @Zero_Chaos A QA team member may act on their own. If there is any dispute of a QA member's action, it should be in private. Any action by a member may be overruled by the deputy or lead without a vote if needed, however, the highest authority in the team will be a team vote.
+2014-04-16 21:48:46 @Zero_Chaos better?
+2014-04-16 21:49:15 @Zero_Chaos creffett|irssi: where do you see that power assigned to you?
+2014-04-16 21:49:18 @creffett|irssi wait, no it isn't
+2014-04-16 21:49:19 @WilliamH ulm: I think so?
+2014-04-16 21:49:19 @creffett|irssi adding people is
+2014-04-16 21:49:24 @Zero_Chaos creffett|irssi: bingo
+2014-04-16 21:49:25 @creffett|irssi oh well
+2014-04-16 21:49:27 @TomWij Zero_Chaos: Isn't this in metastructure?
+2014-04-16 21:49:36 @Zero_Chaos TomWij: show me, I've never seen it
+2014-04-16 21:49:52 @WilliamH flameeyes sure did ;-)
+2014-04-16 21:49:55 @Zero_Chaos anyway, shall we add this to our wiki page? :
+2014-04-16 21:49:57 @Zero_Chaos A QA team member may act on their own. If there is any dispute of a QA member's action, it should be in private. Any action by a member may be overruled by the deputy or lead without a vote if needed, however, the highest authority in the team will be a team vote.
+2014-04-16 21:50:01 @Zero_Chaos ^^ ?
+2014-04-16 21:50:05 @wired QA team members may act on their own. All internal disagreements on said actions must be handled privately between QA members. The Lead/Deputy may revert any action if they believe it was a mistake, but they will be held responsible for that change. All disagreements are to be settled by team votes.
+2014-04-16 21:50:05 @wired or something
+2014-04-16 21:50:29 @TomWij Zero_Chaos: It neither says something about voting. :-$
+2014-04-16 21:50:37 @ulm wired: that sounds good
+2014-04-16 21:50:41 @creffett|irssi +1
+2014-04-16 21:50:46 @Zero_Chaos wait one
+2014-04-16 21:50:52 * creffett|irssi waits
+2014-04-16 21:51:04 @Zero_Chaos "All disagreements are to be settled by team votes" is a requirement
+2014-04-16 21:51:08 @Zero_Chaos not an option
+2014-04-16 21:51:11 @Zero_Chaos it needs to be an option
+2014-04-16 21:51:23 @Zero_Chaos If the lead acts we don't have to vote still
+2014-04-16 21:51:25 @TomWij Again, where did the discussion in private go?
+2014-04-16 21:51:35 @TomWij Ah
+2014-04-16 21:51:40 * TomWij reads *again*.
+2014-04-16 21:51:40 @Zero_Chaos TomWij: you are skipping lines dude ;-)
+2014-04-16 21:52:22 @Zero_Chaos "If the Lead/Deputy action is disputed a team vote will be used to settle the disagreement."
+2014-04-16 21:52:26 @Zero_Chaos is that okay?
+2014-04-16 21:52:35 @Tommy[D] Zero_Chaos: if the lead acts and everyone does agree, there is no disagreement anymore, so no need to vote, but if there is still some disagreement, there should be a vote
+2014-04-16 21:52:45 @Zero_Chaos QA team members may act on their own. All internal disagreements on said actions must be handled privately between QA members. The Lead/Deputy may revert any action if they believe it was a mistake, but they will be held responsible for that change. If the Lead/Deputy action is disputed a team vote will be used to settle the disagreement.
+2014-04-16 21:53:03 wired_ meh
+2014-04-16 21:53:21 @Zero_Chaos Tommy[D]: "All disagreements" means that once there is a disagreement it must be voted upon.
+2014-04-16 21:53:29 @Tommy[D] Zero_Chaos: now you are missing the vote for team member disagreements ;)
+2014-04-16 21:53:40 wired_ something is srly wrong with this thing today. haven't read anything after my last message
+2014-04-16 21:54:09 @TomWij wired_: Don't worry, we're forming the statement we'll vote on; I think Zero_Chaos will very soon post another revision of it.
+2014-04-16 21:54:13 @Tommy[D] the last suggestion from wired looks good to me
+2014-04-16 21:54:30 @WilliamH Zero_Chaos: I don't quite read it that way. The statement with "all disagreements" just refers to not discussing them in public.
+2014-04-16 21:54:36 @Zero_Chaos QA team members may act on their own. All internal disagreements on said actions must be handled privately between QA members. The Lead/Deputy may revert any action if they believe it was a mistake, but they will be held responsible for that change. Any action which is disputed can be settled by a team vote.
+2014-04-16 21:55:08 @Zero_Chaos WilliamH: the line in question read: "All disagreements are to be settled by team votes" that means if there is a disagreement it MUST be voted on.
+2014-04-16 21:55:14 @creffett|irssi One addition: "by a team vote, and the result of that vote will be the final decision"
+2014-04-16 21:55:18 wired_ well, it should be
+2014-04-16 21:55:26 @creffett|irssi just to make it clear that a team vote trumps all
+2014-04-16 21:55:36 wired_ if there's a disagreement, I want it settled
+2014-04-16 21:55:40 wired_ not floating around
+2014-04-16 21:56:06 @Zero_Chaos QA team members may act on their own. All internal disagreements on said actions must be handled privately between QA members. The Lead/Deputy may revert any action if they believe it was a mistake, but they will be held responsible for that change. Any action which is disputed can be settled by a team vote, and the result of that vote will be the final decision.
+2014-04-16 21:56:11 @Zero_Chaos ^^ vote?
+2014-04-16 21:56:23 @TomWij Wait.
+2014-04-16 21:56:30 @Zero_Chaos waiting :-)
+2014-04-16 21:56:38 @TomWij How about non-internal disagreements?
+2014-04-16 21:56:49 @WilliamH TomWij: separate issue.
+2014-04-16 21:56:57 @Zero_Chaos those are obviously not required to be in private :-)
+2014-04-16 21:57:03 @WilliamH TomWij: not relevant for this vote.
+2014-04-16 21:57:13 @TomWij Okay.
+2014-04-16 21:57:20 @Zero_Chaos this is our policy for us
+2014-04-16 21:57:28 @TomWij +1 on Zero_Chaos last statement.
+2014-04-16 21:57:32 @Zero_Chaos there is already an escalation policy for people outside QA disputing QA actions.
+2014-04-16 21:57:35 @Zero_Chaos so vote
+2014-04-16 21:57:43 @creffett|irssi +1 from me
+2014-04-16 21:57:47 @Zero_Chaos +1
+2014-04-16 21:57:59 @ulm +1
+2014-04-16 21:58:07 @Tommy[D] +1
+2014-04-16 21:58:15 * WilliamH yes
+2014-04-16 21:58:40 @Zero_Chaos that's 6, and poor wired is probably still having connection issues.
+2014-04-16 21:58:51 @wired +1, but can be settled sounds vague
+2014-04-16 21:59:00 @creffett|irssi 7, good enough for me
+2014-04-16 21:59:20 @Zero_Chaos wired: it really isn't, it means you *can* vote but you are not required to.
+2014-04-16 21:59:31 @Zero_Chaos creffett|irssi: may i add this to the wiki then?
+2014-04-16 21:59:36 @creffett|irssi since we've been going two hours, I suggest that we handle one minor issue, then meet again next Wednesday
+2014-04-16 21:59:39 @creffett|irssi Zero_Chaos: go for it
+2014-04-16 21:59:46 @wired I want to settle all issues, so can't is vague for me
+2014-04-16 21:59:54 @wired I don't want to leave conflicts around
+2014-04-16 22:00:26 @creffett|irssi wired: it will be settled in some capacity, and I don't expect that people who have disputes will let them go until they've been completely settled :)
+2014-04-16 22:00:29 @TomWij * Where and how will we document what QA processes for both current and future Gentoo Developers and QA members? (Per Council meeting: "the council notes that QA is looking into documenting their process"). [~ 5 min]
+2014-04-16 22:00:30 @TomWij * Are there unclarities wrt what "QA team" and similar things mean in GLEP 48? An individual or the whole team? With agreement or not? Do we need to suggest a change to Council? [~ 10 min]
+2014-04-16 22:00:30 @TomWij * Move QA policies to the devmanual? [~ 5 min]
+2014-04-16 22:00:30 @TomWij * What will we do about the missing QA meeting logs and summaries? [~ 5 min]
+2014-04-16 22:00:33 @TomWij ^ Take your pick. :D
+2014-04-16 22:00:37 @Tommy[D] if you want a vote, request it and you get it, but if someone wants to leave the discussion without vote, that should be ok too
+2014-04-16 22:00:46 @Zero_Chaos wired: then it would be voted on, or abandoned (and there is no more conflict)
+2014-04-16 22:00:47 @creffett|irssi I'm up for the last one
+2014-04-16 22:01:08 @wired creffett|irssi: yeah, thats what I'm hoping for. TBH, this policy is a bit redundant, the only important thing stated here is that we should avoid conflicts in the open so we don't look bad
+2014-04-16 22:01:11 @creffett|irssi can I get volunteers to find, summarize, and email out/add to wiki the results of both this meeting and the last meeting?
+2014-04-16 22:02:30 @creffett|irssi last meeting wasn't too bad, the only major change iirc was clarifying the drop-last-stable policy
+2014-04-16 22:02:34 @creffett|irssi don't all volunteer at once.
+2014-04-16 22:03:20 @Zero_Chaos creffett|irssi: way to kill a meeting dude
+2014-04-16 22:03:23 @Zero_Chaos :-)
+2014-04-16 22:03:31 @TomWij creffett|irssi: You're going to have to pick people. :D
+2014-04-16 22:03:32 @WilliamH lol
+2014-04-16 22:03:39 @Zero_Chaos fine, I'll do this meeting
+2014-04-16 22:03:46 @creffett|irssi Zero_Chaos: thank you
+2014-04-16 22:03:49 @Zero_Chaos someone else volunteer, not like I want to do this either.
+2014-04-16 22:03:58 @creffett|irssi WilliamH: congratulations, you get to take care of last meeting's summary
+2014-04-16 22:04:13 * WilliamH doesn't have a backlog
+2014-04-16 22:04:31 @Zero_Chaos WilliamH: that was an expensive lol, I hope it was heartfelt and enjoyable.
+2014-04-16 22:04:43 @creffett|irssi who does have a log of last meeting?
+2014-04-16 22:04:51 @Zero_Chaos not I
+2014-04-16 22:04:57 wired_ I probably have one
+2014-04-16 22:05:01 @Zero_Chaos that's why i volunteer for this week :-)
+2014-04-16 22:05:08 wired_ lemme check
+2014-04-16 22:05:45 @TomWij WilliamH: Now you do:
+2014-04-16 22:05:47 @Tommy[D] you are talking about the meeting on the 26th of march?
+2014-04-16 22:05:51 @Zero_Chaos creffett|irssi: where in the hell do I add this policy for us on the wiki, I can't pick a place in the wiki that makes sense.
+2014-04-16 22:05:55 @creffett|irssi Tommy[D]: yes
+2014-04-16 22:06:02 @creffett|irssi Zero_Chaos: policy page, under team policies
+2014-04-16 22:06:11 @wired TomWij beat me to it :)
+2014-04-16 22:06:41 @TomWij Yeah, had it still open.
+2014-04-16 22:06:48 @creffett|irssi WilliamH: okay, there's your backlog. summarize :)
+2014-04-16 22:07:18 @creffett|irssi anyway, meet next week, same time same place?
+2014-04-16 22:07:20 @TomWij Here is a automatically generated summary: {"sentences":["Zero_Chaos: I agree, especially when this summer comes and I actually have a job to keep.","creffett|irssi: who is marking them exp?. creffett|irssi: and on what authority?. in case of doubt me .","creffett|irssi: ^^.","creffett|irssi: I was a little confused on your last point, I think I got it right though.","I apologize, I have a flight to
+2014-04-16 22:07:20 @TomWij catch."]}
+2014-04-16 22:07:41 @wired lol
+2014-04-16 22:07:54 @creffett|irssi that...didn't work at all
+2014-04-16 22:08:03 @TomWij (Produced with
+2014-04-16 22:08:25 @TomWij Works quite good on news articles and scientific papers; but yeah, not on meetings.
+2014-04-16 22:08:34 @creffett|irssi okay, no objections to same time same place
+2014-04-16 22:08:38 * creffett|irssi bangs the gavel
+2014-04-16 22:08:39 @Tommy[D] next week, same time should work, would be nice to have a reminder at least some hours before it (in irc+mail) in case i forgot it
+2014-04-16 22:08:43 @creffett|irssi Tommy[D]: will do
+2014-04-16 22:08:47 @Zero_Chaos <-- anyone have an issue with the heading name?
+2014-04-16 22:08:56 @wired thanks, c ya guys
+2014-04-16 22:08:59 @Zero_Chaos thanks all
+2014-04-16 22:09:05 @creffett|irssi Zero_Chaos: lgtm
+2014-04-16 22:09:30 @Zero_Chaos creffett|irssi: I always try to figure out what sex act that is for at least 10 seconds before I remember what it means.
+2014-04-16 22:11:51 @TomWij So, from a quick look the next meeting is about documenting QA processes further (council's statement), are there unclarities in GLEP (raised on project ML, I'll find that mail back by next week) and moving QA policies (and perhaps ComRel's dev handbook) to devmanual as well as about anything that comes up by then.
+2014-04-16 22:12:15 @TomWij None of them urgent.
+2014-04-16 22:12:51 @WilliamH TomWij: Yeah, there was a discussion a while back about putting all of our policies in one place, but I don't know what happened to it.
+2014-04-16 22:13:18 @TomWij WilliamH: It was put at the bottom of I figured out today.
+2014-04-16 22:17:14 @Zero_Chaos creffett|irssi: we just do meeting summaries right? we don't preserve the entire meeting log? we probably should have the whole log available to be able to show the summary is correct....
+2014-04-16 22:19:10 @TomWij Zero_Chaos: We should have the logs online; wired for example did for the first, the second is yet to be filled in.
+2014-04-16 22:20:07 @Zero_Chaos TomWij: roger that
+2014-04-16 22:24:49 @TomWij (It's just opinion; but under the thought that we're forming policies that affect all developers, and because of that how they were formed should be available to those interested in them. Otherwise you get the behind closed door effect; or misconceptions, when someone really doesn't understand how we came to a decision, for what reason [background, reasoning, etc...])
+2014-04-16 22:33:00 @Zero_Chaos TomWij: agreed, I didn't see the other logs and was concerned for exactly those reasons.
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,
+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 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
+2014-04-23 19:24:42 * TomWij isn't sure if 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;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
+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
diff --git a/meeting-logs/20141203.txt b/meeting-logs/20141203.txt
new file mode 100644
index 0000000..463d60e
--- /dev/null
+++ b/meeting-logs/20141203.txt
@@ -0,0 +1,487 @@
+Timestamps are in UTC+3
+[22:05:53] <zlogene> ok, first meeting after months
+[22:06:13] <Pinkbyte> creffett, i can do it, start recording log right now just in case...
+[22:06:18] <creffett> Pinkbyte: okay
+[22:06:46] * zlogene writes logs too
+[22:06:51] <zlogene> fyi
+[22:06:59] <creffett> so, let's start with elections
+[22:07:17] <creffett> if you want to run, please email the alias saying as much and with a short statement of why people should vote for you
+[22:07:41] <creffett> we'll leave that open until next tuesday, at which point I'd like to do a helios vote, same as what we did last year
+[22:07:45] <creffett> any objections?
+[22:07:56] * zlogene is ok
+[22:08:02] <mgorny> no objections, move forward ;P
+[22:08:05] <ulm> ok
+[22:08:17] <Tommy[D]> ok
+[22:08:26] <Pinkbyte> creffett, everything is clear, ok
+[22:08:35] <wired> +1
+[22:08:45] <creffett> that said, I strongly suggest people step up to run, it would be very sad if QA were without a lead
+[22:09:18] * wired doesn't have enough time for this, unfortunately
+[22:09:42] <zlogene> creffett, do you plan to continue your leadership, btw?
+[22:09:47] <creffett> zlogene: I do not
+[22:10:11] <Pinkbyte> That would be sad, i think you are doing very well
+[22:10:18] <ulm> +1
+[22:10:31] <creffett> I disagree with you, but that's a discussion we can have outside of meeting time
+[22:10:40] <creffett> back to the agenda:
+[22:10:56] <creffett> TomWij isn't here to talk about it, unfortunately
+[22:11:11] <creffett> agenda says to review it. Do we have any input? do we like it? do we care?
+[22:11:22] <Pinkbyte> creffett, my opinion after quick look - this should be posted officially as is, no major changes required
+[22:11:41] <ulm> IMHO doesn't make sense to discuss without TomWij
+[22:11:50] <Pinkbyte> and yes, we care. Clearly said what is QA area of responsibility is a good point
+[22:11:54] <ulm> and it's already online ;)
+[22:11:58] <creffett> well, according to the Wiki page, TomWij isn't part of the team, so...
+[22:12:04] <creffett> that's a bit of an issue
+[22:12:12] <zlogene> in general it looks good to me
+[22:12:27] <creffett> personally I'm happy with it in general, but would like to rewrite it to be more concise
+[22:13:06] <Pinkbyte> creffett, o_O. How it's possibly? I saw him in our project page with a 'Deputy lead' in description. Probably something breaks :-/
+[22:13:31] <zlogene> Pinkbyte, his account has been deleted it seems
+[22:13:36] <creffett> Pinkbyte: he removed himself from pretty much all of his projects a couple weeks ago
+[22:13:39] <creffett> !away TomWij
+[22:13:40] <willikins> creffett: tomwij: I am taking a break from Gentoo. I don't think I'm ready to retire, but I think I need a break to decide. Still present to talk if you can catch me... @ 2014/09/10 12:28Z
+[22:13:45] <ulm> Pinkbyte:
+[22:13:45] <creffett> ^^ there we go
+[22:14:25] <creffett> so let's put this off until next meeting, I will rewrite it a little to make it more understandable
+[22:14:32] <ulm> and he was doing well, too
+[22:14:35] <ulm> IMHO
+[22:14:45] <Pinkbyte> That's sad too. We have some disagreement with him in a past, but he did a good job. Hope he will come back
+[22:15:22] <creffett> yeah, well, it is what it is
+[22:15:43] <creffett> any other input on the Inquiry article for now?
+[22:15:57] <zlogene> no
+[22:16:34] <Pinkbyte> creffett, no, as i said - i think it's good to go right now, but if you want to reword it to be more clearer - i do not mind
+[22:16:39] <creffett> Pinkbyte: okay
+[22:16:53] <creffett> next topic, then
+[22:16:59] <creffett> Review the games team policies: games group, forcing /usr/games when upstream does not use it, games.eclass (points 3-5 in mgorny's reply of last Council agenda, deferred by Council to be discussed by QA).
+[22:17:06] <creffett> mgorny: talk to us
+[22:17:08] <mgorny> yay, finally
+[22:17:29] <mgorny> so pretty much council said we don't have to use games.eclass but specific policies should be discussed by qa
+[22:17:42] <mgorny> games team had no input except that i'm stupid
+[22:17:46] <creffett> as expected
+[22:17:55] <creffett> mgorny: what specifically do you want us to vote on?
+[22:17:55] <ulm> kill it with fire
+[22:18:01] <ulm> the eclass, that it
+[22:18:03] <ulm> *is
+[22:18:03] <mgorny> i think we should decide on some goals to get things consistent
+[22:18:11] <zlogene> as usual...
+[22:18:13] <mgorny> 1) install stuff as upstream wants (preferably to /usr)
+[22:18:28] <creffett> mgorny: does games.eclass provide any utility other than forcing /usr/games and the games group?
+[22:18:34] <mgorny> 2) remove games group as currently defined, open access to games
+[22:18:45] * ulm notes that the FHS has /usr/games, /usr/share/games, and /var/games
+[22:19:05] <mgorny> creffett: i think there's one function to do wrappers and one unpacker
+[22:19:07] <ulm> with binaries directly in /usr/games, not /usr/games/bin
+[22:19:13] <Pinkbyte> creffett, i wrote some games ebuilds using games.eclass. And - basically no. Only plenty of functions to force such behaviour
+[22:19:17] <mgorny> but the wrappers are probably /usr/games-related
+[22:19:18] <creffett> k
+[22:19:22] <mgorny> and the unpacker is in unpacker.eclass too
+[22:19:35] <creffett> okay then
+[22:19:45] <Pinkbyte> ulm, yeah, some FHS compatibility is one thing that stops me to say 'god damn, just go with games like with any other normal application in Gentoo!"
+[22:20:11] <creffett> so stop forcing weird install locations, kill games group, eventually kill games.eclass (and make it non-mandatory for now)?
+[22:20:25] <mgorny> it's non-mandatory already but some developers are confused
+[22:20:40] <mgorny> and some people (games team?) tell others to use it
+[22:20:41] <creffett> games team says otherwise ;)
+[22:21:09] <creffett> anyone have comments on these before we vote?
+[22:21:10] <mgorny> which brings up to things like gnome wasting time converting their ebuild to games.eclass
+[22:21:22] <mgorny> because someone told them to
+[22:21:24] <ulm> mgorny: so usual rules, install to /usr
+[22:21:27] <ulm> and /opt if it's a binary pkg?
+[22:21:38] <mgorny> yes, if you believe so
+[22:21:53] <mgorny> though i think /opt is more like /opt/company/fancything
+[22:22:02] <mgorny> when it can't work with /usr layout
+[22:22:54] <Pinkbyte> mgorny, in Gentoo i often see that /opt is used for binary-only stuff
+[22:23:08] <mgorny> i know
+[22:23:19] <mgorny> but that's another topic, so let's not bother ourselves with it
+[22:23:24] <ulm> actually, do we have a policy on this?
+[22:23:29] <mgorny> maybe i'll write a GLEP for simple filesystem layout at some point
+[22:23:42] <mgorny> i'm sure people will be very happy to see it
+[22:23:51] <creffett> ulm: I'm not certain, I know that's unofficial policy for a long time at least
+[22:24:21] <mgorny> another common choice is /usr/lib/whatever
+[22:24:25] <mgorny> i think FHS allows both
+[22:24:33] <mgorny> (firefox, opera, chromium)
+[22:24:49] <mgorny> oh wait, you said binary-only, then opera ;P
+[22:24:50] <ulm> creffett: we do: "Binary-only applications must not be installed outside of /opt."
+[22:24:56] <ulm>
+[22:24:59] <creffett> ulm: okay, that works
+[22:25:23] <creffett> any further discussion on the games topics, or are we ready to vote?
+[22:25:31] <wired> I feel games is way too broad a category of packages for one team to enforce things like install location. as long as the package is not doing something stupid, I do not see any reason to enforce stuff on it just because it's a game.
+[22:25:38] <ulm> anyway, we can simply say that games should follow our normal rules
+[22:25:59] <creffett> yeah
+[22:26:41] <Pinkbyte> ulm, +1 from me
+[22:26:45] <creffett> vote 1: games team should stop forcing install locations to /usr/games/bin and other odd locations.
+[22:27:02] <Pinkbyte> i am for it
+[22:27:03] <Tommy[D]> isnt clear to me
+[22:27:03] * ulm yes
+[22:27:04] * creffett yes
+[22:27:14] <creffett> Tommy[D]: would "follow upstream" be better?
+[22:27:22] * zlogene yes
+[22:27:25] * mgorny yes
+[22:27:38] <Tommy[D]> e.g. is that for all packages, for those with group=games and maintainer or only those with games as maintainer?
+[22:27:39] <ulm> creffett: "follow upstream and gentoo policies"
+[22:27:39] <wired> yes
+[22:27:42] <Pinkbyte> creffett, follow upstream, unless it breaks gentoo rules. I mean - if upstream forces installing to /usr/local - screw it
+[22:27:45] <creffett> okay
+[22:28:11] <creffett> Tommy[D]: the gist of these all is going to be "games team isn't special and should follow the rules the rest of Gentoo follows"
+[22:28:17] <ulm> Pinkbyte's wording is better than mine
+[22:28:26] <creffett> okay
+[22:28:44] <mgorny> does that request them to change the eclass?
+[22:28:49] <creffett> mgorny: we're getting there ;)
+[22:28:59] <Tommy[D]> creffett: my point is, that imho games team should be allowed to create whatever policy they want for the packages they actually maintain, but others maintaining games themselves should not be forced to follow it
+[22:29:05] <wired> I don't mind if some dev feels that a game belongs to a different folder (because of size), we just shouldn't force everyone to do it
+[22:29:36] <mgorny> size is rather a poor argument for /usr/games
+[22:29:43] <mgorny> esp. that games data goes into /usr/share/games
+[22:30:07] <creffett> Tommy[D]: I don't agree, games team should follow the same rules as everyone else
+[22:30:43] <Tommy[D]> creffett: games team uses games eclass, kde uses kde eclass, gnome uses gnome eclass.... ;)
+[22:31:07] <creffett> Tommy[D]: and gnome and KDE all install to standard locations (given that kdeprefix died a long time ago)
+[22:31:16] <mgorny> and we dropped /usr/X11R6 too
+[22:32:04] <ulm> another relic from the 1980s :)
+[22:32:18] <creffett> heh.
+[22:32:22] <mgorny> next meeting we will discuss sbin :>
+[22:32:23] * mgorny hides
+[22:32:30] <creffett> next vote: kill games group
+[22:32:34] * creffett yes
+[22:32:51] * zlogene yes
+[22:32:53] <Tommy[D]> well, if the vote includes a forced change for packages actively maintained by games team, if it only prevents the games team to force their rules onto others, i am fine with it
+[22:33:00] <mgorny> kill games group as used to manage access to running games*
+[22:33:08] <creffett> mgorny: what else is it used for?
+[22:33:12] <ulm> eh, what about usage of the games group by upstream packages?
+[22:33:24] <mgorny> some upstream were using it to share scores... but we broke that by redefining games
+[22:33:25] <ulm> like setgid for accessing score files?
+[22:33:29] <creffett> ah
+[22:33:33] <creffett> I forgot about that
+[22:33:38] <mgorny> we will probably need to sed it to another group
+[22:33:51] <mgorny> or request people to remove their users from games
+[22:34:12] <creffett> what would you suggest? kill games group entirely, or just stop it from being used to restrict game access?
+[22:34:25] <ulm> the latter
+[22:34:30] <creffett> okay
+[22:34:38] * creffett is okay with that
+[22:34:42] <ulm> follow usage as it is in other distros
+[22:35:55] <creffett> anyone else planning to vote?
+[22:36:14] * mgorny yes
+[22:36:30] <ulm> what is the vote? "kill games group"?
+[22:36:36] * Pinkbyte yes
+[22:36:49] <creffett> okay, try this again
+[22:37:08] <creffett> vote to stop games group from being used to restrict access to games, it should only be used to follow usage upstream/in other distros
+[22:37:15] <creffett> ulm: is that acceptable wording?
+[22:37:19] <ulm> yes
+[22:37:24] * zlogene yes
+[22:37:24] * ulm votes yes
+[22:37:42] * creffett yes
+[22:37:54] * mgorny yes
+[22:38:06] * Pinkbyte yes
+[22:38:32] <creffett> wired, Tommy[D]
+[22:38:43] <wired> yes
+[22:38:55] <Tommy[D]> i abstain
+[22:39:00] <creffett> okay, passes
+[22:39:25] <creffett> games.eclass: do we want to completely deprecate it, or just vote to confirm that it isn't required
+[22:39:46] <mgorny> let's try deprecating. we already voted out all its features :)
+[22:39:54] <creffett> k
+[22:40:00] * WilliamH is here sorry folks
+[22:40:02] <creffett> vote to deprecate games.eclass
+[22:40:08] * mgorny yes
+[22:40:12] * zlogene yes
+[22:40:15] * WilliamH yes
+[22:40:15] * creffett yes
+[22:40:20] * ulm yes
+[22:40:31] * Tommy[D] abstain
+[22:40:35] * Pinkbyte abstain
+[22:40:59] <wired> abstain
+[22:41:23] <creffett> passes
+[22:41:26] <Pinkbyte> i'd prefer to make it non-required for generic games ebuild. When it loses most of features - it will be dropped as is, no need to force that on QA level
+[22:41:44] * creffett out, can I get a volunteer to run the rest of the meeting?
+[22:41:48] <ulm> well, deprecated != removal
+[22:41:52] <mgorny> Pinkbyte: right now games.eclass has configurable dirs
+[22:42:03] <mgorny> i'm sure some people will try to workaround our decisions
+[22:42:21] <Pinkbyte> creffett, sure, i will takeover ;-)
+[22:42:31] <creffett> Pinkbyte: okay then, thank you
+[22:42:52] <mgorny> good luck, creffett
+[22:42:53] <WilliamH> Did I miss the vote on tinfo?
+[22:42:56] <Pinkbyte> mgorny, no doubt, i know how behave some of current Games team members
+[22:42:57] <zlogene> so, forward to the next item?
+[22:42:59] <mgorny> WilliamH: not yet
+[22:43:00] <creffett> WilliamH: not yet
+[22:43:01] <zlogene> WilliamH, no
+[22:43:05] <mgorny> so far killed games
+[22:43:25] <Tommy[D]> mgorny: but i liked some games :p
+[22:44:05] <mgorny> Pinkbyte: run that meeting!
+[22:44:10] * mgorny is hungry
+[22:44:16] <Pinkbyte> mgorny, ok then
+[22:44:44] <Pinkbyte> next topic: repoman checks for missing slot/subslot operators
+[22:44:47] <Tommy[D]> anyway, 10 members, 5 votes, so it did not pass?
+[22:44:53] <Pinkbyte> mgorny, your word :-)
+[22:45:22] <mgorny> i have mixed feeling about it these days
+[22:45:35] <mgorny> but the idea was that repoman is supposed to warn you when you do RDEP+DEP on dev-libs/openssl
+[22:45:39] <ulm> Tommy[D]: generally only members being present in a meeting are counted
+[22:45:46] <mgorny> and that could match both openssl:0 and openssl:0.9.8 (which has no headers, just libs)
+[22:46:14] <Pinkbyte> mgorny, one note. Is that checks would be for RDEPEND only or on DEPEND too?
+[22:46:25] <mgorny> so you're required to either do openssl:0, openssl:* explicitly or openssl:=
+[22:46:28] <ulm> mgorny: has this been tested in a real world scenario?
+[22:46:38] <ulm> the repoman check, I mean
+[22:46:39] <mgorny> Pinkbyte: i think ulm has bikeshed it to the point of common subset of RDEP+DEP
+[22:46:47] <Tommy[D]> ulm: in previous meetings the idea was to get more then half of the members into the meeting to be able to get a vote accepted, so that is not clear to me
+[22:46:49] <mgorny> ulm: i was running it for a while ;P
+[22:46:49] <Pinkbyte> let's have some example: boost have subslots. And some app uses ONLY boost headers. Should we force some slot operator here?
+[22:47:15] <mgorny> Pinkbyte: if you can really take any slot, you can do :*
+[22:47:39] <mgorny> right now slot-less dep on slotted package is treated as semi-undefined behavior
+[22:48:05] <Pinkbyte> mgorny, boost have no slots, only subslots. Does that matter?
+[22:48:17] <mgorny> that's the second part :)
+[22:48:18] <Pinkbyte> ahhh, that's what i want to hear
+[22:48:24] <mgorny> first part is just slots in general
+[22:48:36] <mgorny> i don't remember who requested subslots anymore
+[22:48:51] <mgorny> but the second part is the same for subslots
+[22:49:06] <mgorny> i.e. dev-libs/libfoo on subslotted package bad
+[22:49:09] <ulm> what's the rationale for the subslot check?
+[22:49:18] <mgorny> either :0, :0=, :=, :* to force it
+[22:49:35] <mgorny> i.e. to force a specific subslot behavior or to silence the check
+[22:49:43] <mgorny> ulm: finding missing subslot uses, i think
+[22:50:30] <mgorny> but i'm not really convinced by that, so i put that as second item
+[22:51:03] <Tommy[D]> what happens, if a package with only :0 starts to add more slots?
+[22:51:18] <ulm> mgorny: it has the potential for false positives, I think
+[22:51:47] <mgorny> ulm: yes, it does
+[22:52:13] <mgorny> it pretty much requires us to use :* or likes to confirm stuff
+[22:52:25] <mgorny> Tommy[D]: with first check? repoman starts issuing warnings about missing slots
+[22:52:25] <Pinkbyte> so, let's reiterate. Repoman check for slots is needed for packages, that had no slots, but when they are added - it will ease migration if old ebuilds, depending on that now-slotted package, that will have category/foo:0 instead of category/foo dependency
+[22:53:43] <Tommy[D]> mgorny: so maintainer has to request all depending packages to be fixed before adding new slot?
+[22:53:58] <mgorny> or when developers are missing the fact that package is slotted, like they do a lot now
+[22:54:09] <mgorny> Tommy[D]: basically he has to do all the fixing right now
+[22:54:20] <mgorny> we just don't have any checks to help him
+[22:57:07] <Pinkbyte> Tommy[D], well, if it would be warning and not error, i do not think that this is problem. And of course, if old behaviour would not be broken until all things would be fixed
+[22:57:23] <mgorny> and if it proves to bring too many false positives, we can always revert it
+[22:57:37] <Tommy[D]> Pinkbyte: well, if there can be false positives, it cannot be an error ever
+[22:58:58] <mgorny> 'false positive' depends on how undefined behavior of lack of slot op is defined
+[22:59:01] <ulm> I'd say let's try it for slots
+[22:59:15] <mgorny> so let's get it into 3 votes
+[22:59:16] <ulm> but not for subslots, at least not immediately
+[22:59:22] <mgorny> 1. warning for missing slots
+[22:59:29] <mgorny> 2. warning for missing subslots
+[22:59:54] <mgorny> 3. recommending :* over no slot for packages that really support all slots and trigger the warning
+[22:59:56] <ulm> s/slots/slot operators/ ?
+[23:00:11] <mgorny> it can be either a slot spec or slot op
+[23:00:14] <Tommy[D]> so the exact suggestion is, that if repoman detects at least 2 versions of the dependency with different slots, that it then issues a warning, if no explicit slot is defined for the dependency?
+[23:00:15] <mgorny> i.e. :0 or := or :*
+[23:00:26] <mgorny> Tommy[D]: yes
+[23:00:58] <mgorny> (or :0/0 or :0=)
+[23:01:31] <mgorny> Tommy[D]: i can show you the patch if you want
+[23:02:21] <Pinkbyte> can we make this check works only for new revision/version?
+[23:02:31] <Tommy[D]> mgorny: thanks, but i am tired and have pretty limited time for now, so probably would not get to checking it :/
+[23:03:01] <mgorny> Pinkbyte: i don't think we have a sane way of figuring that out
+[23:03:18] <mgorny> plus, the point is to warn about package deps that used not to be slotted
+[23:03:26] <mgorny> this requires retroactive fixes
+[23:05:06] <mgorny> did others leave already? :P
+[23:05:25] * WilliamH is still here, just reading what's going on...
+[23:05:26] <Tommy[D]> maybe already sleeping :)
+[23:05:48] <ulm> so, are we going to vote on it, or what?
+[23:05:57] <Tommy[D]> i follow the suggestion of ulm: try it for slots only for now
+[23:06:26] <Pinkbyte> ok, guys, let's reiterate. Vote 1: should we enable missing slot operator check in repoman?
+[23:06:49] <mgorny> sounds right
+[23:06:54] * ulm yes
+[23:06:55] * zlogene yes
+[23:06:58] * mgorny yes
+[23:06:59] <Tommy[D]> yes
+[23:07:21] * Pinkbyte yes
+[23:07:38] * WilliamH abstain
+[23:08:13] <Pinkbyte> wired, your voice?
+[23:08:28] <wired> abstain
+[23:09:18] <Pinkbyte> so, 5 for, 2 abstain, others do not vote? Motion failed, i'd say
+[23:09:41] <mgorny> err, what?
+[23:09:42] <ulm> 7 members present
+[23:09:48] <mgorny> 5 out of 7 is failed/
+[23:09:54] <ulm> so 5 is a majority
+[23:10:05] <Pinkbyte> oh, stupid me, counted from total members
+[23:10:10] <zlogene> passed
+[23:10:14] <ulm> (given that we follow usual rules)
+[23:10:17] <Pinkbyte> it's probably too late and my brain is sleeping already
+[23:10:35] <Pinkbyte> it's passed of course, no doubt for that, if i would count it correctly :-)
+[23:11:03] <Pinkbyte> so, Vote 2: should we enable missing sub-slot operator check in repoman?
+[23:11:09] * ulm no
+[23:11:11] * Pinkbyte abstain
+[23:11:20] <ulm> not for now
+[23:11:37] * zlogene abstain
+[23:11:42] <Tommy[D]> no (not for now)
+[23:11:44] * mgorny nope
+[23:11:53] * WilliamH no
+[23:12:49] <Pinkbyte> wired, ?
+[23:14:51] <Pinkbyte> ok, i figured out that wired's voice did not change situation much in our case. Clear 'no' is said for this check for now, let's move on
+[23:15:00] <Pinkbyte> no offense, wired
+[23:15:27] <Pinkbyte> next thing: Making global-scope 'use*', 'has_version' and 'best_version' fatal in EAPI 6
+[23:15:51] <ulm> such usage was never allowed
+[23:16:03] <Pinkbyte> yeah, devmanual said about that pretty clear
+[23:16:04] <mgorny> yet vapier did it
+[23:16:14] <ulm> can't we fix remaining usage in tree, and make it fatal everywhere?
+[23:16:15] <mgorny> so this is about making it fatal in EAPI 6
+[23:16:39] <mgorny> i don't mind extending it to all EAPIs
+[23:16:43] <ulm> it's not related to EAPI 6
+[23:16:51] <WilliamH> one question about this, is this a repoman check? I don't see how a function can know if it was called in global scope.
+[23:18:28] <mgorny> no, portage change
+[23:18:33] <Pinkbyte> WilliamH, i suppose it would be portage and not repoman check
+[23:18:35] <mgorny> the global call will cause 'die'
+[23:18:37] <Pinkbyte> ahh, i was right :-)
+[23:19:17] <ulm> mgorny: one has to make sure that it doesn't die when uninstalling a package
+[23:19:43] <mgorny> ulm: then EAPI 6 ;)
+[23:19:49] <Pinkbyte> retroactive changes are bad, BUT, we will do retroactive change to set up behaviour that was intended by standart and devmanual...
+[23:20:04] <Pinkbyte> ulm, hm, i forgot about this case, thanks for catching this up
+[23:20:11] <ulm> mgorny: so it _does_ die on uninstall?
+[23:20:36] <mgorny> ulm: not sure
+[23:20:37] <wired> Pinkbyte: no problem, I'm at work so 'abstain' is my default answer if not here
+[23:20:48] <mgorny> i don't think portage actaulyly reevals globals on uninstall
+[23:20:48] <Pinkbyte> ulm, it would be hard to check, i think, so probably would be better to not alter behaviour for already installed ebuilds
+[23:21:26] <ulm> mgorny: it should source the environment file from the VDB but not the ebuild (?)
+[23:22:06] <mgorny> yes, i think so
+[23:22:12] <WilliamH> I think it is going to be hard to check inside a function whether it was called from global scope or not.
+[23:22:30] <mgorny> WilliamH: it's already implemented
+[23:22:37] <mgorny> and enabled for Arfrever's EAPIs
+[23:22:48] <mgorny> pretty much we can check whether we're in a phase
+[23:23:12] <WilliamH> mgorny: Oh ok.
+[23:23:26] <ulm> can we shelve this till next meeting please? I don't have enough input to be ready for a vote
+[23:23:59] <WilliamH> That's fine with me.
+[23:24:17] <mgorny> if you feel like it
+[23:24:34] <mgorny> next item important
+[23:24:35] <Pinkbyte> guys, should we? I think if we vote for that change in EAPI 6 it would not hurt anyone. Setting this for all previous EAPIs is another thing...
+[23:24:49] <ulm> or that
+[23:25:10] <ulm> but it won't go into pms
+[23:25:29] <mgorny> it already is in pMS :)
+[23:25:33] <ulm> or rather, it is in pms already, for all eapis :)
+[23:25:48] <Pinkbyte> ulm, huh? i thought it is already for all EAPIs, but we just do not do such check in reality
+[23:25:58] <ulm> Pinkbyte: exactly
+[23:28:14] <Pinkbyte> So, will talk about current EAPIs when we will have clear understanding about all possibly consequences Vote: Making global-scope 'use*', 'has_version' and 'best_version' fatal since EAPI 6
+[23:30:02] * Pinkbyte yes
+[23:30:04] * mgorny yes
+[23:30:12] * ulm yes
+[23:30:29] * Tommy[D] yes
+[23:31:08] * WilliamH yes
+[23:31:20] * uDH ушел (Ping timeout: 256 seconds)
+[23:31:35] * zlogene yes
+[23:32:18] <Pinkbyte> 6 'yes', motion passed
+[23:32:37] <Pinkbyte> Next topic: Use of <maintainer/> and <herd/> elements in metadata.xml
+[23:32:48] <mgorny> yay
+[23:32:54] <mgorny> so my newest idea
+[23:32:59] * WilliamH thinks <herd> should just be switched to <maintainer>
+[23:33:01] <Pinkbyte> a bit ambiguous topic as it recorded
+[23:33:03] <mgorny> 1. replace <herd> with <maintainer>/<email>
+[23:33:12] <mgorny> 2. possibly add maintainer type="foo"
+[23:33:33] <Tommy[D]> i am leaving now, i really need to get some sleep
+[23:33:50] <mgorny> the goal is to make bug assignment simpler
+[23:34:10] <mgorny> we keep maintainer/email useful for bug assignment, add extra information without changing the spec
+[23:34:12] <ulm> I must leave soon, too
+[23:34:29] <WilliamH> mgorny: right now, you 1) assign to first maintainer, 2) cc everyone else.
+[23:34:31] <zlogene> herd != maintainer IMO
+[23:34:52] <zlogene> why should we do so then
+[23:34:57] <WilliamH> zlogene: technically, you are right, a herd is a group of packages...
+[23:35:04] <Pinkbyte> zlogene, basically it is. i mean, herd acts like alias for group of maintainters in terms of bug wrangling
+[23:35:15] <ulm> is this topic even a qa issue?
+[23:35:20] <Pinkbyte> but we should differ herd and herd maintainers of course
+[23:35:28] <ulm> it's something for the -dev ml
+[23:35:29] <WilliamH> herds are dead
+[23:35:50] <zlogene> ulm, the same question here
+[23:35:55] <Pinkbyte> WilliamH, lack of cooperation != dead
+[23:36:04] <Pinkbyte> WilliamH, yes, there is really dead herds
+[23:36:13] <WilliamH> Pinkbyte: relevence == dead
+[23:36:27] <WilliamH> Pinkbyte: the herd concept is pretty useless
+[23:36:30] <mgorny> we can leave herds, just change the tags used to assign bugs
+[23:36:34] <zlogene> Pinkbyte, there are, i'd even said :D
+[23:37:02] <mgorny> i.e. <herd>foo</herd> -> <maintainer type="herd"><email></></>
+[23:37:27] <Pinkbyte> WilliamH, it works for quite a long time as i know. Do you propose to drop the whole idea of collective maintainership?
+[23:38:17] <WilliamH> Pinkbyte: this is part of the problem. Herds are NOT people, they are groups of packages.
+[23:38:34] <WilliamH> Pinkbyte: people maintain herds, they are not in herds.
+[23:38:45] <Pinkbyte> WilliamH, but herd maintainers ARE a group of people. So mgorny change seems reasonable in this case
+[23:39:27] <Pinkbyte> for me it's quite simple. Project maintains some complicated stuff. That stuff are present as one or multiple group of packages(herds). Herds are maintained by respective maintainers
+[23:39:42] <Pinkbyte> first problem - herds without a project
+[23:39:44] <WilliamH> Pinkbyte: but why not just have aliases for the herds e.g. <maintainer><name>group name</name><elail></email></maintainer>
+[23:40:03] <WilliamH> Pinkbyte: it is just another maintainer.
+[23:40:06] <ulm>
+[23:40:19] <ulm> council has shelved this in the last meeting
+[23:40:36] <ulm> so does it make sense if we decide something here now?
+[23:41:09] <mgorny> we could give a recommendation to the council
+[23:41:31] <zlogene> ulm, yes it does, for the future references
+[23:42:27] <Pinkbyte> mgorny, i like your idea about 'type' attribute in maintainer field, but i think we can go just by converting herds to apropriate maintainer tags without additional attribute
+[23:42:45] * WilliamH agrees with Pinkbyte
+[23:42:45] <Pinkbyte> anyway, i saw some packages that has <maintainer></maintainer> and no herd at all
+[23:42:49] <mgorny> there were concerns that we lose information
+[23:43:05] <WilliamH> mgorny: what information? I don't see any information loss.
+[23:43:18] <mgorny> but basically, i'm all for having some other structure mapping e-mail addresses to herds
+[23:43:50] <ulm> we need to distinguish single maintainers from projects
+[23:44:07] <mrueg> how about ?
+[23:44:09] <ulm> or whatever will substitute herds
+[23:44:17] <WilliamH> ulm: does that really matter though?
+[23:44:31] <WilliamH> ulm: you can do that in the <name> tag of a maintainer
+[23:44:51] <Pinkbyte> WilliamH, good catch!
+[23:45:26] <ulm> WilliamH: how to you prevent projects from using the name tag?
+[23:45:40] <ulm> s/to/do/
+[23:46:12] <WilliamH> ulm: you don't. <maintainer><name>foo project</name><email></email></maintainer>
+[23:46:44] <ulm> the dtd says that names are only for individuals, though
+[23:47:09] <ulm> but it has to be changed anyway
+[23:47:38] <Pinkbyte> ulm, could you raise mgorny's idea on next Council meeting? If yes, i think we can skip voting on this entirely, until they spoke their word
+[23:47:55] <ulm> yeah, can do
+[23:48:24] <WilliamH> sounds good to me
+[23:48:35] <Pinkbyte> good. Next one: ncurses[tinfo] flag used to change library ABI, bug #487844
+[23:48:38] <willikins> Pinkbyte: "sys-libs/ncurses: USE=tinfo changes library ABI"; Gentoo Linux, Applications; RESO, WONT; mgorny:base-system
+[23:48:52] <Pinkbyte> i suppose, that's here because of WilliamH
+[23:49:42] <Pinkbyte> my personal opinion - vapier said all things right in the bug. Extra revdep-rebuild ewarn is not needed in this case
+[23:49:43] <ulm> I don't see any breakage there, unless users switch from -tinfo to +tinfo and then back to -tinfo
+[23:50:04] <mgorny> this doesn't go alongwith our work on subslots
+[23:50:09] <Pinkbyte> ulm, in the latter case - there would be preserved rebuild warning
+[23:50:17] <mgorny> we want to know ABI breakages before upgrading
+[23:50:24] <ulm> it's certainly not ideal, but we don't have use dependency operators
+[23:50:30] * WilliamH is against dropping the use flag
+[23:50:40] <mgorny> not allow people to play with them because base-sysetm can't handle deciding
+[23:50:53] <mgorny> i'm for making it use.masked or use.forced
+[23:51:02] <WilliamH> There is no prohibition against using a use flag that way
+[23:51:05] <mgorny> or droppping entirely, and doing the switch via revbump with subslot change
+[23:52:16] <WilliamH> I posted a patch on the bug that could be used to provide a warning to the user if we really want to do that.
+[23:52:45] <WilliamH> We can't force dropping or masking of the use flag.
+[23:53:06] <WilliamH> But there is a way as shown in that patch to test whether it was turned off.
+[23:53:44] <ulm> one could also say that the real issue is with reverse dependencies, that are sniffing if there's a tinfo lib and automagically depend on it
+[23:54:04] <Pinkbyte> mgorny, we can not go on subslot logic in all times of ABI problems happened. revdep-rebuild is supported solution, so i do not see serious QA issue here(yet)
+[23:54:11] * zlogene is out, because has no sleep for 2 days
+[23:54:12] <mgorny> ulm: that's how upstream wants it
+[23:54:16] <mgorny> tinfo is basically the future way
+[23:54:27] <mgorny> normal distros just switch and fix the deps
+[23:54:33] <Pinkbyte> mgorny, but too many breakages happens for now
+[23:54:42] <mgorny> only gentoo makes a lot of noise and doesn't do real work
+[23:55:35] <Pinkbyte> mgorny, you can go in usual way - fix all bugs about USE="tinfo" enabled libncurses consumers and then say - 'hey guys, nobody uses ncurses without libtinfo, let's move on!!!'
+[23:55:41] <ulm> well, add WilliamH's patch then, and warn if the users switches from USE=tinfo to USE=-tinfo
+[23:55:48] <Pinkbyte> mgorny, if you are really THAT care
+[23:55:49] <ulm> that certainly won't harm
+[23:57:51] <WilliamH> I can do it if you want after we are done
+[23:57:55] <WilliamH> ulm: ^^
+[23:58:03] <WilliamH> I can add the patch.
+[23:58:37] <ulm> has vapier commented on it?
+[23:58:42] <WilliamH> no
+[23:59:15] <ulm> WilliamH: hm, you could emit the warning in pkg_preinst
+[23:59:25] <WilliamH> I would need to know the exact revdep-rebuild command users should use though.
+[23:59:27] <ulm> would get rid of the environment saving
+[00:00:04] <WilliamH> ulm: Hmm, what would the test look like if I did that?
+[00:00:15] <mgorny> pkg_pretend maybe/
+[00:00:31] <WilliamH> has_version [tinfo] && ! use tinfo
+[00:01:04] <ulm> WilliamH: I think so
+[00:01:36] <ulm> and revdep-rebuild --library=/path/to/
+[00:03:11] <WilliamH> ulm: I guess that path would end up being ${EROOT}usr/lib/
+[00:03:58] <Pinkbyte> WilliamH, yep
+[00:03:59] <ulm> or $(get_libdir) instead of lib
+[00:04:09] <WilliamH> ulm: right.
+[00:04:12] <Pinkbyte> ah, nice catch too
+[00:04:33] <Pinkbyte> errr, nope
+[00:04:39] <WilliamH> I'll update the bug first.
+[00:04:44] <ulm> no?
+[00:04:44] <Pinkbyte> i have it in /lib64/
+[00:04:56] <Pinkbyte> so i suppose no /usr thingie for libtinfo too
+[00:05:03] <Pinkbyte> but it should be checked, of course
+[00:05:58] <ulm> Matched Files: /usr/lib64/; /usr/lib32/; /usr/lib/
+[00:06:02] <ulm> says e-file
+[00:06:41] <ulm> and it makes sense because terminfo stuff is in /usr/share
+[00:06:49] <Pinkbyte> ulm, agrees too
+[00:07:10] <Pinkbyte> so, i was wrong
+[00:07:12] <ulm> that's the same as e-file, I think
+[00:09:25] <ulm> sorry, but I must leave now
+[00:09:27] <Pinkbyte> ok, guys. I have a bit tired too, so can we skip last part of agenda - status checks about GTK use flag issue, missing QA meetings summary and other stuff. I know that this is important, but as i see - not much of us are left in channel
+[00:09:33] <Pinkbyte> ?
+[00:09:48] <ulm> yeah, please postpone
+[00:10:14] <Pinkbyte> WilliamH, ^^ ok with that?
+[00:10:42] <Pinkbyte> mgorny, wired, ^^
+[00:10:47] <mgorny> sure
+[00:10:53] <WilliamH> That's fine.
+[00:11:01] <wired> sure
+[00:11:08] <WilliamH> So for now should I just update the bug?
+[00:12:20] <Pinkbyte> WilliamH, path that you are supposed(${EROOT}usr/lib/ is correct. Add warning about needed revdep-rebuild for library in that path
+[00:12:30] <Pinkbyte> i think that's all that we can do now
+[00:12:56] <WilliamH> Pinkbyte: ok
+[00:14:17] <Pinkbyte> All right guys, meeting is over. Thanks to everyone
+[00:14:37] <WilliamH> ulm: I think there is a concern about using preinst to emit the warning...
+[00:14:40] <Pinkbyte> Will try to post meeting log and summaries tomorrow. If i do not, just poke me with friendly reminder
diff --git a/meeting-logs/20150218.txt b/meeting-logs/20150218.txt
new file mode 100644
index 0000000..2f14690
--- /dev/null
+++ b/meeting-logs/20150218.txt
@@ -0,0 +1,621 @@
+Timestamps are in UTC+3
+[22:04:05] <Pinkbyte> Let's start then, maybe others will join us later
+[22:04:16] <zlogene> WilliamH, ^
+[22:04:32] <zlogene> I saw he around
+[22:04:49] <Pinkbyte> First of all - the simpliest thing. Give mrueg a warm welcome as our fellow team member. And kudos to zlogene as Deputy Lead
+[22:04:56] * WilliamH is here
+[22:05:02] * wired here
+[22:05:18] <ulm> mrueg: welcome :)
+[22:05:30] <WilliamH> mrueg: Welcome aboard. :-)
+[22:05:44] <mrueg> thanks :-)
+[22:06:19] * mgorny kicked mrueg from #gentoo-qa (welcome)
+[22:06:36] <mgorny> oh wait, is that a wrong practice? :D
+[22:06:40] <Pinkbyte> meh
+[22:06:54] <Pinkbyte> well, it's usual for generic newcomers, so... not sure :-)
+[22:06:54] <WilliamH> heh
+[22:07:01] <wired> too late :P
+[22:07:11] <mgorny> he's a dev long enough to have autorejoin
+[22:07:13] * mrueg (~mrueg@gentoo/developer/mrueg) joined #gentoo-qa
+[22:07:48] <Zero_Chaos> mrueg: welcome
+[22:08:11] <mrueg> :)
+[22:09:23] <Pinkbyte> so, i will take care about our logs, but it would be nice to have a backup. zlogene, could you please enable logging in your client too, just in case?
+[22:09:45] <zlogene> Pinkbyte, sure
+[22:12:21] <Pinkbyte> So, let's begin our business
+[22:12:43] <Pinkbyte> games policies... again. Or should i say - at last? :-)
+[22:13:24] <Pinkbyte> bug #537580...
+[22:13:27] <willikins> Pinkbyte: "Allow packages to install files in games directories without chgrp games"; Gentoo Linux, Games; CONF; ulm:qa
+[22:13:54] <ulm> I've outlined the problems and proposed a solution in comment #0
+[22:14:16] <Pinkbyte> i do not want to be rude, but i am kinda tired about hasufell's nagging, who are not willing to put any reasonable amount of real work in this issue, but continues saying that all proposed stuff are useless
+[22:14:49] <mgorny> i like ulm's solution
+[22:15:00] <ulm> basically, devs still cannot install any games in FHS locations, because games.eclass sets the dirs' permissions to 750
+[22:15:01] <mgorny> Pinkbyte: hasufell is a true troll, we could ban him and he wouldn't care much
+[22:15:09] <mgorny> as in, he does that on purpose
+[22:15:23] <mgorny> but it's comrel, not qa business :)
+[22:15:52] <zlogene> i'd vote for ulm's solution
+[22:15:54] <ulm> so my first suggestion would be to change all top-level games dirs to root:root and 755 (i.e. the default)
+[22:16:02] <Pinkbyte> mgorny, true. I am just saying about my personal attitude. Now, technically...
+[22:16:11] <ulm> patch for games.eclass is attached to the bug
+[22:16:16] <Pinkbyte> ulm, let me clarify - do you propose to change games.eclass?
+[22:16:18] <mgorny> ulm: that is equal to /usr/bin and others, correct?
+[22:16:39] <Pinkbyte> ulm, sorry, did not see your attachment in bug, ignore last question
+[22:16:43] <ulm> Pinkbyte: yes, just the part that restricts the dirs listed in comment #0
+[22:17:13] <ulm> e.g. /usr/games and /var/games should be world readable
+[22:17:30] <Pinkbyte> ulm, no objections from me
+[22:17:36] * WilliamH is reading
+[22:17:41] <ulm> any more restrictive permissions can be applied to files or subdirs
+[22:18:18] <ulm> second part is a new group for shared scores/bones/states
+[22:18:45] <ulm> the "games" group cannot be used for that, unfortunately
+[22:18:54] <ulm> so we would need a new name
+[22:19:16] <ulm> like "scores"
+[22:19:36] <Pinkbyte> ulm, 'gamescores'(or scores) seems more valid for me, rather than proposed name 'gamers' in maillist
+[22:19:51] <mgorny> i'd go for scores
+[22:19:54] <mgorny> simple and efficient
+[22:19:56] <ulm> or "spiele", "jeux", "juegos", "ludi", "gry"
+[22:19:59] <mrueg> gamescores
+[22:20:18] <mgorny> Pinkbyte, mrueg: this makes me think about 'cores'
+[22:20:26] <ulm> mrueg: yeah, but it's too long
+[22:20:45] <mrueg> or maybe game-stats
+[22:20:49] <ulm> shouldn't be more than 8 chars otherwise some programs cannot display it
+[22:20:58] <mrueg> gamestat ;)
+[22:21:00] <ulm> and no hyphen ;)
+[22:21:15] <zlogene> gscores? ;D
+[22:21:19] <Pinkbyte> ulm, lol, a bit off-topic: your last sentence reminds me about some russian user, that was really curious about why locale defined in make.conf as LINGUAS and not LANGS for example :-)
+[22:22:03] * WilliamH isunsure what the games group is supposed to be used for
+[22:22:22] <zlogene> Pinkbyte, lingua latina non ... you know
+[22:22:26] <ulm> WilliamH: games would be setgid "scores" (or whatever its name will be)
+[22:22:41] <ulm> so they can access shared score files on the system
+[22:23:03] <WilliamH> ulm: My question though was, why not setgid games?
+[22:23:09] <Pinkbyte> WilliamH, 'games' can not be thrown away because of backward compatibility. And can not be utilized by regular users because of security bug #125902
+[22:23:13] <willikins> Pinkbyte: "games-roguelike/nethack: local privilege escalation and insecure savegame creation (CVE-2006-1390)"; Gentoo Security, Vulnerabilities; IN_P; taviso:security
+[22:23:48] <ulm> WilliamH: many gentoo users will be in the games group, so there will be a security issue if we have setgid binaries at the same time
+[22:23:59] <mgorny> WilliamH: long story short, because that group needs to be empty ;)
+[22:24:01] <Pinkbyte> WilliamH, if regular user can overwrite score files in default configuration by another app, not related to reading/writing them(like text editor) it creates some nasty security holes
+[22:24:32] <WilliamH> So users shouldn't have been put in the games group to begin with.
+[22:24:54] <ulm> WilliamH: right, but too late to change that now
+[22:24:56] <Pinkbyte> WilliamH, yes, but we can not say them - go away from games group until we throw away games.eclass entirely
+[22:25:13] <Pinkbyte> WilliamH, it will not happen in any near future, it will require some work to do
+[22:25:39] <WilliamH> Pinkbyte: ok, thanks. :-)
+[22:25:51] <Pinkbyte> and that bitrotting security issue pains me from the time i join Gentoo Security, i am glad that it was brought to our attention(at last!)
+[22:26:03] <ulm> so, gscores, gamestat, or should I go to the -dev ml for bikeshedding?
+[22:26:06] <ulm> or launch a forums poll? :)
+[22:26:36] <WilliamH> gamestat ++
+[22:26:37] <Zero_Chaos> whatever you want man, I think this is not so important we need a vote
+[22:26:40] <Zero_Chaos> gamestat, fine
+[22:26:42] <Pinkbyte> ulm, i like 'gamestat'
+[22:27:00] <ulm> ok, gamestat it will be
+[22:27:17] <ulm> can we have a vote on the whole proposal
+[22:27:19] <ulm> ?
+[22:27:45] <ulm> as outlined in bug 537580 comment #0
+[22:27:47] <willikins> "Allow packages to install files in games directories without chgrp games"; Gentoo Linux, Games; CONF; ulm:qa
+[22:27:51] <ulm> (first two items)
+[22:28:16] <Pinkbyte> Let's clarify: "Create separate group: 'gamestat' and set score files to it, /usr/games and /var/games should be world-readable"
+[22:28:32] <ulm> well, all dirs listed in the bug
+[22:28:57] <ulm> /usr/games /usr/games/bin /usr/games/lib* /usr/share/games /var/games /etc/games /opt
+[22:29:32] <ulm> /opt was already fixed, though
+[22:30:50] <ulm> and these dirs' permissions and owner should just be left alone
+[22:30:56] <ulm> root:root and 755
+[22:31:21] <ulm> like /usr/bin and all others
+[22:31:32] * WilliamH yes
+[22:31:36] * Pinkbyte yes
+[22:31:38] * mgorny yes
+[22:31:39] * ulm yes
+[22:31:53] * zlogene yes
+[22:31:56] <Zero_Chaos> yes
+[22:32:35] <Pinkbyte> mrueg, ?
+[22:32:42] <mrueg> yes.
+[22:32:59] <ulm> thank you :)
+[22:33:08] <Pinkbyte> motion passed
+[22:33:25] * wired yes
+[22:33:50] <Pinkbyte> ...unanimously
+[22:33:51] <Pinkbyte> :-)
+[22:34:18] <Pinkbyte> so, next question... "Developers ignoring (not updating) eclass/ChangeLog file"
+[22:34:46] <zlogene> Pinkbyte, what do you mean by this item ?
+[22:34:46] * WilliamH doesn't have a strong opinion since once we go to git it will be irrelivent.
+[22:34:51] <mgorny> we should get a consistent policy here
+[22:34:51] <Pinkbyte> Who brought this up?
+[22:34:56] * mgorny did
+[22:35:04] <mgorny> long story short, some devs update eclass/ChangeLog, some don't
+[22:35:08] <Zero_Chaos> Changelogs should be updated
+[22:35:11] <Pinkbyte> zlogene, i am just reading what is in our agenda, not all of those items are brought there by me
+[22:35:13] <mrueg> repoman should work on profiles/ and eclass/
+[22:35:13] <mgorny> the result is you can't read the file reliably
+[22:35:23] <mrueg> right now it doesn't
+[22:35:44] <zlogene> mrueg, repoman is for qa checks
+[22:35:46] <Pinkbyte> mrueg, the problem is that not every directory in profiles/ has ChangeLog
+[22:36:01] <zlogene> echangelog can deal with profiles and eclass
+[22:36:04] <mgorny> Pinkbyte: that's not really a problem, it's a bit irritating
+[22:36:09] <Pinkbyte> some deep arch profiles have only top level ChangeLog(and it's fine if it is consistent)
+[22:36:20] <ulm> as long as we have a ChangeLog in eclass it should be updated
+[22:36:30] <mrueg> zlogene: repoman ci -m "Foo" calls echangelog, except for eclass or profile.
+[22:36:31] <Pinkbyte> mgorny, i mean that this is problem for a automatic tool to check, such as repoman
+[22:36:49] <mgorny> the problem is that it's not devs forgetting, i think
+[22:36:54] <zlogene> mrueg, i know
+[22:37:01] <mgorny> they openly refuse to update the ChangeLog
+[22:37:24] <mgorny> so we should decide if refusing this is a reason for QA action
+[22:37:26] <WilliamH> mgorny: Yes, there is some of that going on too.
+[22:37:35] <mgorny> or we should just drop the ChangeLog since it confuses people
+[22:37:39] <WilliamH> mgorny: But I've also seen situations where
+[22:37:52] <mrueg> well don't we try to enforce the usage of repoman to commit stuff to the tree?
+[22:37:53] <WilliamH> mgorny: repoman ci -m 'msg' doesn't work.
+[22:38:28] <WilliamH> mgorny: I can't figure out when it doesn't work.
+[22:38:42] <Zero_Chaos> for all I care we can drop the Changelog files entirely and rely on cvs log for eclasses, but it should be consistent
+[22:38:57] <Pinkbyte> mgorny, well, before we will have git we should preserve as much ChangeLogs as possible
+[22:39:31] * WilliamH agrees with Zero_Chaos about consistency
+[22:39:51] <mrueg> bug #390651
+[22:39:53] <willikins> mrueg: "repoman: support commit in non-package directories like eclasses and profiles"; Portage Development, Repoman; CONF; zmedico:dev-portage
+[22:39:58] <Pinkbyte> we could rely on CVS commit messages, but they are not for end-users as i would said. 'git log' is a more user-friendly
+[22:40:21] <Zero_Chaos> Pinkbyte: git log and cvs log are effectively the same thing. you just have to |less on your own for cvs
+[22:40:50] <wired> this changelog problem has been around forever, I don't see it going away until we switch to git
+[22:40:55] <mgorny> i'd suggest two possible decisions:
+[22:41:04] <zlogene> mgorny, phrase "we will have a git" correlates to HL3 release
+[22:41:26] <mgorny> a. we declare that if a particular subtree or a parent tree has a ChangeLog, developer must update it when committing to it
+[22:41:37] <Pinkbyte> zlogene, be more optimistic. At least mgorny do a real work for this, writing nice kind-of-migration software
+[22:41:49] <mgorny> b. we drop eclass/ChangeLog and possible others ChangeLogs used inconsistently
+[22:41:59] <ulm> I believe that a. is existing policy already
+[22:42:12] <Pinkbyte> mgorny, "a" plan is fine by me
+[22:42:20] <Pinkbyte> ulm, not sure
+[22:42:24] <WilliamH> "a" allows "b" even.
+[22:42:39] <WilliamH> Because if the changelog is gone you don't have to worry about it.
+[22:43:00] <zlogene> maybe developers confused since they don't know what changelog they should update?
+[22:43:02] <mgorny> ulm: if it is, then we should confirm it
+[22:43:13] <Pinkbyte> ulm, i was wrong -
+[22:43:15] <zlogene> in subprofiles case
+[22:43:16] <mgorny> zlogene: no, i'm talking about eclass/, there's only one ;P
+[22:43:21] <Pinkbyte> "Note: If a ChangeLog file is not present in your current working directory, then you should write a ChangeLog entry in the parent's directory ChangeLog file. "
+[22:43:24] <zlogene> ah
+[22:43:43] <Pinkbyte> so, it IS a policy, from devmanual
+[22:44:50] <Pinkbyte> and i do not think that we need to change it in current situation. It's in pure "a" variant, suggested by mgorny
+[22:45:28] * mgorny prepares a gentoo-dev@ mail then :)
+[22:45:47] <ulm> we could confirm the policy again
+[22:46:09] <Zero_Chaos> I say we officially confirm the policy
+[22:46:12] <mrueg> maybe ping portage-devs to add support to repoman for these profiles?
+[22:46:25] <mrueg> s/profiles/Changelog generation/
+[22:46:35] <mgorny> mrueg: not sure if you can do that reliably
+[22:46:50] <mgorny> it would have to somehow distinguish between 'update parent changelog' and 'create new changelog here'
+[22:46:56] <WilliamH> mrueg: I'm not sure how much work we should ask the portage devs to do, because
+[22:47:10] <WilliamH> mrueg: once we change to git, the ChangeLog files will be gone
+[22:47:27] <Pinkbyte> mgorny, dol-sen is quite responsive and not so busy as zmedico(which is responsive too). And that's not so hard work to do
+[22:47:29] <mrueg> mgorny: well at least for eclass it should be easy?
+[22:47:47] <WilliamH> mrueg: per council decision
+[22:47:48] <mgorny> yes
+[22:48:01] <Pinkbyte> WilliamH, if we will pospone fixing this until git migration is done it will be there -> not good
+[22:48:48] <WilliamH> Pinkbyte: I'm just saying that any fix we do should be a fix that won't break again once the git migration happens.
+[22:49:07] <WilliamH> Pinkbyte: and the ChangeLog disappears
+[22:49:08] <Pinkbyte> WilliamH, repoman does not write to changelog in git repos, IIRC
+[22:49:11] <mgorny> can we vote on confirming this policy then? if we remove all the ChangeLogs with git, the rule would still be fine
+[22:49:15] <Zero_Chaos> git migration will change things, it is what it is.
+[22:49:27] <mrueg> ack mgorny
+[22:49:34] <Zero_Chaos> ack mgorny
+[22:49:42] * ulm votes yes for confirming the policy
+[22:49:57] * WilliamH yes
+[22:49:58] <Pinkbyte> And yes, let's not mix things up. We are with cvs now - so, let's keep things clear and tidy NOW
+[22:49:58] <mrueg> (which means vote yes)
+[22:49:59] <Zero_Chaos> yes
+[22:50:04] * Pinkbyte yes
+[22:50:12] * zlogene yes
+[22:50:21] * mgorny yes
+[22:50:27] <Zero_Chaos> so we all seem to agree, what do we do about violators? revert their changes?
+[22:50:49] <Zero_Chaos> publicly insult their mothers?
+[22:50:54] <ulm> that would be an overreaction :)
+[22:50:59] <ulm> both :)
+[22:51:20] <Zero_Chaos> flaming bags of dog poop on their porch?
+[22:51:24] <Pinkbyte> Zero_Chaos, send apropriate message in gentoo-dev, blaming author and asking to update changelog itself
+[22:51:38] <Zero_Chaos> we can't have a policy we don't enforce, so we need to have a policy for enforcement.
+[22:51:49] <Zero_Chaos> I'm fine with emailing the dev directly and cc gentoo-dev
+[22:51:50] <Pinkbyte> Zero_Chaos, you are really inventor these days, are not you? :-)
+[22:51:54] <Zero_Chaos> but not all devs read gentoo-dev alone
+[22:52:03] * WilliamH agrees with Pinkbyte
+[22:52:16] <WilliamH> That would be a response to a msg on gentoo-commits probably
+[22:52:21] <zlogene> Zero_Chaos, do we have any other method?
+[22:52:24] <Pinkbyte> Zero_Chaos, sure, direct mails WITH CC-ing gentoo-dev@ is fine too
+[22:52:28] <zlogene> g-dev only
+[22:52:37] <mrueg> + CC qa@
+[22:52:47] <zlogene> yeah
+[22:52:52] <Zero_Chaos> zlogene: if we don't email the dev directly, they might not see it. I'm a few thousand behind on gentoo-dev
+[22:52:52] <mgorny> i'd say gentoo-dev + 24h timeout
+[22:52:58] <mgorny> if developer doesn't update the ChangeLog, we revert
+[22:53:26] <Pinkbyte> WilliamH, i am not receiving all mail from gentoo-commits and it's not trivial to receive a specific e-mail from mailman archive too, so, it depends...
+[22:53:26] <mgorny> and a regular QA action on repeated offenses
+[22:53:30] <WilliamH> g-dev alone isn't good enough though because g-dev is not mandatory for devs.
+[22:53:38] <mrueg> mgorny: we need a lcvs-qa-revert tool ;p
+[22:53:45] <ulm> mgorny: revert because of missing changelog entry? what if it's an important fix?
+[22:54:05] <Zero_Chaos> I think email warnings and we don't bind our hands if we have a repeat offender
+[22:54:20] <WilliamH> Yeah, we would have to use common sense; we can't just revert depending on the fix.
+[22:54:38] <mgorny> maybe
+[22:54:38] <zlogene> ulm, i'd say write a message before rever (directly to dev maybe)
+[22:54:45] <zlogene> *revert
+[22:55:00] <mgorny> but not reverting means the ChangeLog will again be inconsistent
+[22:55:03] <Pinkbyte> ulm, agreed, retroactively add ChangeLog entry is better than losing a critical fix. But it should not be a usual practice like 'ah, those guys will update changelog themselves"
+[22:55:08] <wired> wait. revert changes because of changelog?
+[22:55:29] <zlogene> may be we should make a template for it?
+[22:55:38] <Zero_Chaos> I don't think we need to officially state we will revert changes. i think we can leave ourselves free to act as appropriate
+[22:55:44] <mrueg> mgorny: if we revert it, we need to fix the changelog anyway right?
+[22:55:49] <wired> please don't, it may be a policy violation, but the commit may be more important than the policy violation.
+[22:55:59] <Pinkbyte> wired, ++
+[22:56:02] <mrueg> aka echangelog "Foo"; echangelog "Revert foo"
+[22:56:08] * WilliamH is against specifying how we will react
+[22:56:32] <WilliamH> That should be a case by case kind of thing.
+[22:56:41] <mgorny> mrueg: well, if you revert something that wasn't there, you don't say you did :)
+[22:56:50] <wired> the only real solution is to enforce this server side. until then, we have to point fingers and accept that some people will not follow rules unless they are enforced
+[22:57:43] <Pinkbyte> wired, and again - ++ from my side
+[22:58:14] <Pinkbyte> apropriate git hooks will screw such retarded behaviour and force dev's commits to be nice and shiny
+[22:58:22] <wired> ^^
+[22:58:23] <mrueg> mgorny: so you even don't echangelog "Revert foo"?
+[22:58:23] <Pinkbyte> **devs'
+[22:58:25] <WilliamH> Folks, you cannot just blindly revert an update because of a ChangeLog entry missing.
+[22:58:43] <mgorny> mrueg: yes
+[22:58:44] <Zero_Chaos> we cannot blindly revert fixes, period.
+[22:58:47] <ulm> WilliamH: ++
+[22:58:57] <wired> and we're spending way too much time on this, it's not an important policy altogether
+[22:58:58] <mgorny> how about reverting unreviewed eclass changes?
+[22:59:10] <Zero_Chaos> so let's vote that we email the developer, cc -dev, and deal with anyone who refuses as appropriate
+[22:59:22] <WilliamH> mgorny: again, no.
+[22:59:24] <Pinkbyte> so, let's recap: "Remind all about our policy on ChangeLog files"
+[22:59:26] <ulm> mgorny: not all eclasses require a review
+[22:59:38] <ulm> e.g. toolchain.eclass doesn't
+[22:59:40] <Pinkbyte> mgorny, i am understanding where this goes. That's ANOTHER issue
+[22:59:49] <Pinkbyte> ulm, hm. Why?
+[23:00:00] <ulm> Pinkbyte: the devmanual says so
+[23:00:13] <wired> mgorny: that's a different issue altogether, I'd like to see us use a review tool and enforce at least one peer review, starting with eclasses, but that's something for another day :P
+[23:00:15] <ulm> and explicitly mentions toolchain as example
+[23:00:52] * WilliamH is with Pinkbyte remind everyone about our policy
+[23:01:14] <Pinkbyte> ulm, you were right, again
+[23:01:21] <WilliamH> Then handle violaters on a case by case basis
+[23:01:28] <Pinkbyte> "It is not usually necessary to email the gentoo-dev list before making changes to a non-general eclass which you maintain. Use common sense here."
+[23:01:29] <WilliamH> just like any other violation
+[23:01:39] <Pinkbyte> !herd toolchain
+[23:01:41] <willikins> Pinkbyte: (toolchain) halcy0n, kumba, lu_zero, rhill, vapier
+[23:02:11] <Pinkbyte> vapier is there, so it's his right to do so and accept all consequences of breakages
+[23:02:50] <mgorny> but while at it, do we consider it ok to revert if the commit actually causes breakage, and request fixing it first?
+[23:03:21] <Pinkbyte> mgorny, yes, but WITH notifying those who break it about breakage
+[23:03:22] <wired> I would revert if the commit wrecked havoc
+[23:03:49] <wired> and ping the proper people to fix it
+[23:04:00] <Pinkbyte> mgorny, even after reverting, does not matter. Our own policy requires that for serious breakages - to send notice to the actual maintainer that things was bad and WE fixed it
+[23:04:02] <wired> we really need a review tool ^_^
+[23:04:50] <ulm> should go without saying that the maintainer will be notified
+[23:05:33] <Pinkbyte> ulm, by sending notice i mean e-mail, that does not require it's ACK
+[23:05:40] <Pinkbyte> just a reminder
+[23:05:50] <Pinkbyte> that things reverted on purpose
+[23:06:08] <mgorny> ok, i guess we can move forward with the agenda
+[23:07:04] <Pinkbyte> yep, we voted for the initial agenda proposal, motion passed
+[23:07:19] <Pinkbyte> "Missing QA meetings summaries"
+[23:07:38] <Pinkbyte> Not sure what i personally can do here. Probably nothing, unless somebody has missing logs
+[23:09:00] <Zero_Chaos> which ones are missing?
+[23:09:37] * zlogene has no logs
+[23:09:44] * WilliamH has no logs
+[23:10:26] <Pinkbyte> Zero_Chaos, oh, stupid me, i thought that logs are missing too!
+[23:10:36] <Zero_Chaos> I also have no logs
+[23:10:41] <Pinkbyte> so, we just need to provide a convinient summary for them
+[23:10:45] <ulm> we can ask robbat2
+[23:10:55] <ulm> willikins is logging IIRC
+[23:11:01] <Pinkbyte> no need - we have all meeting logs on our wiki page
+[23:11:29] <Pinkbyte> just lacks some summaries for March 19, 2014 and March 26, 2014 meetings
+[23:11:51] <Pinkbyte> i will take care of that and post apropriate summaries
+[23:11:58] <Zero_Chaos> Pinkbyte: thanks
+[23:13:31] <Pinkbyte> "GTK use flag" status check
+[23:13:55] <Pinkbyte> Who wants to discuss this? Your word.
+[23:14:03] <floppym> If anyone ever needs logs, feel free to ask me for any channel I am in.
+[23:14:12] <floppym> quassel logs everything.
+[23:15:19] <zlogene> gtk use flags? again?
+[23:15:50] <mrueg> Pinkbyte: has the status changed?
+[23:16:00] <WilliamH> heh, I sent an email to the gnome team sometime back but we never got an answer.
+[23:16:01] <mrueg> if not: unchanged. ;)
+[23:16:29] <WilliamH> So I would say the status is unchanged.
+[23:16:49] <ulm> so how do we proceed?
+[23:17:01] <Zero_Chaos> kill everyone in the gnome team!
+[23:17:02] <ulm> we cannot wait for the gnome team forever
+[23:17:23] <Zero_Chaos> that or just do it, assuming someone cares enough to do the work
+[23:17:23] <ulm> Zero_Chaos: you have crative suggestions today :)
+[23:17:28] <ulm> *creative
+[23:17:40] <zlogene> Zero_Chaos, do you have a pistol for this purpose?
+[23:17:41] <Zero_Chaos> ulm: I'm working on something I find enjoyable, it helps my mood a lot.
+[23:17:47] <Zero_Chaos> zlogene: several
+[23:17:52] * WilliamH doesn't know enough about the build system, or gtk in general to comment.
+[23:18:01] <Pinkbyte> well, i remember WilliamH's e-mail. I propose to send it again. And then - if no answer will be till the next meeting - move that to Council. There is nothing we can do when we are ignored
+[23:18:04] <WilliamH> e.g. does upstream support gtk slotting?
+[23:18:36] <Pinkbyte> WilliamH, not really matters in case of regular apps, that usually build with only ONE of GTK versions, but can not be built with both
+[23:18:48] <Pinkbyte> i mean - simultaneously build with both
+[23:19:04] <creffett> ahh, my favorite QA issue.
+[23:19:05] * creffett here
+[23:19:11] <Pinkbyte> creffett, o/
+[23:19:34] <zlogene> creffett, \o
+[23:19:41] * WilliamH would have to go back and dig up the email.
+[23:19:55] <Zero_Chaos> creffett: \o/
+[23:20:43] <creffett> WilliamH: does it matter? they've been asked several times and ignored the requests
+[23:21:32] <WilliamH> creffett: good point.
+[23:22:14] <mgorny> is this crusade worth fighting?
+[23:22:22] <Pinkbyte> ulm, are you ok with moving that up to Council?
+[23:22:30] <Zero_Chaos> if none of us is willing to make the commits, then we should drop this
+[23:22:34] <Pinkbyte> mgorny, consistency and following policies? Yeah, why not ;-)
+[23:22:37] <Zero_Chaos> that's the only way it will ever get done
+[23:22:41] <ulm> Pinkbyte: fine with me
+[23:23:50] <Pinkbyte> Zero_Chaos, i can dig with this, if i will have strong backup on my shoulders. Saying "I am QA team lead and we decided this should be THAT way" is not enough here
+[23:24:17] <Zero_Chaos> Pinkbyte: it really is. You will only ever have the power you assume. If you assume you are weak, then you are.
+[23:25:04] <WilliamH> Pinkbyte: qa has a lot of tree-wide authority. It is up to us to figure out how to use it.
+[23:26:10] <WilliamH> Pinkbyte: the only way someone can override qa is by going to the council.
+[23:26:29] <Pinkbyte> No doubt it is. But ulm already agrees to bring that to Council, so we would not blamed to over-use our powers. In any case, this is consistency issue, and it is serious. But nothing is broken badly on users systems
+[23:26:44] <Zero_Chaos> We have no authority if we choose not to exercise authority. We have authority to do this, if we choose to.
+[23:27:10] <Zero_Chaos> but again, this will never happen if we don't do the work
+[23:27:55] <WilliamH> It is a consistency issue that I personally think we should follow through on.
+[23:28:04] <ulm> Pinkbyte: alternatively to forwarding this to the council, you could post the qa decision on gtk and gtk3 flags to the -dev ml
+[23:28:09] <Zero_Chaos> is that a volunteer I hear?
+[23:28:13] <WilliamH> I"m not really ina position where I can do the commits personally since I don't use a gui
+[23:28:45] <ulm> Pinkbyte: assuming that we have a decision. do we?
+[23:28:51] <WilliamH> ulm: that will end up in endless arguments again
+[23:29:17] <Pinkbyte> WilliamH, we have answer from eva@, but it's only about 'keeping us in touch' with changes he planned to do
+[23:29:22] <Pinkbyte> ulm, yes
+[23:29:25] <WilliamH> ulm: I thought we did have a decision... but I don't remember now.
+[23:29:29] <ulm> WilliamH: if it's a policy it has to be made public
+[23:29:42] <ulm> makes no sense, otherwise
+[23:30:32] <ulm> we had a discussion with the conclusion that we want gtk=GTK2 and gtk3=GTK3
+[23:30:45] <ulm> but I don't remember if we had a formal vote on it
+[23:31:22] <Pinkbyte> ulm,
+[23:31:23] <Pinkbyte> we do
+[23:32:10] <WilliamH> The email I sent was to ask the gnome team for more information about why they are doing things differently, but they never answered.
+[23:32:51] <ulm> heh, that was a full year ago
+[23:33:17] <Pinkbyte> WilliamH, as i said eva@ is answered, but his anwer does not contain any information about the problem itself and the concrete things to fix that
+[23:34:36] <WilliamH> ulm: So basically we made the decision and tried to dialog with the gnome team but they gave us nothing.
+[23:34:42] <leio> He went on and did actual QA work. Found that many related USE flags are completely wrongly used, and from there I am amazed the QA team is doing some stuff like that, when there are much bigger fish to fry than decide that USE flags are for declaring external dependencies instead of FEATURES.
+[23:35:12] <leio> The half-done work was linked to you from a spreadsheet by me, I have not heard of anything since on what to do about all those.
+[23:35:14] <creffett> leio: everyone has their idea of what QA should be doing
+[23:35:31] <creffett> and none of those ideas agree with any other person's idea
+[23:35:42] <leio> well, considering half of those USE=gtk's shouldn't be a USE=gtk at all...
+[23:36:16] <leio> anyways, I realized this is a meeting,
+[23:36:17] * leio shuts up
+[23:36:40] <mgorny> don't worry, it's boring anyway :P
+[23:36:57] <WilliamH> leio: Should they be hard deps instead of use=gtk?
+[23:37:15] <Pinkbyte> leio, you are free to attend the meeting and say your opinion about problem, do not worry about that
+[23:37:47] <Pinkbyte> leio, and beeing in GNOME team makes your opinion even more valuable :-)
+[23:37:48] <leio> I do not have the time to read through the meeting log right now. Need to fix problems in the xorg/gtk/wayland/gles2 area.
+[23:38:28] <leio> But you are welcome to engage the GNOME team in the #gentoo-desktop channel. We hate e-mail.
+[23:41:06] <Pinkbyte> So, who will be in charge of that conversation with GNOME team? I am all for making it as clear as it's possible, without enforcing rules, that are not apropriate because of some stupid misunderstanding
+[23:43:19] <Pinkbyte> guys?
+[23:44:02] <Pinkbyte> WilliamH, ^^
+[23:45:00] <ulm> I don't know, but if we had a valid policy, then I would just fix my few packages with IUSE=gtk
+[23:45:28] <ulm> but I've postponed it because I feel that things are still in a pending state
+[23:46:01] <Pinkbyte> ok, seems nobody wants to do this. I will take care about talking to GNOME team myself then.
+[23:46:04] <WilliamH> ulm: I thought we had a valid policy...
+[23:46:06] <Pinkbyte> and yes, we HAVE policy
+[23:46:11] <Pinkbyte> but nobody enforces it
+[23:46:11] <ulm> so e.g. emacs neither follows gnome nor qa policy
+[23:46:37] <ulm> ok, so I will change flag usage there
+[23:47:52] <wired> gotta run
+[23:48:01] <wired> l8r :)
+[23:48:08] <WilliamH> Pinkbyte: I don't know that I'm really qualified to do much since I don't use gnome myself.
+[23:48:36] <Pinkbyte> WilliamH, sure, no problem. You are not the only QA team member :-/
+[23:49:09] <Pinkbyte> So, postponed until beeing discussed with GNOME team. "Status check: Followup on decisions of past QA and Council meeting"
+[23:49:18] <Pinkbyte> not sure what's this about
+[23:50:25] <Pinkbyte> !expn qa
+[23:50:26] <willikins> Pinkbyte: qa = creffett,patrick,pinkbyte,tommy,ulm,williamh,wired,zerochaos,zlogene,mgorny,mrueg,
+[23:50:39] * mgorny has no clue
+[23:50:40] <Pinkbyte> Guys, can we have some attention here, please? We are close to end the meeting
+[23:50:57] * WilliamH isn't sure either
+[23:51:01] <Zero_Chaos> I'm still here, just not sure I have anything to contribute
+[23:51:30] <ulm> not sure, who has put this topic on the agenda? :)
+[23:51:31] * zlogene too
+[23:52:18] <Pinkbyte> ulm, you!
+[23:52:24] <ulm> oops
+[23:52:39] <ulm> yeah, copied from previous meeting's agenda
+[23:52:44] <Pinkbyte> logs does not lie, muahahaha :-P
+[23:53:17] <ulm> well, next topic please :)
+[23:53:21] <Pinkbyte> ok then
+[23:53:43] <Pinkbyte> "open bugs with QA involvement"
+[23:53:53] <ulm>
+[23:53:58] <ulm> 210 open bugs
+[23:54:05] <Zero_Chaos> lol, ouch
+[23:54:50] <Pinkbyte> well, i do not think we should discuss all of them now :-)
+[23:55:03] <Pinkbyte> we have life, you know
+[23:55:46] <mgorny> who? ;o
+[23:55:53] <Pinkbyte> anything concrete about open bugs?
+[23:55:57] <dilfridge> life?
+[23:56:17] <ulm> mgorny: can I close bug 539982?
+[23:56:22] <willikins> ulm: "Unused licenses: CC-BY-ND-2.5, DSL, ECL-2.0, ODbL-1.0, intel-psb, mongrel, newton, urbanterror-4.1-maps"; Gentoo Linux, Unspecified; CONF; mgorny:licenses
+[23:56:33] <mgorny> sure, your choice
+[23:56:38] <ulm> k
+[23:56:56] <hedge256> Damn I forgot all about the meeting :(
+[23:57:33] <WilliamH> Zero_Chaos: can I close bug 537996?
+[23:57:36] <willikins> WilliamH: ">=sys-apps/openrc-0.13 netmount script cannot properly mount nfs shares"; Gentoo Hosted Projects, OpenRC; CONF; zerochaos:openrc
+[23:57:49] <Zero_Chaos> WilliamH: not until it works, no
+[23:58:01] <Zero_Chaos> WilliamH: but you could ask the team to vote on it.
+[23:58:04] <Pinkbyte> Zero_Chaos, what's the problem there?
+[23:58:13] <WilliamH> Zero_Chaos: it does according to qa, and a new release was spun with "use" in the dependencies as requested.
+[23:58:17] <Zero_Chaos> Pinkbyte: /etc/init.d/netmount cannot start nfs mounts
+[23:58:33] <Zero_Chaos> Pinkbyte: you have to start another service first, but openrc currently lacks the ability to do it right.
+[23:58:41] <Pinkbyte> Zero_Chaos, i clearly states how it should be done, did not i?
+[23:58:48] <WilliamH> Pinkbyte: it is a config issue. he wants it to start them without having to type rc-update add nfsclient default
+[23:59:06] <Pinkbyte> WilliamH, i remember that i answered clearly on that bug, did not i?
+[23:59:14] <Zero_Chaos> netmount is also not in the default runlevle
+[23:59:22] <WilliamH> Pinkbyte: Yes, you did, and I followed your suggestion.
+[23:59:35] <Pinkbyte> Zero_Chaos, and it is correct not beeing in default runlevel
+[23:59:38] <WilliamH> Zero_Chaos: that's on you; you removed it.
+[23:59:59] <Zero_Chaos> WilliamH: your init script is missing deps. that's not my fault.
+[00:00:14] <Zero_Chaos> WilliamH: you know how I feel about this, why constantly ask if I reconsidered?
+[00:00:15] <Pinkbyte> Zero_Chaos, not everybody uses NFS. And who did - they can follow proper procedure to configure it, including adding nfsclient to runlevel
+[00:00:28] <Zero_Chaos> WilliamH: I though we agreed to add 'want' or similar to openrc?
+[00:00:49] <WilliamH> Zero_Chaos: there is a separate bug for that, like I already told you.
+[00:00:54] <Pinkbyte> Zero_Chaos, it can not be the 'need dep', only 'use' and it's already done. But this does not fix your situation, unless you will reconsider some configuration things
+[00:01:30] <Zero_Chaos> Pinkbyte: /etc/init.d/netmount cannot possibly mount nfs shares without taking addition actions. that's a bug.
+[00:01:45] <WilliamH> Zero_Chaos: but that isn't a blocker for this issue. Like I said, netmount is in the default runlevel for all installs unless you remove it.
+[00:01:46] <Pinkbyte> Zero_Chaos, why?
+[00:02:06] <Zero_Chaos> Pinkbyte: that's like saying "sure my ebuild works, you just have to emerge something else first.
+[00:02:09] <Pinkbyte> Zero_Chaos, netmount can not mount AFS/CEPH/whateverFS too(for example)?
+[00:02:19] <Pinkbyte> should it be other bug too?
+[00:02:26] <Zero_Chaos> Pinkbyte: I don't see how hilighting additional bugs makes mine invalid....
+[00:02:45] <Pinkbyte> should netmount depends hardly on EVERY initscript of every net-based file system?
+[00:03:00] <WilliamH> Pinkbyte: that is unreasonable.
+[00:03:04] <Zero_Chaos> Pinkbyte: no, that's why WilliamH and I agreed to have 'want' added to openrc
+[00:03:13] <Zero_Chaos> Pinkbyte: so it can use things which are there, but not fail if they are not.
+[00:03:20] <Pinkbyte> Zero_Chaos, ok, that's another issue you want it
+[00:03:26] <Pinkbyte> that depends on that one
+[00:03:42] <Zero_Chaos> Pinkbyte: yes, the bug for fixing nfs would dep on the bug for "want"
+[00:03:57] <WilliamH> Pinkbyte: It works right now if users follow the instructions covered in the newsitem.
+[00:04:12] <Pinkbyte> simple as that - document current behaviour with workarounds, set proper depends on bug and remove QA from there
+[00:04:13] <Zero_Chaos> Pinkbyte: I do not dispute that
+[00:04:15] <WilliamH> Pinkbyte: The newsitem was very clear about what you need to do.
+[00:04:40] <Zero_Chaos> WilliamH: I agree with pinkbyte, set my bug to dep the one on adding 'want' and drop qa from my bug is fine.
+[00:04:59] <Pinkbyte> So, everything for workaround is set up. We do not need QA involvement in there, no breakages that users are unaware from are happening
+[00:05:10] <Zero_Chaos> I accept
+[00:05:32] <WilliamH> Pinkbyte: I vote close zero's bug because if you do what you are told in the newsitem things work. then,
+[00:05:41] <WilliamH> Pinkbyte: let me finish.
+[00:06:05] <Zero_Chaos> WilliamH: if you want my bug closed against my wishes, I believe it will need to go to a vote.
+[00:06:34] <WilliamH> Pinkbyte: bug 406021 is a separate feature I have agreed to work on, but not having it isn't a bug if you folow the docs.
+[00:06:36] <willikins> WilliamH: "sys-apps/openrc -"want" soft-dependency"; Gentoo Hosted Projects, OpenRC; CONF; polynomial-c:openrc
+[00:06:47] <Zero_Chaos> WilliamH: documenting a bug doesn't make it a feature.
+[00:07:11] <Pinkbyte> WilliamH, why you need that bug to be closed right now? It's example behaviour that you can see improved after realizing "want" feature
+[00:07:16] <WilliamH> Zero_Chaos: it isn't a bug. Like I said it works fine in the default setup. you removed netmount; that is on you.
+[00:07:26] <Zero_Chaos> WilliamH: you are missing a dep, it's a bug.
+[00:07:48] <WilliamH> Zero_Chaos: no sir
+[00:08:19] <WilliamH> Zero_Chaos: we don't have depends in localmount or netmount for all of the things they need to mount file systems.
+[00:08:24] <Zero_Chaos> WilliamH: we both know how the other feels, if we still have enough of the team let's just vote, shall we?
+[00:08:57] <mgorny> vote: deprecate openrc, use systemd which is free of such issues
+[00:09:02] <Pinkbyte> Guys! Currently it's a workarounded bug. It is workarounded because of lacking features in OpenRC. It's workarounded nicely, so it would not hurt anyone, if they follow workarounds properly
+[00:09:06] <WilliamH> But this brings up an interesting question... Even if we do vote, OpenRC is an independent upstream... Does the vote matter?
+[00:09:47] <Zero_Chaos> Pinkbyte: he wants to close the bug because he doesn't feel it's a bug, I want it open because a missing dep is a bug. So this elevates back up to qa
+[00:10:01] <Zero_Chaos> WilliamH: the vote is about a gentoo bug, so yes, it matters.
+[00:10:07] <Pinkbyte> Ok, then, let's vote
+[00:10:19] <Zero_Chaos> may we each explain briefly the issue?
+[00:10:40] <Pinkbyte> WilliamH, if you want that patch realizing 'want' was Gentoo-specific - that would be a problem. If no - no, it would not
+[00:10:58] <WilliamH> Well, I do plan to work on want.
+[00:11:12] <Pinkbyte> WilliamH, so...
+[00:11:14] <WilliamH> But, the bug I sited from zero isn't really a bug because
+[00:11:16] <Zero_Chaos> WilliamH: as is standard in legal proceeding, I brought the charges, may I explain my issue, you defend, and we vote?
+[00:11:39] <WilliamH> there is procedure in place to handle it.
+[00:12:02] <WilliamH> and president (sp) for openrc behaving that way.
+[00:12:05] <Zero_Chaos> WilliamH: you are dragging your feet on the vote, we don't have all day. let's just get to this.
+[00:12:08] <Pinkbyte> Guys, the all discussion here is summarized by that picture -
+[00:12:16] <Pinkbyte> but if you want - fine, let's vote
+[00:12:32] <WilliamH> wait
+[00:12:38] <WilliamH> the picture does me no good. ;-)
+[00:12:43] <Zero_Chaos> Pinkbyte: who explains (briefly) first? I think this merits explaination
+[00:13:01] <Zero_Chaos> WilliamH: it was a lame picture anyway, picture of a bug, then a bug in a suit marked "feature"
+[00:13:19] <ulm> I use nfs but this issue never hit me
+[00:13:21] <WilliamH> Here's where I'm at on it.
+[00:13:27] <ulm> maybe because I'm using autofs?
+[00:13:37] <WilliamH> ulm: maybe...
+[00:13:59] <WilliamH> ulm: basically, nfsclient has "before netmount" in the dependencies.
+[00:14:20] <WilliamH> ulm: nfsmount did in the past handle the mounting as well, but now it doesn't, so it was renamed nfsclient.
+[00:14:46] <WilliamH> ulm: netmount for a while was a noop... zero's bug has all of the history
+[00:15:09] <Zero_Chaos> can we please just each say a short explaination and vote? I have 10 minutes before my next meeting....
+[00:15:18] <WilliamH> ulm: zero removed netmount from his default runlevel because he didn't want it running.
+[00:15:20] <Zero_Chaos> please, let's do this or drop it and stop wasting everyone's time
+[00:15:38] <WilliamH> Zero_Chaos: do we really need a vote on this?
+[00:15:56] <WilliamH> Zero_Chaos: I agreed to work on "want", and the other bug is resolved per qa instructions and a newsitem.
+[00:16:15] <Zero_Chaos> WilliamH: I do not want my bug closed until it's fixed. So yes, if you want to close it without fixing it, we need a vote.
+[00:16:25] <Zero_Chaos> WilliamH: win, and you get to close the bug
+[00:16:34] <Zero_Chaos> but for the love of god, we need to do this or drop it
+[00:16:47] <Zero_Chaos> I only had an hour and a half for this meeting
+[00:16:59] <WilliamH> Zero_Chaos: I agreed that want is a feature I'll look into. But, as things currently stand, if you follow the instructions in thenewsitem things work.
+[00:17:33] <Zero_Chaos> WilliamH: I refuse to argue with you on this any further. agree to a vote or drop it. now.
+[00:17:46] <Zero_Chaos> I lack the time for this
+[00:18:17] <WilliamH> Zero_Chaos: fine, vote, but if I lose I will go straight to council.
+[00:18:27] <ulm> Pinkbyte: what is the motion?
+[00:18:31] <Pinkbyte> WilliamH, it's your right
+[00:18:37] <Zero_Chaos> WilliamH: as is your right
+[00:18:44] <Zero_Chaos> Pinkbyte: who explains their side first?
+[00:19:05] <Pinkbyte> ulm, "Bug #537996 - should it be closed as fixed?"
+[00:19:08] <willikins> Pinkbyte: ">=sys-apps/openrc-0.13 netmount script cannot properly mount nfs shares"; Gentoo Hosted Projects, OpenRC; CONF; zerochaos:openrc
+[00:19:24] <Zero_Chaos> can we please give a brief description before the vote?
+[00:19:26] <Zero_Chaos> it's a long bug
+[00:19:43] <ulm> < 100 chars please :p
+[00:20:41] <Zero_Chaos> I'll be quick. nfs is supposed to be mounted by netmount, but netmount cannot do it without a helper which is not in the dep list.
+[00:21:35] <Pinkbyte> helper can not be added as 'need' dependency(because nfs-utils should be added to RDEPEND list of openrc too), and 'use' dependency makes no sense too
+[00:21:56] <Pinkbyte> however, most of OTHER filesystem, unlike nfs is as 'use' dependencies in netmount script already
+[00:21:57] <Zero_Chaos> right, so WilliamH and I agreed that openrc needed 'want' which would resolve this issue when implemented
+[00:22:13] <Pinkbyte> so it's a question - is all of them refers to this bug, or NFS is a special case?
+[00:22:53] <WilliamH> May I state my side?
+[00:23:00] <Pinkbyte> WilliamH, sure
+[00:23:01] <Zero_Chaos> WilliamH: please do
+[00:24:26] <WilliamH> OpenRC, by default, puts netmount in the default runlevel. nfsmount has "before netmount" and netmount now has "use nfsmount" in their dependencies. The newsitem I released with the new openrc tells you to add both to your runlevels.
+[00:24:49] <WilliamH> If you do that, things start as they should.
+[00:24:52] <WilliamH> and netmount works.
+[00:25:52] <WilliamH> I have agreed to look into adding the "want" dependency as an enhancement, but that is separate from this issue.
+[00:26:26] <WilliamH> I'm done.
+[00:26:27] <ulm> WilliamH: I thought nfsmount was deprecated?
+[00:26:50] <ulm> you mean "use nfsclient"?
+[00:26:56] <WilliamH> ulm: nfsmount is nfsclient now. again, you add nfsclient to your runlevel as stated in the newsitem.
+[00:27:02] <WilliamH> hang on.
+[00:27:10] <WilliamH> How can I link to the newsitem here?
+[00:27:14] <Zero_Chaos> this is a lot more than 100 char at this point
+[00:27:29] <Zero_Chaos> and I'm out of time
+[00:27:30] <ulm> WilliamH: above you said 'netmount now has "use nfsmount" in their dependencies'
+[00:27:48] <WilliamH> It is 2015-02-02-nfs-service-changes
+[00:27:49] <ulm> should read "use nfsclient", I guess?
+[00:27:51] <Zero_Chaos> Pinkbyte: please count that I vote against closing my bug until it is fixed, but I agree to making to dep the 'want' but and removing QA.
+[00:28:00] <Pinkbyte> Zero_Chaos, sure
+[00:28:35] <WilliamH> ulm: that use was put there because pinkbyte requested it.
+[00:29:10] <ulm> now you've managed to completely confuse me
+[00:29:15] <Pinkbyte> ulm, it's the closest currently available dependency measure
+[00:29:41] <Pinkbyte> ulm, problem is - 'use FOO' would not start foo, unless service foo is added into the same runlevel
+[00:29:54] <ulm> on my system here I see "need nfsclient netmount" in nfsmount
+[00:30:00] <Pinkbyte> 'need FOO' would do the trick, but it's hard dependency, not soft
+[00:30:04] <ulm> openrc-0.13.9
+[00:30:20] <Pinkbyte> ulm, look at nfsclient
+[00:30:26] <WilliamH> ulm: the nfsmount script was re-added by robbat2 to catch people who didn't follow the news item.
+[00:30:31] <ulm> and netmount has "use nfsclient"
+[00:31:05] <Pinkbyte> ulm, i am sorry, netmount of course.
+[00:31:07] <Pinkbyte> yeah
+[00:31:08] <Zero_Chaos> Pinkbyte: the real solution to my issue is add 'want' support to openrc, and then "want nfsclient" when nfs mount are in fstab. the patch is written, WilliamH agreed to add want support when he has time, so my bug tracks the issue.
+[00:31:15] <WilliamH> ulm: that change too netmount was requested by Pinkbyte
+[00:31:19] <Zero_Chaos> Pinkbyte: we agree on everything except the fact that it's a bug.
+[00:32:13] <WilliamH> Pinkbyte: imo this is all happening because Zero_Chaos removed netmount from his default runlevel.
+[00:33:01] <Pinkbyte> WilliamH, non-default setup is not always a bug itself, sometimes it reveals bugs
+[00:33:28] <WilliamH> Pinkbyte: the news item specifically tells you to make sure netmount and nfsclient are in the same runlevel.
+[00:33:54] <Pinkbyte> WilliamH, true
+[00:33:58] <WilliamH> How do I link to it here?
+[00:34:11] <Zero_Chaos> WilliamH: they are, niether is in any run level at all :-)
+[00:34:44] <WilliamH> Zero_Chaos: then you aren't following instructions. :p
+[00:34:57] <Pinkbyte>
+[00:35:08] <WilliamH> I need a link to the newsitem in this channel so everyone can see it.
+[00:35:22] <Zero_Chaos> I do not contend the news item is wrong
+[00:35:25] <WilliamH> ok
+[00:35:27] <Zero_Chaos> I contend the init script is wrong
+[00:35:49] <WilliamH> Zero_Chaos: then what you are asking for is the want feature, wich has a separate bug.
+[00:36:08] <WilliamH> Zero_Chaos: so we don't need two bugs open.
+[00:36:56] <Pinkbyte> How about that solution - rename bug to "nfsclient dependendency should be 'want'", depend that bug on other one, about the feature itself and lower it's priority to enhancement
+[00:36:57] <WilliamH> Zero_Chaos: the want feature is bug 406021
+[00:37:00] <willikins> WilliamH: "sys-apps/openrc -"want" soft-dependency"; Gentoo Hosted Projects, OpenRC; CONF; polynomial-c:openrc
+[00:37:05] <Pinkbyte> so you could track all things up properly
+[00:37:16] <Pinkbyte> and remove qa@ from it, of course
+[00:37:51] <Zero_Chaos> Pinkbyte: I would accept that as well. I would accept almost anything that keeps my issue properly tracked
+[00:38:20] <WilliamH> Zero_Chaos: I don't see why we need a dupe bug which is basically what yours is.
+[00:38:38] <WilliamH> Zero_Chaos: I think if I dupe it it will move you to the other bug...
+[00:39:04] <Pinkbyte> WilliamH, your bug is about feature itself. Zero_Chaos's bug is about which script should utilize this feature after it would be implemented
+[00:39:04] <WilliamH> Zero_Chaos: Can I test that and reopen it if it doesn't?
+[00:39:36] <ulm> guys, we're approaching 3 hours meeting time ...
+[00:39:49] <Zero_Chaos> WilliamH: this is not a dupe, it is a missing dep in your init script which cannot be solved without a feature enhancement
+[00:40:22] <Pinkbyte> WilliamH, let's recap - you will code nice and shiny 'want' feature. But you will need to remember which initscript will have benefits from it
+[00:40:29] <Pinkbyte> or dig into closed bugs for that
+[00:41:04] <Pinkbyte> or wait until new bug would be opened for exactly the same issue with netmount/nfsclient
+[00:41:38] <Zero_Chaos> right
+[00:41:41] <WilliamH> Pinkbyte: ok... do that for now...
+[00:43:14] <Zero_Chaos> WilliamH: you want to close my bug, add the want feature, and for me to reopen my bug and as for "want nfsclient" (which is exactly my bug now)? that makes no sense.
+[00:43:34] <Zero_Chaos> I think this issue makes sense to all, let's vote so we can end this pain.
+[00:43:42] <WilliamH> Zero_Chaos: no, I just agreed with him to drop the priority on yours etc.
+[00:44:49] <Zero_Chaos> WilliamH: I am fine with making my bug an "enhancement" and marking the want bug as a depend. If that meets your approval, please proceed.
+[00:44:59] <Zero_Chaos> WilliamH: just don't close my bug.
+[00:45:28] <WilliamH> Zero_Chaos: ok
+[00:45:42] <Pinkbyte> I am really glad that we finally make some consensus here. Thanks for you both
+[00:46:26] <Pinkbyte> So, i propose we will end our meeting now, cause, as ulm is mentioned - we hit 3 hours barrier and it's not really good
+[00:46:53] <WilliamH> go for it ;-)
+[00:47:00] <Pinkbyte> But honestly - there is 00:46 am now on my clock and i need to be at work at 08:00 am, so... i just want to go to bed :-P
+[00:47:10] <mrueg> Pinkbyte: just one last question
+[00:47:32] <mrueg> is there an invite-only gentoo qa channel?
+[00:47:46] <mrueg> I haven't found any information on that.
+[00:47:54] <Pinkbyte> mrueg, nope. And i do not think we need to have that channel
+[00:47:57] <mrueg> Tommy[D] told me that qa@g.o is used for that
+[00:48:01] <ulm> there is #gentoo-qa-private
+[00:48:09] <mrueg> heh.
+[00:48:12] <Pinkbyte> ulm, o_O
+[00:48:19] <ulm> but no idea who uses it
+[00:48:38] <Pinkbyte> so, it's non-official
+[00:49:32] <ulm> founded by creffett, as it looks like
+[00:49:43] <mrueg> creffett|irssi: ^
+[00:49:51] <ulm> and most qa members are listed
+[00:50:05] <Pinkbyte> yep. And i am(along with almost all team members) lucky to be in access list of it
+[00:50:21] <ulm> but I don't see mrueg there
+[00:51:09] <Pinkbyte> ulm, yep, the other place that i forgot to send a request to add him to. Because i did not even know about it :-)
+[00:51:42] <mrueg> Pinkbyte: should we document adding new qa members somewhere in the wiki?
+[00:52:22] <Pinkbyte> mrueg, maybe. You can draft an article as a member, who went through all that pain :-)
+[00:52:37] <ulm> Pinkbyte: only creffett has +f there
+[00:52:38] <mrueg> Pinkbyte: okay will do ;)