Import QA team meeting logs.HEADmaster

https://dev.gentoo.org/~wired/qa/meetings/gentoo-qa-team-meeting-log-20140129.txt

1 files changed, 773 insertions, 0 deletions

diff --git a/meeting-logs/20140129.txt b/meeting-logs/20140129.txt
new file mode 100644
index 0000000..817e575
--- /dev/null
+++ b/meeting-logs/20140129.txt
@@ -0,0 +1,773 @@
+[20:04:26] <creffett> let's get this show on the road then
+[20:05:20] <creffett> bonsaikitten, Pinkbyte Tommy[D], TomWij, ulm, wired, WilliamH, Zero_Chaos, zlogene: showtime
+[20:05:25] <wired> o/
+[20:05:29] <Pinkbyte> \o/
+[20:05:30] * creffett grumbles about no !expn qa
+[20:05:36] <zlogene> ^_^ 
+[20:06:03] * ulm here
+[20:06:15] <Pinkbyte> creffett, i hope you will log this and make this available in public later, as usual ;-)
+[20:06:15] <Tommy[D]> creffett: you are the master, so your showtime :)
+[20:06:17] <TomWij> creffett: oh hi
+[20:06:18] * creffett waits a couple more minutes in case anybody else shows up
+[20:06:29] <creffett> Pinkbyte: sure
+[20:06:30] * wired has logs as well if needed
+[20:06:41] <TomWij> !logs++
+[20:07:01] <Tommy[D]> i log all channels i am in, if anyone needs a log
+[20:07:44] <creffett> pretty sure Zero_Chaos said he can't make this time, no idea on bonsaikitten or WilliamH
+[20:07:46] <creffett> eh, let's get started
+[20:07:51] * WilliamH is here
+[20:07:57] <creffett> that works too
+[20:07:59] <creffett> 8/10 isn't bad
+[20:08:27] <creffett> first order of business: for those who missed it, I've appointed TomWij deputy QA lead
+[20:09:06] <creffett> so when I'm out (which will be a lot of weekends this semester) and a decision has to be made, he's in charge
+[20:09:46] <wired> great :)
+[20:09:58] <creffett> save all your difficult decisions for him ;)
+[20:10:00] <Pinkbyte> Good. I have to read the whole docs about QA team. IIRC correctly, deputy can be appointed without council intervention, huh?
+[20:10:19] <creffett> Pinkbyte: correct, the appointment is up to me, and he is answerable to me
+[20:10:22] <WilliamH> Pinkbyte: right.
+[20:10:31] <creffett> and anything he does as deputy lead carries the same weight as my decisions
+[20:11:22] <creffett> next: meeting scheduling
+[20:11:43] <Pinkbyte> good. I am sorry for being noisy, will we have open floor on this meeting like on Qt ones? I have some topics to bring, but i do not want to interfere your routine, creffett  ;-)
+[20:11:53] <creffett> Pinkbyte: yup, we'll hit that at the end
+[20:12:00] <creffett> I'm sure we have a lot to talk about that I don't have on the agenda
+[20:12:08] <Pinkbyte> creffett, good, now i shut up and i am all ears
+[20:12:37] <creffett> it's currently the fifth Wednesday of the month, which is generally not a good number to plan around, so how does regularly meeting on the third Wednesday of every month, 1800 UTC sound to everyone?
+[20:12:51] * WilliamH is fine with that
+[20:13:05] <ulm> I'd prefer one hour later, i.e. 19 UTC
+[20:13:09] <WilliamH> That's a week after Council.
+[20:13:17] <ulm> not sure if I can always make it at 18
+[20:13:21] <WilliamH> 19 is fine too
+[20:13:32] <wired> I'm fine with 1800 or later
+[20:13:39] <Pinkbyte> Fine by me. 19 UTC is fine too, but is close to limit of beeing sleepy :-)
+[20:13:51] <creffett> I can do 19 (though I'm worried about how it will work this summer, but I'll worry about that later)
+[20:13:52] <TomWij> One week after Council is a good idea, if they decide something that we need to reflect on or so; ideal to follow up a week later.
+[20:13:56] * zlogene is fine with that 
+[20:14:01] <TomWij> And +1 on ulm's 19 UTC.
+[20:14:40] <creffett> Tommy[D]: does that time work for you?
+[20:15:31] <Tommy[D]> should work for me, hope there will be reminders before those dates, otherwise i may likely miss them while doing something different
+[20:15:50] <creffett> okay, we can start sending regular team meeting announcements out
+[20:15:53] * creffett bangs his gavel
+[20:16:09] <ulm> there's a gentoo calendar in google, too
+[20:16:19] <creffett> really? I did not know that
+[20:16:20] <Pinkbyte> ulm, huh?
+[20:16:22] <ulm> I can put the date there
+[20:16:31] <wired> I added today's meeting there
+[20:16:34] <Tommy[D]> not everyone uses google ;)
+[20:16:39] <wired> :)
+[20:16:53] <Pinkbyte> not everyone knows that such  thing exists
+[20:17:03] <creffett> ulm: where can one view this calendar?
+[20:17:03] <Pinkbyte> i mean gentoo calendar on google, not google itself :-)
+[20:17:17] <creffett> Pinkbyte: what is this "goo-gle" you speak of ;)
+[20:17:21] <creffett> is it like Bing?
+[20:17:22] <zlogene> Pinkbyte: i know, but forgot aboyt that 
+[20:17:36] <zlogene> *about
+[20:17:36] <ulm> Pinkbyte: google calendar, then search for gentoo?
+[20:17:58] <creffett> I didn't know you can search for a calenar
+[20:18:12] <wired> https://www.google.com/calendar/embed?src=88di0t0pl2cfau7oak48rbccfs%40group.calendar.google.com&showCalendars=0&color=%235229A3
+[20:18:17] <wired> ^^ Gentoo Calendar
+[20:18:40] <wired> use the button at the bottom right corner to add it to your google account
+[20:18:41] <creffett> awesome
+[20:18:48] <ulm> wired: thanks
+[20:19:14] <wired> yw
+[20:19:32] <Pinkbyte> wired, i can not find it properly(only found upcoming events). Thanks for the direct link
+[20:20:09] <creffett> okay, let's move on to discussion topics
+[20:20:21] <creffett> 1. Policymaking workflow
+[20:21:35] <creffett> what I have in mind right now is something like person brings us problem -> we look into problem, discuss at meeting -> if no policy on problem, make policy; if policy/docs unclear, update them; if they're actively ignoring policy...politely ask them to stop
+[20:21:46] <creffett> so it's more reactive than proactive
+[20:22:35] <creffett> anyone have improvements/suggestions/completely different ideas?
+[20:23:26] <TomWij> With a monthly meeting it makes sense to do the policymaking at the meeting; if it needs to happen more often (doubt it, compared to Cuncil) we can change the workflow later if needed.
+[20:23:51] <creffett> agreed, and this does not preclude emergency action on our part
+[20:23:53] <Pinkbyte> creffett, i think this ok, but we should some measure to stop bringing suspicious "enhancements" into tree before policy will be created
+[20:23:54] <Tommy[D]> looks fine to me, will give the team the time to work out basic rules and workflows, we might do more proactive tasks later one, if there is any need for them
+[20:24:07] <creffett> Pinkbyte: what do you mean?
+[20:24:26] <Pinkbyte> i do not mean to suspend someone's rights, just polite "please do not do more of this before we will have clear idea is it good or not"
+[20:24:43] <creffett> Pinkbyte: that sounds good
+[20:24:51] <Pinkbyte> well, situation somebody commits shit, but there is no policy defining that this is really shit
+[20:25:19] <creffett> then if we think someone's breaking stuff, yeah, I think it's fair to ask them to stop pending a QA review
+[20:25:37] <Pinkbyte> so, we asks him to stop for now, do not touch what he did before(if this did not broke tree entirely), talk about this - and them do our thing(fix or remove shit)
+[20:25:54] <creffett> reminder: in the case where QA and the maintainer disagree, the expectation is that it be left how QA wants it until the Council can rule on the matter
+[20:25:59] <creffett> Pinkbyte: yeah, sounds good
+[20:26:16] <creffett> and if it really is breaking stuff, then it is fine for QA to tell someone to stop
+[20:27:10] <wired> creffett: the workflow you described seems pretty realistic to me
+[20:27:30] <WilliamH> It sounds good to me too.
+[20:27:42] <zlogene> sounds good for me 
+[20:27:57] <TomWij> +1
+[20:27:59] <ulm> +1
+[20:28:09] <creffett> unanimous, then
+[20:28:11] * creffett bangs his gavel
+[20:29:18] <creffett> next question: how much communication are we expected to have with devs when we make changes to their packages?
+[20:29:58] <wired> depends on the fix
+[20:30:18] <creffett> let's group it into...two? categories
+[20:30:26] <wired> I'd say, if it's critical, fix and contact at the same time
+[20:30:28] * WilliamH agrees, it depends on the fix.
+[20:30:34] <wired> otherwise, try to contact first
+[20:30:36] <creffett> trivial stuff like fixing repoman errors, and stuff that actually changes the package
+[20:30:49] <creffett> maybe add a third "critical" category
+[20:31:38] <creffett> a second question relevant to this is how long we wait before making a fix ourselves
+[20:31:44] <zlogene> ok, so i have question, how long we must wait for maintainers respond
+[20:31:47] <zlogene> ah
+[20:31:53] <wired> ++, trivial stuff that doesn't change the way the ebuild works don't really need communication either
+[20:32:16] <zlogene> ++
+[20:32:20] <creffett> ++
+[20:32:30] <wired> I'm thinking something around 2 weeks
+[20:32:58] <creffett> so trivial stuff, we fix and maybe ping them (optionally), critical stuff (package- or tree-breaking) we fix and ping them, that leaves us with the gray area in the middle
+[20:33:22] <creffett> so...file a bug, wait two weeks, fix?
+[20:33:25] <Tommy[D]> for the trivial stuff, some notification to the comitter/maintainer about it might be a good idea, so that he in the future can have an additional look to avoid such problems
+[20:34:31] <Pinkbyte> yeah, post-factum notification is good for trivial cases. Just e-mail the maintainer saying 'hey, we are fix small problem, be ready for breakage^W^W^W^W. Have a nice day!"
+[20:34:33] <creffett> Tommy[D]: good point
+[20:34:37] <wired> creffett: well, if they don't respond and they're violating policy, I don't see any way around this. two weeks should be enough for anyone to respond.
+[20:34:43] * Pinkbyte is too funny, need to be serious...
+[20:34:49] <Tommy[D]> with inclusion of the 2 weeks in the bug (so that the maintainer knows about it before it happens), that sounds fine
+[20:34:52] <wired> Tommy[D]: agreed. depends on the fix, but yeah
+[20:35:15] <creffett> wired: mhm, sounds right to me
+[20:35:27] <creffett> I just want to have a bug open for communicating and tracking the issue
+[20:35:40] <wired> agreed, I thought that was implied :)
+[20:35:58] <creffett> it could be done just via email/pinging/whatever, I guess
+[20:36:22] <Pinkbyte> creffett, bug workflow is more open and is more useful for non-trivial things
+[20:36:33] <wired> just open a bug, keeps things documented :)
+[20:36:46] <TomWij> And ... what means pinging? Not everyone is on IRC. Not everyone appreciates mails (what we might perceive non-trivial they might perceive trivial, etc...). The gray area here plays a huge role...
+[20:36:57] <creffett> mhm, so I'm happy with filing a bug
+[20:37:13] <Pinkbyte> TomWij, well, we have documented way of communication - bugzilla. It relies on e-mails
+[20:37:26] <TomWij> So, pinging means bug usually on non-trivial matters; ok, sounds good.
+[20:37:52] <Pinkbyte> so, if any Gentoo dev ignore e-mails about severe breakages of his packages - he must be thrown through the windows in the room of hardly laughing people
+[20:38:38] <creffett> mhm
+[20:38:42] <zlogene> :D
+[20:38:44] <creffett> so, are we happy with "fix and send a friendly reminder for trivial fixes; open bug, wait 2 weeks, make change for larger but non-critical fixes; make change and send a notification for critical fixes" as our methodology?
+[20:38:56] <wired> ++
+[20:39:00] <zlogene> +1
+[20:39:14] <ulm> fine with me
+[20:39:36] <TomWij> Imo maintainers should even check ChangeLog, like when you would do `git pull ; git log` in a typical repositry; but I guess a tree-wide `cvs up` makes it a bit harder to notice there was a commit on your package.
+[20:40:15] <creffett> yeah, I personally don't check changelogs, so I think it's nice to ping on changes
+[20:40:40] <Pinkbyte> TomWij, well, maintainers can be subscribed to gentoo-commits with filters on their own packages. But that would be a lot of noise, so we should not force that
+[20:40:49] <Tommy[D]> fint with me
+[20:41:22] <wired> maintainers should just accept that other people may touch their packages for some [important] reason and keep that in mind :)
+[20:41:31] <creffett> WilliamH, TomWij, Pinkbyte: okay with you all?
+[20:41:31] <TomWij> +1 on the methodology; the gray area is going to be a bit annoying, but we'll have to see that on on a case by case basis which needs to go where. I guess we'll learn what's best to do for each case as we come across them...
+[20:41:51] <WilliamH> Sounds good to me.
+[20:42:07] <Pinkbyte> creffett, yep
+[20:42:36] * creffett bangs his gavel
+[20:42:40] <wired> https://www.youtube.com/watch?v=TbEuMTOA3fo&t=3s
+[20:42:44] <wired> just had to :P
+[20:43:00] <creffett> wired: thank you :P
+[20:43:04] <creffett> next:  What to do about the GTK USE flag situation? (hasufell's recent emails)
+[20:43:05] <wired> xD
+[20:43:37] <Pinkbyte> creffett, well, tbh, i am someway lost here. I think we should stick this as a policy with help from GNOME team.
+[20:43:53] <creffett> summary: the concern is that we have flags gtk, gtk2, gtk3, they're all very ambiguous, yadda yadda yadday
+[20:44:02] <Pinkbyte> cause if it remains plain recomendation, people will be lazy to follow it
+[20:44:06] <WilliamH> I would recommend that people follow the gnome team's practice with that situation
+[20:44:16] * creffett still thinks that the qt solution (number all instead of having a generic "gtk" flag) is best, but that's just me
+[20:44:22] <Pinkbyte> But removing gtk2 support as GNOME team does is not an option too
+[20:44:24] <wired> please don't force people to use one toolkit
+[20:44:30] <wired> (version)
+[20:44:38] <ulm> IMHO, we should get rid of the gtk2 flag, but maintainers can leave the gtk3 flag in place if they have good reason
+[20:44:40] <creffett> TomWij: you had some concerns about the GNOME team's solution
+[20:44:44] <TomWij> creffett: The one idea where we proceed with making it policy, and then look at the cases where people disagree with it and find solutions for those individual situations might fit.
+[20:44:45] <Pinkbyte> wired, +1. I do this and because of that we lost one contributor
+[20:44:49] <Pinkbyte> blame me :'-(
+[20:45:15] <wired> it just doesn't make sense
+[20:45:31] <TomWij> creffett: 'cause during a quick scan a while ago I saw there were reasons to not do it on the WONTFIX bugs, haven't looked into detail into them though.
+[20:45:41] <creffett> TomWij: all right
+[20:45:46] <wired> personally I'm all for the 'versioned use flags only' solution
+[20:46:07] <wired> but I'm fine with gtk/gtk3 as well (since it would be too much work to change now)
+[20:46:16] <WilliamH> Do the old toolkits work with current gnome?
+[20:46:28] * WilliamH is a little confused on this to be honest
+[20:46:36] <wired> I just don't see why we can't have gtk and gtk3 at the same time for packages that support both toolkit versions
+[20:47:00] <TomWij> leio: If around, feel free to provide details / comments wrt the gtk USE flags. ^
+[20:47:09] <creffett> wired: the policy suggests that as an option, but they seem to recommend forcing gtk3
+[20:47:12] <leio> Hello.
+[20:47:14] <wired> WilliamH: the way I understand it (I was hit by this on one of the packages I maintain), the gnome team wants you to choose the toolkit for the user, instead of letting them decide
+[20:47:56] <leio> backlog on the topic starting at just xx:39?
+[20:48:05] <creffett> leio: correct
+[20:48:09] <TomWij> Affirmative, with the "next: ..." message.
+[20:48:36] <ulm> wired: same for emacs, currently the user can choose between Xaw, Xaw3d, motif, gtk2, or gtk3
+[20:48:56] <ulm> and I don't see why I should take away any of these choices from them
+[20:49:01] <wired> ++
+[20:49:23] <WilliamH> Are all of those toolkits being actively maintained by upstreams?
+[20:49:31] <creffett> ulm: I think that in that case the official recommendation is to change the flags to gtk/gtk3 instead of gtk2/gtk3
+[20:49:33] <leio> gtk2 is not very actively maintained.
+[20:50:04] <ulm> WilliamH: gtk has some severe bugs affecting emacs in both versions
+[20:50:10] <wired> leio: it's still here though
+[20:50:28] <leio> Theoretically gtk3 should be better, so we hope that applications move over to it, and that maintainers make it use gtk3 instead of gtk2 without an in-tree option to avoid that; BUT only if the gtk3 port is as good as gtk2 one; otherwise stick to gtk2 only until gtk3 port catches up
+[20:50:44] <kensington> creffett: it would be nice to confirm such a recommendation, for example we will have this issue all over again when qt5 is unleashed and it would be nice to get it right from the start
+[20:50:56] <ulm> creffett: right, gtk should select the toolkit, and gtk3 then says that version 3 is preferred over 2
+[20:51:06] <leio> gtk3 USE flag is meant for things that provide support for both gtk2 and gtk3 libraries; this is primarily gtk theme engines and input methods
+[20:51:16] <ulm> so the gtk2 flag can be punted
+[20:51:23] <creffett> kensington: are you asking that we make this policy for USE flags in general which might depend on one of several slots of a toolkit?
+[20:51:57] <leio> meanwhile libraries that do either gtk2 or gtk3 should be SLOTted like all the GNOME libraries that depend on gtk+ and existed in the gnome2 times too
+[20:52:15] <Pinkbyte> ulm, well it is a bit trickier. We can not make this as for USE="ssl". And qt situation is a bit different - USE-flags are versioned
+[20:52:16] <ulm> leio: why can't we leave the choice to the user also for applications? in some cases that makes sense
+[20:52:17] <kensington> creffett: it could be something worth considering considering the wide reach it will have, beyond the decisions of one small team
+[20:52:19] <leio> that way users don't need to mess with USE flags just to get the necessary support libraries for the application they really care about
+[20:52:36] <leio> well, bring an example of a case maybe
+[20:52:53] <wired> kensington: the state of Qt is pretty straightforward IMO, we have qt4 and we'll add qt5, the confusion will be far lesser cause the old use flag is already versioned
+[20:52:54] <ulm> leio: see above, emacs
+[20:53:16] <leio> why specifically would you prefer gtk2 over gtk3 there
+[20:53:16] <wired> s/'ll add/added/
+[20:53:19] <Pinkbyte> leio, gtkdiskfree - both versions of GUI(gtk2 and gtk3), maintainer was upstream and he quits when i remove gtk2 support from ebuild
+[20:53:38] <Pinkbyte> both versions of GUI works flawlessly
+[20:53:50] <ulm> leio: because it crashes less often when using multihead support ;)
+[20:54:12] <leio> then maybe emacs gentoo maintainer should just offer gtk2, because gtk3 support is subpar
+[20:54:23] <ulm> but users not using that feature may prefer gtk3
+[20:54:24] <kensington> wired: sure, but there are still consistency issues to consider eg. a package requires qt (no USE flag), but next release supports both major versions
+[20:54:38] <wired> leio: there are reasons. themes. not really needing gtk3 if all your apps are still gtk2
+[20:55:01] <ulm> leio: and if I follow that logic, then I should remove gtk support altogether and go for Xaw3d or motif only ;)
+[20:55:44] <ulm> that would make evern more users unhappy, though
+[20:55:45] <leio> Upstream considers gtk3 as a natural follow-up to gtk2, it's just parallel installable to support gradual upgrading of everything to gtk3 versions due to API/ABI breaks
+[20:55:47] <ulm> *even
+[20:56:16] <leio> and the driving force from our end is mostly to pressure everything to go to gtk3; see also: gtk1 existing in tree after a decade
+[20:56:22] <ulm> leio: upstream should fix their bugs
+[20:57:01] <wired> leio: big changes like this one take time, as long as you have popular applications that have not migrated to the newer toolkit, you can't really expect to force anything to the user
+[20:57:06] <leio> point us to relevant upstream bugs, and I'll pressure or fix them ;)
+[20:57:27] <ulm> leio: https://bugzilla.gnome.org/show_bug.cgi?id=85715 to start with ;)
+[20:57:59] <ulm> I'll gladly drop gtk2 support if this is fixed in gtk3
+[20:58:04] <leio> and then xfce manages to go gtk3, we probably rush to it, no-one avoids gtk3 anymore and we have some USE flag proliferation
+[20:58:25] <leio> this leads me again to - why do we have a gtk USE flag at all
+[20:58:35] <leio> why isn't it named "gui"
+[20:58:41] <leio> ponder on that :)
+[20:58:59] <creffett> because some people prefer different toolkits?
+[20:59:00] <ulm> leio: because there are other toolkits, too?
+[20:59:00] <leio> this is mostly how it's used nowadays; for applications
+[20:59:18] <wired> cause some qties will come haunt you in your sleep then :p
+[20:59:41] <WilliamH> leio: so if we generalized "gtk" to "gui"  that would eliminate the confusion?
+[20:59:41] <Pinkbyte> leio, so, if package will have both qt and gtk GUIS... and we will have "qt4" and... "gui" USE-flag? srously?
+[20:59:53] <creffett> -- on "gui" USE
+[20:59:57] <leio> and "gtk" :)
+[21:00:13] <creffett> leio: that's just a useless additional flag, then
+[21:00:43] <leio> I believe USE flags should communicate functionality, not what dependency they pull in, but maybe that's just me.
+[21:01:10] <leio> either way, let me know if you want input from gnome team, I let you discuss and decide as per your meeting plan :)
+[21:01:12] <TomWij> Yeah, people could just mask the libraries they don't want, etc...
+[21:01:32] <creffett> but the gtk flag means "build gtk support"
+[21:01:35] <creffett> anyway
+[21:01:51] <wired> the only upside of "gui" would be that it could use REQUIRED_USE to force the user to select a toolkit afterwards, but it does seem a bit pointless
+[21:01:52] <Pinkbyte> guys, what's our options? 1. gtk for generic GTK support(tricky, different slot-based dependency, unobvious for user). 2. gtk for gtk2, gtk3 - for gtk3, probably sometimes REQUIRED_USE in action(when they can be build together, example - wireshark)
+[21:02:06] <Pinkbyte> any other option? please do not bring new USE-flags in this mess
+[21:02:22] <creffett> Pinkbyte: 3, make the entire tree hate us and move to gtk2 for gtk2 support, gtk3 for gtk3 support, ...
+[21:02:22] <Pinkbyte> renaming gtk -> gtk2 just for clarification will give us pain. No. PAIN!!!!
+[21:02:27] <ulm> gtk for gtk support (any version)
+[21:02:39] <ulm> gtk3 to prefer gtk3 over gtk2
+[21:02:39] <Pinkbyte> creffett, did i just tell about pain?
+[21:02:41] <Pinkbyte> :-)
+[21:02:59] <creffett> Pinkbyte: yes, yes you did
+[21:02:59] <wired> imo
+[21:03:00] <ulm> and get rid of the gtk2 flag
+[21:03:25] <wired> gtk should be gtk2, gtk3 should be used INSTEAD whenever gtk3 is supported and when gtk2 dies, we can get rid of gtk completely
+[21:03:32] <wired> then next time the change will be much simpler
+[21:03:34] <wired> (gtk3->gtk4)
+[21:03:40] <TomWij> What will we do when gtk4 is there? (Yes, it's a new USE flag; but an important one :P)
+[21:03:54] <TomWij> ^ Same thoughts :D
+[21:03:59] <wired> that's how qt does it and it seems so much cleaner to me
+[21:04:04] <leio> at this rate I'd rather kill gtk3 USE flag on applications and have USE=gtk2 mean "Prefer deprecated gtk2 over gtk3"
+[21:04:12] <Pinkbyte> TomWij, we do the same as we did for Qt
+[21:04:15] <leio> (I'm not sure how to handle theme engine providers in this scenario)
+[21:04:18] <Pinkbyte> i mean Qt3/4
+[21:04:35] <ulm> leio: also fine
+[21:04:56] <Pinkbyte> leio, i think going for preferring versioned USE-flag is a better idea
+[21:05:00] <ulm> most important point is that we should have only two flags but not three
+[21:05:02] <wired> leio: that would also work, but still not as clean as the versioned use flags imo. and gtk4 is going to be a mess again
+[21:05:09] <ulm> and their meaning should be clear
+[21:05:16] <Pinkbyte> i mean, someday we will drop USE="gtk" in favor of USE="gtk3" and possibly some USE="gtk4"
+[21:05:36] <Pinkbyte> wired, +1
+[21:05:37] <dilfridge> please remember that qt5 is imminent
+[21:05:58] <Pinkbyte> dilfridge, you tell me :-)
+[21:05:59] <leio> when gtk4 comes alone, there would be a USE=gtk3 for "Prefer deprecated gtk3 over gtk4" and hopefully by that date we've managed to convert everything in-tree to gtk3 and drop USE=gtk2
+[21:06:03] <ulm> so I'm fine with all of them: gtk/gtk2, gtk/gtk3, or gtk2/gtk3
+[21:06:15] <wired> leio: so you'll have to change all old package use flags to gtk3?
+[21:06:15] <Pinkbyte> leio, hopefully? :-)
+[21:06:20] <creffett> leio: but then you would have to change all of the flags...
+[21:06:31] <Pinkbyte> leio, we drop entire Qt3 thingie to fix this, i doubt that you will do the same
+[21:06:32] <leio> no, USE=gtk is still there for "Use gtk, any version"
+[21:06:42] <wired> why do you even need that?
+[21:07:02] <leio> for people to build only the command line interfaces of stuff.
+[21:07:10] <leio> Or pick Qt GUI over Gtk GUI
+[21:07:13] <wired> isn't -gtk2 -gtk3 enough?
+[21:07:27] <wired> or just -gtk3
+[21:07:31] <leio> I'm operating under the assumption there is a USE=gtk and only one of gtk2 or gtk3
+[21:07:31] <Pinkbyte> leio, why can not you use two strictly defined USE-flags instead of one ambigious?
+[21:07:44] <ulm> wired: not if the application supports several toolkit
+[21:07:47] <ulm> *s
+[21:08:06] <wired> ulm: what do you mean? so your app supports qt4, qt5, gtk2 and gtk3
+[21:08:10] <wired> and you have those 4 useflags
+[21:08:26] <ulm> wired: Xaw, Xaw3d, motif, gtk2, gtk3 ;)
+[21:08:35] <wired> yeah
+[21:08:46] <ulm> and yes, five USE flags ;)
+[21:08:52] <wired> my point is, there is no need to provide a generic "gtk" use flag
+[21:09:26] <Pinkbyte> wired, +1 again. :-)
+[21:09:33] <creffett> wired++
+[21:10:22] <ulm> guys, do we really want to go completely against the gnome team's recommendation?
+[21:10:24] <WilliamH> Isn't there also a generic qt use flag though?
+[21:10:29] <wired> no
+[21:10:31] <wired> we killed it
+[21:10:33] <creffett> WilliamH: nope
+[21:10:39] <wired> with fire :p
+[21:10:49] <Pinkbyte> wired, and it was good idea
+[21:10:51] <creffett> ulm: if a different recommendation makes more sense...then why not?
+[21:11:05] <wired> well, this is a big policy to enforce
+[21:11:18] <Pinkbyte> ulm, we do not want to force someone, but we also need tree consistent
+[21:11:19] <wired> but tbh, I'd like to see something like this gentoo-wide, it would make things simpler for users
+[21:11:24] <wired> Pinkbyte++
+[21:11:32] <Pinkbyte> so.... it is a matter of choice... and responsibility
+[21:11:40] <creffett> ulm: it also improves consistency across the tree, since we now have gtk$(ver), qt$(ver)...etc.
+[21:12:09] <ulm> hm, 239 / 2 / 28 packages using the gtk / gtk2 / gtk3 flags
+[21:12:15] <ulm> says eix
+[21:12:40] <creffett> so we burn the last two gtk2
+[21:12:50] <creffett> start transitioning gtk -> gtk3 for those that are gtk3 only
+[21:12:57] <ulm> creffett: that would be the least painful option
+[21:13:07] <creffett> and when gtk2 dies off, we celebrate
+[21:13:14] <ulm> burning gtk2, I mean
+[21:13:25] <wired> creffett: I'm all in for that
+[21:13:39] <Pinkbyte> ulm, gtk will mean support for GTK2
+[21:13:43] <Pinkbyte> when we end
+[21:13:49] <creffett> leio: would that be an acceptable compromise?
+[21:13:50] <ulm> media-sound/jalv and net-analyzer/wireshark are the last two gtk2 consumers
+[21:13:54] <Pinkbyte> because of renaming it into gtk2 is a bit more pain
+[21:14:02] <creffett> we can work out the details a little more in the future
+[21:14:43] <leio> I don't know, nor understand clearly why is this a good idea in any way; just don't decide something like that impromptu and discuss it with the GNOME team before, which consists of other (more active) people than me
+[21:14:59] <wired> perhaps a thread on -dev with the toolkit teams would be a good idea 
+[21:15:08] <Pinkbyte> wired, +1
+[21:15:17] <creffett> sounds good to me
+[21:15:27] <wired> we have a good case study to show (Qt) why we think this is a good plan
+[21:15:48] <Pinkbyte> leio, and we do not understand idea of generic USE-flag for two different versions of the same toolkit. It was a bad idea with Qt and we painly got rid of it
+[21:16:18] <WilliamH> wired: the down side, I guess, is that if
+[21:16:20] <Pinkbyte> leio, and please, do not appeal to USE="ssl" - it's a bit different case
+[21:16:40] <wired> ssl is a mess
+[21:16:47] <wired> please don't remind me
+[21:17:05] <WilliamH> wired: maintainers force the use flags on, with IUSE defaults,
+[21:17:20] <WilliamH> wired: users will have to constantly watch out for that if they don't want a gui
+[21:17:28] <wired> well
+[21:17:42] <wired> USE="-gtk3" should always take care of that
+[21:17:59] <WilliamH> wired: until gtk4 comes along
+[21:18:03] <wired> other than that, users who emerge stuff without checking out the useflags probably get what they deserve
+[21:18:10] <WilliamH> wired: USE="-gtk3 -gtk4 ..."
+[21:18:16] <wired> I mean, it's gonna be new deps, new use flags
+[21:18:21] <wired> how can you miss that?
+[21:18:22] <creffett> WilliamH: then, as with the impending qt5 introduction, they will add USE=-gtk4
+[21:18:22] <wired> :)
+[21:18:34] <Pinkbyte> WilliamH, i think that planning in a more than 5 years perspective(i do not think that we can see qt6 or gtk4 sooner) is a bit... brave :-)
+[21:19:04] <WilliamH> Ok, true...
+[21:19:49] <wired> oh look, emerge wants to rebuild half my packages with +gtk4... "Y<enter>"... a few days later: why do I have a ui version of this? D'UH
+[21:19:54] <wired> :p
+[21:20:23] <creffett> any objections to tentatively recommending "gtk means gtk2, gtk3 means gtk3, burn gtk2 flag, transition flags as appropriate" and discussing this further on @-dev?
+[21:20:29] <leio> I'm afraid we could see a gtk4 in a 2-3 year perspective, as they seem to want to base things on top of clutter at some point. That said, it seems gtk2 to gtk3 might be smoother conversion than gtk1 to gtk2 had been, to still give enough time to migrate things to gtk3 first with xfce/mate and so on jumping on.
+[21:20:42] <Tommy[D]> creffett: i think your suggestion looks ok, but i prefer a public discussion e.g. on -dev ML including the gnome team first, before we do a decision on that topic
+[21:20:49] <Pinkbyte> creffett, no objections
+[21:21:02] <creffett> Tommy[D]: well, we will say "we like this idea, please discuss further"
+[21:21:03] <wired> leio: one more reason to switch to a versioned use flag scheme then
+[21:21:04] * WilliamH prefers a discussion also
+[21:21:16] <wired> creffett: +1, discussion first
+[21:21:28] <Pinkbyte> leio, i doubt that when gtk4 will hit our door we will get rid from all of gtk2 stuff. And then - USE="gtk" will be even bigger mess
+[21:21:52] <Pinkbyte> user can set USE="gtk" and blindly got deps on gtk2/gtk3 or new gtk4. How is this can be good?
+[21:22:05] <TomWij> +1, discussion first
+[21:22:07] <Pinkbyte> i mean - in different apps, of course
+[21:22:14] <leio> because why the user should care which it is. He just wants a GUI
+[21:22:25] <creffett> leio: we're talking about Gentoo users here
+[21:22:30] <creffett> they care a lot more than "I want a GUI"
+[21:22:38] <Pinkbyte> leio, personally i know users who do not wants gtk3 on their systems entirely
+[21:22:51] <wired> what creffett said, this is gentoo, we care!
+[21:22:54] <creffett> but I digress; we have a majority, discussion to be continued on @-dev
+[21:23:02] <Pinkbyte> and when they are forced to use it, they patch ebuilds in local overlays until upstream drop gtk2 support completely
+[21:23:02] <creffett> wired: would you mind sending that email after we finish up here?
+[21:23:19] <wired> creffett: I'll do it yeah. may happen tomorrow tho, if that's not a problem :)
+[21:23:25] <creffett> wired: fine with me
+[21:23:32] <wired> great
+[21:23:43] <leio> please CC gnome@ specifically too, to be sure. Maybe Reply-To -dev then.
+[21:23:44] * wired notes it down
+[21:23:56] <creffett> are people okay for another 15-20 minutes (few more items to be discussed), or do we need to start wrapping up?
+[21:24:09] * WilliamH is ok 
+[21:24:12] <wired> I'm cool for at least another hour
+[21:24:14] * ulm fine
+[21:24:20] <Pinkbyte> leio, i know, progress can no be stopped, but we must give user a choice. If upstream supports gtk2 - we must also support it. If upstream drops gtk2 support - we drop it too. I do not see problems in this logic
+[21:24:40] <creffett> next item: Official recommendation for how to recommend optional RDEPs (relevant to bug 498832) https://bugs.gentoo.org/498832
+[21:24:41] <willikins> creffett: https://bugs.gentoo.org/498832 "sys-kernel/dracut: qa violation with regard to use flags and improvement with regard to best practices with patches"; Gentoo Linux, Applications; CONF; williamh:aidecoe
+[21:24:46] <Pinkbyte> creffett, i am good
+[21:25:04] <Pinkbyte> creffett, yeah, this is a big PITA
+[21:25:07] <creffett> mhm
+[21:25:19] <WilliamH> Well, the recommendation is elogs in postinst.
+[21:25:23] <Pinkbyte> i have some similar violation in one of my ebuilds too
+[21:25:28] <creffett> I've opened a bug to add an optfeature() function to eutils (reopened now that discussion on -dev petered out)
+[21:25:29] <WilliamH> That's in the devmanual.
+[21:25:54] <WilliamH> creffett: I like optfeature, but should we force it?
+[21:25:58] <creffett> which just adds some basic logic for only displaying if installed, handling some sets, etc.
+[21:26:04] <creffett> WilliamH: I'm thinking more "recommend"
+[21:26:15] <ulm> I think it is a step in the wrong direction
+[21:26:18] <creffett> WilliamH: people are free to use plain elogs if they like
+[21:26:30] <creffett> ulm: why's that?
+[21:26:35] <ulm> we should reduce the amount of things displayed in postinst messages, not encourage it
+[21:26:53] <ulm> so integrate it with readme.gentoo.eclass
+[21:27:27] <ulm> that way it's only displayed when the package is first installed
+[21:27:43] <WilliamH> ulm: you can also do that nowadays with
+[21:27:58] <creffett> ulm: but what about when the optional deps change? is that handled?
+[21:28:03] <WilliamH> ulm: if [[ -n $REPLACING_VERSIONS ]]; then ... fi
+[21:28:08] * creffett admittedly isn't super familiar with readme.gentoo
+[21:28:39] <wired> imo there are cases where using use flags is justified, but in this case it doesn't make sense. I would recommend adding optfeature() to some eclass and forcing devs to use it unless they have important reasons to go with the USE solution
+[21:28:43] <ulm> creffett: readme.gentoo allows forcing redisplay  if needed
+[21:28:56] <wired> until someone sits down and writes proper portage support for this anyway...
+[21:29:09] <creffett> wired: I'm not holding my breath on that one
+[21:29:10] <ulm> anyway, optfeature() is better than USE flags ;)
+[21:29:44] <creffett> ulm: I personally prefer optfeature, but since I'm the one who wants to introduce it, I'm aware that I'm opinionated
+[21:29:59] <WilliamH> creffett: does your version of optfeature have ansi codes in it? If it does that is evil. ;-)
+[21:30:06] <creffett> WilliamH: it does not
+[21:30:25] <WilliamH> creffett: ok good.
+[21:30:37] <creffett> for the moment, can we agree that using USE-deps for optional packages is bad (except in certain case-by-case circumstances)?
+[21:30:58] <ulm> WilliamH: I always wonder why somebody would hardcode ansi escapes
+[21:31:00] * WilliamH agrees
+[21:31:02] <wired> creffett: +1
+[21:31:04] <Pinkbyte> creffett, yep
+[21:31:15] <ulm> WilliamH: instead of using tput or proper curses functions
+[21:31:28] <ulm> creffett: +1
+[21:31:32] <creffett> okay
+[21:31:48] <TomWij> creffett: +1
+[21:31:49] <creffett> we probably should keep track of exceptions we've made, guess that could just go in the ebuild
+[21:32:03] <creffett> # Violates policy, but given QA approval because blah blah blah
+[21:32:13] <creffett> but that's a separate issue
+[21:32:33] <creffett> Tommy[D], zlogene: any input?
+[21:33:03] <Tommy[D]> general deprecation of USE-deps f or optional packages sounds fine with me
+[21:33:08] <wired> creffett: I'd watch the wording a bit, saying is bad is like saying "we don't like it, but meh". devs should not do it, period.
+[21:33:27] <creffett> okay
+[21:33:35] <zlogene> +1
+[21:33:45] <WilliamH> s/is bad/is not allowed/
+[21:33:49] <creffett> not on the agenda, but important: how do we want to communicate policy/policy changes made during meetings?
+[21:34:06] <ulm> so to clarify, the guide line is not to have USE flags for runtime dependencies that don't otherwise change the build of the package?
+[21:34:20] <WilliamH> ulm: yes.
+[21:34:22] <creffett> ulm: correct
+[21:34:25] <ulm> k
+[21:34:29] <Pinkbyte> creffett, well, probably some announcements on such important stuff are needed
+[21:34:39] <wired> gentoo-dev@, wiki, maybe a blog post on gentoo.org
+[21:34:44] <creffett> Pinkbyte: what do you think, -dev-announce? -proj? -dev?
+[21:34:48] <creffett> probably not -proj
+[21:34:55] <Pinkbyte> creffett, -dev AND -dev-announce
+[21:34:57] <wired> -dev-announce too yeah
+[21:35:12] <Pinkbyte> -proj is not for our technical mumbo-jumbo :-)
+[21:35:16] <creffett> wiki yes, I'll start a page to keep track of policies which don't belong in the devmanual
+[21:35:24] <Tommy[D]> announcements to -dev-announce and additional list is likely -dev since everything should be technical
+[21:35:25] <creffett> er, we have one already, I'll update it
+[21:35:26] <WilliamH> I think all devs are required to subscribe to -dev-announce, so it should go there.
+[21:35:34] <creffett> I believe you're right
+[21:35:53] <Tommy[D]> additionally having our policies documented in the project space of qa 
+[21:36:10] <creffett> mhm, and any which should go to devmanual should be added there as well
+[21:36:28] <creffett> (but since a lot of stuff is too specific for devmanual, like the gtk thing, we probably do need a separate place)
+[21:37:12] <creffett> I'll skip the "team projects" item, since we're running late; if you have ideas, https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Current_projects is the place
+[21:37:27] <creffett> last item: stable thread
+[21:37:37] <creffett> WilliamH: you're on, what do you want from the team exactly?
+[21:38:03] <WilliamH> This is a tough topic...
+[21:38:16] <WilliamH> I understand that the arch teams want to keep their arch's stable...
+[21:38:53] <WilliamH> But old packages kept in stable can become anissue, e.g. 
+[21:38:56] <creffett> WilliamH: how about we focus on "how to get more people arch testing"
+[21:38:57] * WilliamH is looking for a bug
+[21:39:21] <wired> IMO, the whole testing/stable process is rather outdated
+[21:39:26] <ulm> bug 498332
+[21:39:28] <willikins> ulm: https://bugs.gentoo.org/498332 "Dropping stable keywords on m68k, s390, sh"; Gentoo Linux, Keywording and Stabilization; CONF; dilfridge:council
+[21:39:28] <Pinkbyte> WilliamH, unless there is security issue or breakages - they are stable
+[21:39:44] <WilliamH> bug 497272
+[21:39:45] <willikins> WilliamH: https://bugs.gentoo.org/497272 "=net-misc/dhcpcd-5.6.4 fails to compile on ppc64"; Gentoo Linux, Applications; CONF; ago:williamh
+[21:39:50] <wired> I really have big plans for this but no time for now :(
+[21:40:03] <Pinkbyte> wired, what do you suggest? Offload stabilization for possibly unqualified users as TomWij suggests?
+[21:40:13] <wired> Pinkbyte: we need automation
+[21:40:41] <Pinkbyte> wired, true. But sometimes only one option to check if package is stable is manually run and do something with it
+[21:40:43] <WilliamH> the new glibc hit stable and broke old dhcpcd on that arch.
+[21:41:00] <TomWij> (+1 on -dev, -dev-announce [and perhaps a list to keep track of them on wiki, ...] for announcing)
+[21:41:08] <Pinkbyte> wired, for console utilities some unit tests can be pretty handy. But GUIs are a different story IMO
+[21:41:11] <wired> Pinkbyte: I agree. But in my mind the problem is far greater.
+[21:41:21] <Tommy[D]> if you just want "it compiles" level of stability, use a tinderbox and do auto-stabilization, but do we want that?
+[21:41:38] <WilliamH> My thing is this, I would say that we do need more people on arch testing.
+[21:41:40] <Pinkbyte> Tommy[D], i - definitely do not want that
+[21:41:46] <Pinkbyte> WilliamH, +1
+[21:42:00] <TomWij> Short run, we need more people.
+[21:42:02] <Tommy[D]> we cannot force people to work on arch teams
+[21:42:03] <Pinkbyte> more arch team members and arch testers
+[21:42:05] <WilliamH> I also think 90 days for an open stable req is plenty of time.
+[21:42:13] <WilliamH> If there are no blockers.
+[21:42:19] <TomWij> Long run, we need to evaluate whether we are progressing better; and take better decisions if we just get worse.
+[21:42:32] <WilliamH> My big complaint is stable reqs that sit there with no action from arch teams.
+[21:42:34] <Tommy[D]> we can only announce the need for more people, hope that more join and otherwise work out some policy how to reduce the amount of stable keywords for overloaded arch teams
+[21:42:37] <zlogene> as member of all arch teams: we have no power to test system packages (like openrc systemd and so on) at boot time 
+[21:43:12] <wired> Pinkbyte: what we really need is systems that do automated testing on everything. Imagine a system where everything goes through at least one automated build-test-run. That could be the entry barrier for a stabler "~testing" or "~current" tree. Then, you implement a system where users (and devs in general) can report whether a package has been stable for them for say, 30 days. Combine that with the successful auto-test-run and you can have stable packages. Of course, critical packages 
+[21:43:12] <TomWij> 'cause in the long run, if things tend to get even worse (growing queue); anything gets better than not doing anything at all.
+[21:43:25] <wired> but things atm are too manual
+[21:43:59] <Pinkbyte> wired, sounds pretty awesome. Like the upgraded infra boxes that exists now, but more accessible
+[21:44:10] <creffett> so how do we get more ATs (short term fix)
+[21:44:26] <creffett> I'm sure plenty of people have seen the requests
+[21:44:46] <creffett> maybe we can expand the existing AT-but-not-dev role/encourage non-devs to get into that?
+[21:44:55] * WilliamH thinks it should also be official policy that devs can stabilize themselves on architectures they have access to
+[21:45:06] <wired> Pinkbyte: combined with smart git repositories and a streamlined process, I believe it would like x100 our current project QA
+[21:45:21] <zlogene> <creffett>: we can get more testers for major arches, but what about minor arches? 
+[21:45:24] <wired> creffett: well, we can advertise, but this is a hard goal
+[21:45:32] <TomWij> creffett: Advertisement on the various Gentoo sites can increase visibility.
+[21:45:53] <creffett> zlogene: if we can't get enough people with that arch to help, then what's the point of keeping the arch stable?
+[21:45:53] <Pinkbyte> WilliamH, no, unless if they are know how to do it properly
+[21:45:58] <Tommy[D]> WilliamH: under the condition that they follow the arch team rules (e.g. full test on a fully stable system, running certain scripts as done by the arch team), i am fine with that
+[21:46:05] <Pinkbyte> WilliamH, and if they are - they are de-facto arch team members :-)
+[21:46:09] <creffett> zlogene: I'm not even sure if anyone uses HPPA besides rej, for example :P
+[21:46:11] <TomWij> cfr. The advertisements the StackExchange sites do at the right aside of their site.
+[21:46:25] <TomWij> s/cfr./see for reference/
+[21:46:33] <Pinkbyte> creffett, vapier probably still uses HPPA
+[21:46:45] <creffett> Pinkbyte: I was mostly joking
+[21:47:27] <Pinkbyte> WilliamH, more interesting question about degrading current unstable arches to fully unstable
+[21:47:30] <WilliamH> I also like Mike's suggestion on the ml.
+[21:47:45] <Tommy[D]> i suggest we decide for the case, where the arch team is overloaded and we need to reduce the amount of arch team work
+[21:47:49] <Pinkbyte> i was for it, but i read Mike's arguments and see how it's going inside s390 boxes
+[21:47:50] <WilliamH> about marking profiles "exp"
+[21:48:03] <Pinkbyte> ACCEPT_KEYWORDS="-~s390 s390"
+[21:48:04] <Pinkbyte> meh
+[21:48:06] <zlogene> <creffett>: for example i and ago have access to all arches in the tree (exclude unstable only and hppa), but i think armin and vapier will not happy if we will test systemd.openrc on main installation and then reboot the machine 
+[21:48:06] <WilliamH> and if all profiles are marked "exp" for an arch maintainers don'thave to care about it.
+[21:48:18] <Tommy[D]> everything else (how to improve automation, how to get more people into teams etc) are long term goals and cannot be simply fixed with a policy
+[21:48:19] * creffett has to run to class, back in 5-10, TomWij has the gavel while I'm out
+[21:49:14] <zlogene> btw, what about vapier? 
+[21:49:23] <Pinkbyte> WilliamH, well, exp means 'pretty broken' for me
+[21:49:25] <Tommy[D]> TomWij: you have the power now, quickly use it before its too late :)
+[21:49:46] <Pinkbyte> zlogene, and what's about him? :-)
+[21:50:08] <zlogene> <Pinkbyte>: look at perl changelog for example 
+[21:50:27] <Pinkbyte> zlogene, ah, you are about that little revert war with him :-)
+[21:51:05] <WilliamH> zlogene: heh, that's another issue.
+[21:51:29] <Tommy[D]> i suggest we only target the following question: "How to reduce the work of overloaded arch teams?" since everything else cannot be solved short term or via policy
+[21:51:32] <TomWij> Tommy[D]: Came up with a lot of suggestions and talking on that thread, I'm not really the person to take a decision I guess... :P
+[21:51:56] <Tommy[D]> TomWij: you did read my responses on that thread too?
+[21:52:02] <WilliamH> zlogene: I think we should wait for creffett  to come back, because there is another issue where vapier is doing something I want to talk about that is definitely outside of policy.
+[21:52:13] <TomWij> Read everything there, but would need to re-read to remember what it is about.
+[21:52:15] <Pinkbyte> Tommy[D], there was one solution, that was brought, and it is suitable for understaffed minor arches
+[21:52:25] <Pinkbyte> dropping keywords to unstable instead of stabilization
+[21:52:26] <wired> a summary of that hell-thread would be nice
+[21:52:32] <wired> haven't gotten around to reading it all
+[21:52:42] *** Quits: creffett (~creffett@gentoo/developer/creffett) (Ping timeout: 245 seconds)
+[21:52:58] <WilliamH> Yes, a summary of the stabilization thread would be nice.
+[21:53:34] <TomWij> Tommy[D]: But yes, a combination of increasing amount of arch teams (better PR, advertisements, occasionally announce people are needed, ...) as well as making the work more fit (more important first, etc...) should be a good start to make the queues less long.
+[21:53:39] <Tommy[D]> Pinkbyte: dropping keywords? My suggestion was to remove the last package for a stable arch, if that arch is not responding within 90 days, maybe working it out with maintainers of depending packages
+[21:53:52] <wired> Pinkbyte: dropping to ~testing for archs that just don't have the manpower sounds good to me
+[21:53:57] <wired> and we have to stop calling ~testing ~unstable
+[21:54:04] <wired> if anything, I'd rather call it ~current
+[21:54:21] <Pinkbyte> Tommy[D], dropping to ~arch of course
+[21:54:23] <Tommy[D]> ~testing is fine 
+[21:54:33] <wired> ~unstable sounds so freakin bad
+[21:54:43] <WilliamH> Tommy[D]: That's what I suggested at the start of the thread.
+[21:54:44] <zlogene> I'm already start to downgrade 
+[21:54:49] <Pinkbyte> but sometimes IIRC, armin76 drops keywords entirely(sparc, sh, s390)
+[21:54:51] <Tommy[D]> Pinkbyte: are you talking about keeping the previously stable package and dropping it from stable to testing?
+[21:55:22] <zlogene> but if vapier will revert our downgrade committs it no make sense then 
+[21:55:24] <Pinkbyte> Tommy[D], yep. Cause dropping package versions is usually up to maintainer, unless he said 'last arch - please drop old version'
+[21:55:25] <TomWij> wired: Yeah, ~unstable doesn't reflect reality; the packages are what upstream determines stable in the first place, for us it's unknown if they are known (un)stable so ~testing makes more sense.
+[21:55:30] <Tommy[D]> WilliamH: i know, discussion derailed somewhat, so i want to focus it again
+[21:56:29] <WilliamH> Tommy[D]: That's what lead to the discussion about omg no you can't drop remove a stable version because it will break our stable tree
+[21:56:34] <Tommy[D]> Pinkbyte: and i said "let the maintainer drop the package version with the last stable keyword for the unresponsive arch", qa should imho only make a policy and let the maintainers decide individually
+[21:56:45] <wired> TomWij: exactly. even ~testing is a bit out-of-place with the current state of stable. ~current is probably even closer to reality. but I'll start a -dev thread about that at some point :)
+[21:56:58] <WilliamH> s/drop //
+[21:57:38] <Tommy[D]> Pinkbyte: keep in mind that just doing s/stable/testing/ does not really make sense, since everyone with testing keywords will already use a newer version, so noone would use that version
+[21:57:39] <Pinkbyte> Tommy[D], i am still disagreeing with such sentence. Dropping keywords to unstable AND checking revdeps is fine for me in this case. Dropping entire old version is not
+[21:57:49] <TomWij> This discussion would be easier to follow if we split it up in sub topics. "stabilization" is a huge enough scope to mix up some topics.
+[21:58:02] *** Joins: creffett (~creffett@gentoo/developer/creffett)
+[21:58:02] *** ChanServ sets mode: +o creffett
+[21:58:15] <zlogene> <WilliamH>: just to clarify, next time, if you ask for system-important packages on minor arches, compile test is enough for you? 
+[21:58:21] <WilliamH> Pinkbyte: the thing is, that if a drop an old version to ~, I can then remove it.
+[21:58:39] <Tommy[D]> Pinkbyte: as i also wrote: if the stable tree breaks because of dropping, the maintainer should talk with maintainers of depending packages, so that they also drop their stable keywords/outdated versions
+[21:59:07] <Pinkbyte> Tommy[D], same as making it unstable.
+[21:59:10] * creffett back
+[21:59:36] <Pinkbyte> Tommy[D], do not get me wrong, you propose new similar solution, i - propose to restore old one, that worked somedays
+[21:59:46] <Pinkbyte> but was forgotten
+[21:59:52] <Tommy[D]> Pinkbyte: and when you make it testing, it is just the oldest version with testing keywords, so can be removed savely, so why not directly remove it?
+[22:00:15] * WilliamH agrees with Tommy[D] 
+[22:00:40] <Pinkbyte> Tommy[D], what's about maintainer wants two different versions in tree and disagrees about removing old one?
+[22:01:06] <Tommy[D]> Pinkbyte: restoring old ones is imho even worse since you will likely cause more trouble as those old, outdated packages dont support newer versions of their dependencies
+[22:01:14] <Pinkbyte> if old versions has no security, build-time or run-time issues - it is up to maintainer to decide keep it or drop it
+[22:01:22] <Pinkbyte> Tommy[D], ^^
+[22:02:18] <Tommy[D]> Pinkbyte: sure, if maintainer wants to keep more versions in the tree and will also support all of them, then i dont mind them dropping the stable keyword instead of removing the older version, but our policy should be "allow old versions to be removed"
+[22:02:24] <WilliamH> Pinkbyte: I think we are saying the same thing.
+[22:02:56] <WilliamH> Pinkbyte: it should be left up to the maintainer whether to keep or drop an old stable version if an arch teamhasn't responded to a stable request in 90 days.
+[22:03:06] <Pinkbyte> WilliamH, ah....
+[22:03:10] <Pinkbyte> i messed up, sorry
+[22:03:34] <Pinkbyte> i thought you are talking about other active arch team or qa member, but NOT about the maintainer
+[22:03:52] <WilliamH> Pinkbyte: the problem is, right now, it feels like arch teams can force maintainers to keep old versions around by not stabilizing new versions.
+[22:04:00] <Pinkbyte> then - fine by me
+[22:04:18] <Pinkbyte> WilliamH, yep, it's not good, i agree
+[22:05:20] <Tommy[D]> so as a summary "allow the maintainer to drop stable keyword or last stable version, if arch team does not respond within 90 days"?
+[22:05:32] <Pinkbyte> creffett, are you back? It seems that we are ready to vote on this. At least i see three +1
+[22:05:56] <TomWij> WilliamH: Well, that's another way to kill the queue; if arch team doesn't stabilize by time for a non-important package, drop to unstable (check rdeps) because the arch has failed to stabilize it in time. Only question that arises here is whether we need to inform the users and/or how?
+[22:06:03] <creffett> Pinkbyte: I am here, yes
+[22:06:23] <Tommy[D]> +if it breaks the dependency tree, then the maintainer has to work with maintainers of depending packages before dropping keyword/last stable version
+[22:06:43] <creffett> so are we voting on the two lines Tommy[D] just said?
+[22:07:06] <wired> +1
+[22:07:44] <creffett> if so, +1
+[22:07:52] <zlogene> +1
+[22:08:10] <TomWij> Tommy[D]: What happens if those reverse dependencies are also last stable? Just wait until all reverse dependencies have passed 90 days? What about important vs non-important packages? When this happens to importast (eg. system, important deps) we bring up unstabling the entire arch?
+[22:08:10] * WilliamH votes yes
+[22:08:11] <Tommy[D]> TomWij: i guess the user will be warned because of the installed version being keyword-masked, if that is true, that should imho be enough
+[22:08:45] <TomWij> (Tommy[D]: Yeah, just like an occasional mask does; should work fine, if there's a problem with that we can improve Portage's output)
+[22:09:00] <TomWij> s/importast/important/
+[22:09:13] <Tommy[D]> TomWij: well, since their dependency cannot be supported, the depending packages can be directly dropped to testing too, just should be done in advance to avoid a broken stable tree
+[22:09:15] <ulm> I'm not sure about the consequences this will have for users, so I abstain
+[22:09:25] <TomWij> +1 on Tommy[D]; the questions above don't block it, but address future concerns with it.
+[22:09:45] <creffett> Pinkbyte: your vote?
+[22:09:55] <Pinkbyte> creffett, as i said earlier - +1
+[22:09:59] <creffett> oh, missed that
+[22:10:06] <creffett> okay, passes 7-0, 1 abstaining
+[22:10:11] * creffett bangs his gavel
+[22:10:28] <Pinkbyte> ulm, differency from masking - users will not get message about why it's happened. Other things - ok
+[22:10:30] <creffett> open floor time, I believe
+[22:10:38] <creffett> WilliamH: you had concerns about vapier, I believe?
+[22:11:13] <WilliamH> heh
+[22:11:21] <ulm> Pinkbyte: yeah, it might be fine
+[22:11:24] <WilliamH> someone else, I think zlogene  did also...
+[22:11:48] <WilliamH> and the specific issue I'm thinking about is the multislot issue...
+[22:11:59] <Pinkbyte> creffett, my turn, before i fell asleep :-/
+[22:12:05] <creffett> Pinkbyte: okay
+[22:12:08] <Pinkbyte> WilliamH, yes! bug #174407
+[22:12:11] <willikins> Pinkbyte: https://bugs.gentoo.org/174407 "[Future EAPI] add support for USE-dynamic SLOTS"; Gentoo Hosted Projects, PMS/EAPI; CONF; vapier:pms-bugs
+[22:12:16] <WilliamH> zlogene brought up perl; I haven't really looked at it.
+[22:12:17] <Pinkbyte> i want to bring this here
+[22:12:33] <creffett> zlogene, WilliamH: I'll let Pinkbyte go first if that's okay
+[22:12:41] <creffett> Pinkbyte: so you want to bring up multislot?
+[22:12:52] <WilliamH> ok
+[22:12:55] <Pinkbyte> vapier did some nasty things(for good reasons, i believe), but he brokes metadata cache
+[22:13:30] <Pinkbyte> creffett, i am for removing multislot ebuilds to separate overlay for now. When proper use-dynamic slots will be implemented - we can return them
+[22:14:11] * creffett doesn't understand what the use of multislot is or why it's breaking things
+[22:14:20] <Pinkbyte> examples: autoconf, gcc
+[22:14:20] <ulm> SLOT should really be immutable, like PV
+[22:14:25] <ulm> only problem is that it's not part of the ebuild's file name ;)
+[22:14:40] <ulm> that would effectively stop all such games
+[22:14:50] <Pinkbyte> creffett, re-read metadata section of devmanual, please
+[22:15:17] <Pinkbyte> all parts of metadata cache can not depend on some condition and should be persistent on all arches
+[22:15:42] <creffett> and what is multislot used for?
+[22:15:50] <Pinkbyte> some users say that one of the reasons for portage degradation may be in this inconsistence. I doubt it, but it is not good at all
+[22:16:14] <WilliamH> creffett: http://devmanual.gentoo.org/general-concepts/portage-cache/index.html
+[22:16:20] <Pinkbyte> creffett, long story short - bring dynamic(${PV}) slots to package for wider testing by developers. Users usually do not need this feature
+[22:16:35] <Pinkbyte> creffett, for example, you will have 4.8.1, 4.8.2 and so on SLOTS for gcc
+[22:16:49] <ulm> Pinkbyte: it shouldn't have a large impact on portage performance, multislot was used for ages
+[22:17:05] <Pinkbyte> it's good for testing packages - it's mess for trivial upgrades
+[22:17:14] <Pinkbyte> very neat, yet testing configuration
+[22:17:23] <creffett> okay
+[22:17:24] <Pinkbyte> ulm, yep, i thought the same way
+[22:17:39] <Pinkbyte> but it is still a QA problem and we have to deal with it somehow
+[22:17:49] <creffett> Pinkbyte: so what you want is to ask toolchain to remove multislot until there's proper support in Portage?
+[22:18:09] <ulm> Pinkbyte: right, we do
+[22:18:16] <Pinkbyte> creffett, ulm suggest to move multislot ebuilds into separate overlay
+[22:18:53] <Pinkbyte> if multislot is only about toolchain(i do not really dig into this) - then probably direct into toolchain overlay. Otherwise - one more overlay should be created
+[22:19:00] <creffett> Pinkbyte: how much breakage could that cause for people using multislot?
+[22:19:13] <ulm> do we know if (and how much) the feature is used by users?
+[22:19:49] <ulm> if only our toolchain devs use it, then it should go to an overlay indeed
+[22:19:54] <WilliamH> ulm: no, we don't, I've never seen it discussed anywhere.
+[22:20:14] <ulm> sounds like a case for a forums poll
+[22:20:23] <Pinkbyte> creffett, do not get me wrong, ebuilds are fine in terms of syntax and probably work(do not test this myself). But metadata cache is unhappy with this situation. And some devs(read hasufell) really wants some decision from us
+[22:20:35] <Pinkbyte> "Do not care" is not an option, period
+[22:20:39] <creffett> okay
+[22:20:54] <creffett> forums poll if you want
+[22:21:21] <creffett> but I think the best option is to talk to toolchain about it, see if removing it will probably break things for anyone, and if no, newsitem and removal to overlay
+[22:21:28] <creffett> am I missing anything?
+[22:21:58] <Tommy[D]> and in case it breaks something or makes some workflow much harder?
+[22:22:24] <ulm> sounds good, and if more than a handful of users need it, then we can still reconsider
+[22:23:08] <creffett> Tommy[D]: then we can't really do anything until we have an EAPI that supports it and a toolchain which uses that EAPI
+[22:23:49] <Pinkbyte> Tommy[D], well, then we should calculate all slowdows/inconsistencies and errors that we have now because of that and weight if it worth it to fix this.
+[22:23:57] <creffett> but let's start out with determining how much is likely to break
+[22:24:09] <Tommy[D]> so first a forum poll to check the usage and contact toolchain to get their opinion, with that feedback i suggest we can base our decision on the next meeting
+[22:24:14] <creffett> sounds good
+[22:24:34] <creffett> can I get someone to handle the forums and someone to handle talking to toolchain?
+[22:24:37] <Pinkbyte> creffett, oh, and yes, other PMs(read paludis) are even more unhappy with that. ciaranm can say more, in bright words :-)
+[22:25:03] <creffett> Pinkbyte: I'm sure he has plenty to say, doesn't mean I want to hear them right now ;)
+[22:25:22] <wired> or ever :P
+[22:25:40] <creffett> well, that's a different issue
+[22:25:43] <wired> heheh
+[22:25:54] <creffett> ulm: I don't venture near the forums, you want to handle the forums poll?
+[22:26:29] <ulm> creffett: yeah, I can do
+[22:26:34] <creffett> ulm: thank you
+[22:26:39] <creffett> Pinkbyte: want to talk to toolchain?
+[22:27:27] <ulm> does anyone know if there is a good explanation of the feature somewhere, that I could copy and paste to the poll?
+[22:27:30] <Pinkbyte> creffett, sure, but it would be hard iirc. Not for me, mostly - for them. Cause usually vapier talks from them and he is... well i have baaad feeling about when he answered back(read 'nowhere')
+[22:27:55] <Pinkbyte> meh
+[22:28:01] <ulm> I fear it's documented nowhere :/
+[22:28:05] * WilliamH doesn't know of an explanation anywhere
+[22:28:07] <Pinkbyte> s/nowhere/never/
+[22:28:17] <creffett> Pinkbyte: I'd suggest you or someone familiar with the issue talk about it, just because I don't know enough about the issue to actually explain things well
+[22:28:26] * TomWij is making a summary of the meeting.
+[22:29:01] <creffett> TomWij: mind making it a separate page on the wiki? like proj:qa/meeting_agenda/meeting-jan-2014 or something
+[22:29:02] <Pinkbyte> creffett, ok, i will sent e-mail to toolchain tomorrow with CCing qa@ as usual
+[22:29:15] <creffett> Pinkbyte: thank you, I appreciate it
+[22:29:19] <creffett> you can go sleep now ;)
+[22:29:42] <TomWij> creffett: Currently a separate summaries page, we can split later.
+[22:29:45] <wired> ulm: I think it all ends up to the ability to dynamically switch between having all versions of a package slotable or not.
+[22:29:55] <TomWij> In any case, not mixed up with the agenda. :)
+[22:30:00] <creffett> TomWij: okay, good to me
+[22:30:09] <creffett> WilliamH, zlogene: you're on
+[22:30:22] * WilliamH defers to zlogene 
+[22:31:10] <ulm> wired: yeah
+[22:31:42] <ulm> looks like only gcc* binutils* autoconf* are using multislot
+[22:31:57] * zlogene lose question due to power issues :/ 
+[22:32:04] <wired> grub has USE="multislot" as well
+[22:32:11] <wired> ulm: ^^
+[22:32:16] <creffett> zlogene: the question was something like "did you have an issue with vapier you wanted ot bring up"
+[22:32:36] <ulm> wired: false positive, grub has fixed SLOTs
+[22:32:58] <creffett> I'm pretty sure multislot grub just renames things so you can have grub 1 and grub 2 in parallel or something
+[22:33:09] <WilliamH> zlogene: you were talking about dev-lang/perl I thought?
+[22:33:11] <ulm> creffett: right
+[22:33:24] <zlogene> ah. of course
+[22:33:46] <zlogene> yes, vapier still revert my commits for perl packages 
+[22:33:52] <wired> yeah. seems so. I think it used to do nastier stuff tho. doesn't matter now :)
+[22:33:58] <creffett> zlogene: what did he undo?
+[22:34:49] <WilliamH> The grub situation is that upstream considers grub legasy deprecated...
+[22:34:53] <WilliamH> iirc
+[22:34:54] <Tommy[D]> i guess commits dropping stable keywords for "his" arches
+[22:34:58] <zlogene> creffett: revert m68k/s390/sh 
+[22:35:06] <zlogene> to stable 
+[22:35:12] <creffett> zlogene: ah, right
+[22:35:25] <creffett> do we want to get involved, or do we want to wait on the council bug discussion?
+[22:36:11] <Tommy[D]> i suggest we wait until council did another review on their decision
+[22:36:12] <Pinkbyte> creffett, i think we should wait. If council decide to remain system@ subset in stable for those arches, it would be fine by me too.
+[22:36:24] <creffett> okay
+[22:36:35] <creffett> anyone object to waiting pending council reviewing?
+[22:36:46] * WilliamH does not
+[22:36:51] <zlogene> no 
+[22:36:54] <ulm> +1 for waiting until after next council meeting
+[22:37:20] <ulm> that should count as a "no" I guess ;)
+[22:37:24] <creffett> heh
+[22:37:44] <creffett> any other business?
+[22:38:15] <WilliamH> Well, maybe just a question...
+[22:38:16] <ulm> can we limit future meetings to two hours max?
+[22:38:21] <ulm> ;)
+[22:38:28] <wired> lol
+[22:38:37] <creffett> ulm: I don't object to that (I'm hoping most of them will go faster than this one)
+[22:38:39] <WilliamH> lol
+[22:38:40] <Tommy[D]> we currently are only at 125% :D
+[22:38:47] <zlogene> ulm:+1
+[22:38:48] <creffett> WilliamH: ask away
+[22:39:28] <wired> well we end up dealing with some important stuff here, we can deal with some overtime! :D
+[22:39:39] <Tommy[D]> but i am fine with a soft 2 hours limit with the option for a longer meeting, if all agree
+[22:39:39] <WilliamH> It sort of bugs me when someone responds like aidecoe did initially to the dracut bug...
+[22:40:07] <zlogene> looks like we forgot about megration from depcrecated EAPI 
+[22:40:09] <WilliamH> What is a polite way to tell someone, "I respect that you think you have a better way, but what you are doing violates policy so it has to be changed."
+[22:40:48] <creffett> WilliamH: that's pretty much the right thing to say imo
+[22:40:56] <WilliamH> creffett: ok.
+[22:40:58] <wired> indeed
+[22:41:07] <Pinkbyte> WilliamH, i think that your sentence contains as much respect as needed :-)
+[22:41:08] <creffett> zlogene: right.
+[22:41:13] <Tommy[D]> WilliamH: imho there is no general answer for every dev, imho you have to adjust your line depending on your target, also i did not spend too much time reading that specific bug
+[22:41:36] <WilliamH> Well, he is working with me now, so I think we can come up with something. :-)
+[22:41:46] <creffett> zlogene: problem is that I don't think we want to have the discussion of which EAPIs to ban and which to eprecate and stuff
+[22:41:57] <WilliamH> he seems more open to working with me on it than I first thought.
+[22:42:07] <WilliamH> So I think this will end up in a good situation.
+[22:43:02] * creffett likes ban 1/2, deprecate 0/3, but that's just me
+[22:43:07] <wired> you can always add something like "if you feel the policy can be improved, feel free to contact the QA team and discuss about it. for the time being though, please respect the policy the same way every other developer does" or something
+[22:43:15] <creffett> wired++
+[22:43:36] <Tommy[D]> WilliamH: i guess if some things get together (qa hat, clear wording as in "you violate polciy", language barrier and maybe some more), then the beginning of such conversation might be not that nice, but keep it going nicely and you can work with most people
+[22:43:58] <WilliamH> Tommy[D]: ok, cool. :-)
+[22:45:00] * creffett thinks we should make a note of ^^ discussion in the summary
+[22:45:03] <wired> so, shall we wrap this up? :)
+[22:45:18] <creffett> wired: sounds good to me, we can do EAPI banning/deprecation next time
+[22:45:25] <Pinkbyte> guys, i am not nagging, but can we move remaining questions(if any) to the next agenda. I think EAPI migration will continue without our urgent intervention.
+[22:45:44] <Pinkbyte> thanks x_O
+[22:46:07] <creffett> okay, meeting over.
+[22:46:09] <wired> awesome
+[22:46:09] * creffett bangs gavel
+[22:46:25] <wired> https://www.youtube.com/watch?v=TbEuMTOA3fo&t=3s
+[22:46:28] <wired> heheh
+[22:46:48] <wired> thank you guys, we really did go over a lot of things :)
+[22:46:54] <wired> ++
+[22:47:09] <WilliamH> Yes it was very productive. :-)
+[22:47:36] <zlogene> Must we public our logs or no?
+[22:47:43] <Tommy[D]> nice meeting and we got a good amount of topics done, so we can announce: qa is back, active and productive :)
+[22:48:01] <Pinkbyte> zlogene, creffett will do it later
+[22:48:04] <creffett> zlogene: we'll publish the meeting summary and probably throw the logs somewhere
+[22:48:05] <creffett> mhm
+[22:48:46] <zlogene> Okay 
+[22:49:03] <creffett> and I'll send a message to -dev and -dev-announce later with the summary of policy changes
+[22:49:30] * zlogene go in bed, definitely ^_^
+[22:49:45] <Tommy[D]> zlogene: good night :)
+[22:50:04] <wired> night!
+[22:50:20] <zlogene> <Tommy[D]>: thanks :)
+[22:52:46] <creffett> TomWij: let me know when you've got the summary in and I'll send an email
+[22:56:27] *** creffett changes topic to 'Welcome to #gentoo-qa | Next meeting: Wednesday, Feb 19, 1900 UTC | Gentoo QA mailing list: gentoo-qa@gentoo.org | http://devmanual.gentoo.org | The Treecleaner project needs you!  E-mail treecleaner@gentoo.org for info'