path: root/meeting-logs/20150113.txt

[20:02:02] <dilfridge> shall we start?
[20:02:02] <-> ulm_ heißt jetzt ulm
[20:02:18] <dilfridge> 1. Roll call (5 minutes)
[20:02:20] -*- dilfridge here
[20:02:24] <radhermit> here
[20:02:30] -*- rich0 here
[20:02:35] <dberkholz|mob> Here
[20:02:44] -*- WilliamH here
[20:03:12] <dilfridge> ulm, blueness?
[20:03:24] <blueness> here
[20:03:34] <ulm> just in time for the meeting I am having connection issues :(
[20:03:36] -*- ulm here
[20:03:43] <dilfridge> ok everyone's here!
[20:04:03] <dilfridge> 2. Discussion of GLEP39, "lame projects" / "lame project leads" (10 minutes)   http://thread.gmane.org/gmane.linux.gentoo.project/4169/focus=4170
[20:04:11] <dilfridge> rich0: your moment
[20:04:32] <rich0> Was that one mine?
[20:04:35] <radhermit> lame -> unresponsive I assume
[20:04:43] <dilfridge> err sorry
[20:04:49] <dilfridge> blueness: your moment :)
[20:05:02] <blueness> well
[20:05:02] -*- rich0 breathes a sign of relief
[20:05:32] <blueness> there was a lot of chatter on the list, but basically i wanted to see what the council thinks we ought to do with lame team leads
[20:06:07] <blueness> in particular toolchain.  it doesn't have a project page, i'm not sure whos lead, i think its vapier, but vapier isnt' very responsive
[20:06:29] <blueness> so i want to help with toolchains, but can't interact with its organization
[20:06:32] <WilliamH> blueness: if it doesn't have a project page it isn't really a project?
[20:06:39] <dilfridge> in this particular case it's even more complicated since it's no project (no page)...
[20:06:43] <blueness> no idea, it *is* a herd
[20:06:49] <WilliamH> blueness: I've seen toolchain as more a subproject of base-system.
[20:06:51] <dilfridge> and glep39 only talks about projects...
[20:07:08] <blueness> WilliamH, is it?
[20:07:15] <rich0> All of these issues are related.
[20:07:30] <WilliamH> Well, it is more like just a group of maintainers.
[20:07:36] <rich0> We have lots of loose associations of packages and devs with varying levels of formality, and varying levels of leadership/etc.
[20:07:37] <WilliamH> udev-bugs is similar.
[20:07:44] <blueness> glep 39 isn't so much about laying down the law as expectations
[20:08:02] <rich0> I'll agree with that.  I think there needs to be flexibility.
[20:08:14] <rich0> Also, I think that to some degree devs need to "be bold" in Wikipedia terms.
[20:08:28] <rich0> ie not wait around forever for an email response that will probably never come
[20:08:44] <WilliamH> rich0: I can agree with that... I have personally been cautious about that myself in ways, but you are right.
[20:08:48] <blueness> rich0, i think some boldness is needed too, but its really hard when you are naturally a "team player' not that i like that erm
[20:08:51] <blueness> term
[20:09:17] <dilfridge> the base system project page states that the base system project kinda maintains the toolchain, though it does not list toolchain as one of its herds
[20:09:23] <blueness> classic bug to illustrated the issue -> https://bugs.gentoo.org/show_bug.cgi?id=516988
[20:09:23] <radhermit> what exactly are you wanting to do here? rework/redo the toolchain eclass and need feedback?
[20:09:43] <-- dberkholz|mob (~AndChat19@gentoo/developer/dberkholz) hat das Netzwerk verlassen (Disconnected by services)
[20:10:23] <blueness> radhermit, no just get some toolchain stuff done, eg the next one is shooting for gcc 4.9.2 stabilizatoin
[20:10:40] --> dberkholz|mob (~AndChat19@gentoo/developer/dberkholz) hat #gentoo-council betreten
[20:10:48] <radhermit> so there really hasn't ever been a leader coordinating such things in recent history
[20:10:50] <WilliamH> blueness: imo if no one responds in a reasonable amount of time add yourself and go for it.
[20:11:05] <radhermit> just the main gcc maintainer at the time
[20:11:06] <rich0> Agree with the solution to the immediate problem.
[20:11:21] <WilliamH> radhermit: yes, it was mostly the gcc maintainer.
[20:11:21] <rich0> I think the real question is does this need fixing, and can it be fixed?
[20:11:39] <blueness> radhermit, in part just filling in the nitty griddy stuff with rhill being gone
[20:11:39] <WilliamH> rich0: I'm not sure there is anything to fix here.
[20:11:56] <rich0> IMO I think our options are limited.  If somebody doesn't want to actually step up and be a charismatic leader / etc, then at most we can just put barriers in the way of people who don't want to do that.
[20:12:01] <blueness> the toolchain eclass is there too, but i don't want to focuse on that
[20:12:09] <radhermit> basically someone needs to step up, and we can't really do anything as a council to effectively make that happen
[20:12:12] <dilfridge> that is a different porblem
[20:12:37] <dilfridge> the biggest problem is "trying to join a team, but there is noone who responds"
[20:12:45] <blueness> radhermit, i'm okay with coordinating it, but vapier is the technical wizard here
[20:12:52] <WilliamH> blueness: I say go for it; no one is stopping you from adding yourself.
[20:12:55] <rich0> yup, I don't think not having any toolchain team is better than having one with a non-responsive lead
[20:13:13] -*- dilfridge has some doubts about the wizard level since the botched dependency fixes
[20:14:01] <blueness> okay, so zorry and i spoke about this in pm and we'd like to start coordinating toolchain
[20:14:24] <blueness> so maybe i'll get a page up as a subproject of base system
[20:14:31] <radhermit> sounds fine to me
[20:14:31] <dilfridge> sounds good
[20:14:38] <WilliamH> blueness: nothing is stopping you from formalizing it into a project.
[20:14:44] <blueness> and then at least there'll be some point-of-contact
[20:15:14] <WilliamH> blueness: it doesn't have to be a subproject of base-system even imo that's up to you.
[20:15:22] <blueness> to be honest, i didn't care so much about games team or other teams being disorganized, but its worrisome when toolchain is this way
[20:15:37] <dilfridge> yes, but it's a repetitive problem
[20:15:52] <blueness> okay, i don't think we need a motion here or anything, i just wanted to bounce this off the council for feedback
[20:16:05] <rich0> toolchain, portage at times, sometimes infra.  There are a lot of overworked/understaffed/etc projects that are fairly core to the distro
[20:16:06] <dilfridge> maybe we should come up with a general idea how to solve it
[20:16:11] <radhermit> I think teams are disorganized in general, with organization being the rarity here
[20:16:16] <blueness> zorry and i had a similar situation with hardened back in the day when gengor + solar were fading away
[20:16:47] <rich0> To some extent it might reflect an attitude that these things are mature and don't need a lot of improvement
[20:16:48] <dilfridge> scarabeus seems to be missing in action, so office is only me right now...
[20:17:06] <ulm> isn't it straight forward? apply to join the project/team, and if there is no reply from project members for some time then you just add yourself
[20:17:11] <blueness> radhermit, if you see vapier in real life, just let him know what i'm up to.  and reassure him we (zorry and i) are only shooting for conservative commits
[20:17:28] <radhermit> sure, might see him tonight
[20:17:29] <dilfridge> ulm: that is exactly what I'd suggest to put somewhere in writing.
[20:18:04] <ulm> lead MIA can be handled in a similar way
[20:18:08] <radhermit> that's exactly what I've always done... other people are just too hesitant I guess :P
[20:18:13] <WilliamH> As someone told me, the lead of a project doesn't have to be the technical wizzard. The lead just coordinates the project.
[20:18:13] <rich0> Agree.  In general if the previous team is unresponsive, just step up and make a new one, etc.
[20:18:33] <rich0> WilliamH++
[20:18:46] <radhermit> really the technical wizard types should probably be doing work, not coordinating stuff
[20:19:21] <blueness> works for me
[20:19:26] <rich0> Agree.  We don't want people who are outright disruptive, but if somebody wants to quietly do their own thing and it is making Gentoo better, then we should get out of their way.
[20:19:32] <dilfridge> do we need / want a resolution?
[20:19:55] <blueness> dilfridge, i don't think we need a motion here
[20:20:06] <dilfridge> fine with me
[20:20:08] -*- WilliamH agrees with blueness 
[20:20:10] <dilfridge> anyone else?
[20:20:11] <rich0> I think we should try to send out a general mesage though.  It isn't about rules.
[20:20:20] <radhermit> "Ask if you can add yourself... after X amount of time with no response, add yourself."
[20:20:23] <radhermit> something like that
[20:20:26] <blueness> toolchain is important and i want to make sure the council is okay with trying to re-organize it
[20:20:28] <rich0> radhermit: ++
[20:20:35] <WilliamH> s/x/a reasonable/
[20:20:52] <rich0> And they can always escalate to council if there is conflict.  However, if it is person vs wall of silence, the person can just assume the answer is yes.
[20:21:01] <blueness> radhermit, i almost always agree with that statement, but i'm not so sure when it comes to the more demanding stuff
[20:21:08] <dberkholz|mob> +1 on that (self-adding w no response)
[20:21:19] <blueness> eg. i'm not sure if non-response about binutils should mean anyone gets to add binutils!
[20:21:26] <dberkholz|mob> Making that explicit if it's not yet would be a good thing
[20:21:30] <radhermit> blueness: if some random person starts breaking important stuff they'll get noticed ;)
[20:21:36] <blueness> true!
[20:21:40] <radhermit> and things will become less silent
[20:21:45] <blueness> yes yes
[20:21:47] <dilfridge> and qa wakes up
[20:21:49] <dilfridge> :)
[20:22:00] <blueness> actually the way i usually add toolchain stuff is keyword masked
[20:22:01] <rich0> radhermit: agree, right now I think we're erring on the side of too little risk, and not enough is getting done
[20:22:10] <blueness> so it can't break stuff right away
[20:22:19] <rich0> If things start breaking then we can deal with that problem
[20:22:21] <blueness> but its there for testing
[20:22:37] <dilfridge> ok I think we're all basically of the same opinion.
[20:22:50] <dilfridge> any completely different statements? if not, ...
[20:23:11] <blueness> good, so expect some toolchain stuff to be comeing from me and zorry, eg stabilization of gcc-4.9 etc
[20:23:21] <radhermit> sounds excellent
[20:23:36] <dilfridge> Next topic... 
[20:23:36] <dilfridge> 3. Policy for long-term package masks (10 minutes) http://thread.gmane.org/gmane.linux.gentoo.project/4169/focus=4198
[20:24:04] <WilliamH> Really what I was wanting was to get some folks to step up and update them or fix things.
[20:24:05] <dilfridge> dunno how much we need to talk there
[20:24:18] <WilliamH> and that is happening.
[20:24:31] <dberkholz> i would kinda prefer to see them move to overlays if they're gonna be long-term
[20:24:48] <radhermit> some issues relate to games that have bundled libs I'm assuming, kind of hard to fix that
[20:24:48] <dberkholz> and use p.mask for breakage
[20:24:49] -*- WilliamH tends to agree with dberkholz  to be honest
[20:25:09] <ulm> as long as a package is actively maintained, I don't have a problem with long-term masks
[20:25:31] <blueness> ulm, there is one example of where that might make sense
[20:25:32] <ulm> but we should avoid broken and unmaintained stuff sitting in the tree for years
[20:25:42] <WilliamH> is taviso still around ?
[20:25:44] <blueness> paxtest is a package which is *intentionally* broken
[20:25:47] <dilfridge> as long as there is a good description what the mask is for, I don't mind either (why? impact? duration?)
[20:25:51] <radhermit> taviso isn't around
[20:25:53] -*- WilliamH points to the very bottom of p.mask
[20:26:20] <radhermit> works on google security stuff atm iirc
[20:26:37] <WilliamH> radhermit: is he still an active gentoo maintainer?
[20:26:42] <dilfridge> in general masked packages are better gone, but there are valid reasons to keep them around
[20:26:45] <ulm> WilliamH: nethack? that was discussed on lists
[20:26:55] <ulm> broken by games policy
[20:27:11] <WilliamH> no
[20:27:12] <WilliamH> sorry
[20:27:16] <radhermit> WilliamH: he's not even a dev afaik
[20:27:17] <dberkholz> is he even an active gentoo dev? i don't think so
[20:27:20] <radhermit> retired him
[20:27:26] <WilliamH> bug 44351
[20:27:27] <dilfridge> # <klieber@gentoo.org> (01 Apr 2004)
[20:27:28] <dilfridge> yeah
[20:27:29] <willikins> WilliamH: https://bugs.gentoo.org/44351 "games-fps/unreal engine vulnerability"; Gentoo Security, Vulnerabilities; VERI, CANT; carlo:security
[20:28:07] <WilliamH> masked for 11 years now?
[20:28:20] <dilfridge> actually I wonder if this still runs
[20:28:26] <ulm> in addition these are cdrom installs, so nobody can check status
[20:28:49] <mgorny> is unreal free these days?
[20:28:56] <rich0> that was on the lists
[20:28:56] <ulm> such stuff should be removed, or moved to an overlay
[20:28:56] <rich0> yes
[20:29:10] -*- WilliamH agrees with ulm
[20:29:12] <rich0> I'm not convinced that games with issues like this can't be in the tree
[20:29:20] <blueness> i agree with ulm above, the key point is whteher its being actively maintained, not the masking
[20:29:21] <rich0> However, I think that should only be if they're maintained
[20:29:35] <rich0> if they're maintainer-wanted and nobody can even tell if they work, then I'm fine with treecleaning
[20:30:05] <rich0> Anything that isn't open-source should be treecleaned if not maintained - nobody can even vouch for whether it works
[20:30:16] <WilliamH> Is "This is a fun game so I think it should be kept" valid?
[20:30:24] <ulm> rich0: +1
[20:30:27] <ulm> it's a different story if there's a maintainer who can confirm that it still works
[20:30:44] <WilliamH> ;-)
[20:30:53] <a3li> just to be clear: something that works but puts users at risk is "maintained" by your definition?
[20:30:59] <dilfridge> WilliamH: imho not if there's a big security problem with it
[20:31:00] <rich0> a3li: yes
[20:31:10] <rich0> I'm fine with it being masked and in the tree.
[20:31:14] <rich0> Let the user make the choice
[20:31:19] <radhermit> solution: try last-riting stuff you want to remove and see who cares ;)
[20:31:38] <WilliamH> radhermit: I did, that's why we are talking about it.
[20:31:44] <rich0> I'm more concerned with it being unmaintained and untestable than it being insecure
[20:31:56] <dilfridge> a3li: what's the official security steam statement about keeping security-problematic packages in the tree masked?
[20:32:01] <rich0> security is a continuum, with risk up to to the user
[20:32:23] <a3li> dilfridge: practice has been to remove known vulnerable packages for years (n>5); only keep if needed for good reasons
[20:32:24] <dilfridge> a3li: (or how is it handled now, mostly?)
[20:32:29] <blueness> what about a package that simulates security risks as part of a test suite?
[20:32:35] <WilliamH> When I've had security bugs on packages I maintain I've been asked to remove vulmerable versions after the fixed one is stable.
[20:32:47] <dilfridge> blueness: that doesnt count imho, but it needs to be documented.
[20:32:50] <a3li> dilfridge: and statement: keep that policy.
[20:32:51] <rich0> WilliamH: sure, if there is a non-vulnerable version
[20:32:55] <blueness> dilfridge, it is
[20:33:04] <rich0> What if latest version is insecure, and this is unlikely to change?
[20:33:24] <blueness> paxtest intentionlly tries to execute code in the stack, bss, data etc to see if the pax kernel catches the problem
[20:33:27] <dilfridge> kick, kill, move to overlay
[20:33:29] <WilliamH> rich0: I disagree with you wrt keeping vulnerable software in the tree (qa hat firmly on)
[20:33:30] <dilfridge> ?!
[20:33:31] <ulm> rich0: remove, unless there are good reasons for keeping it
[20:34:01] <rich0> WilliamH: you're allowed to disagree, but I'm not changing my mind
[20:34:19] <dilfridge> ok
[20:34:20] <rich0> ulm: the good reason for keeping it is that it is useful
[20:34:36] -*- WilliamH disagrees
[20:35:10] <blueness> security depends on context, so let the user decide
[20:35:11] <rich0> WilliamH: everything you use has a security vulnerability.  They're just unknown at present.
[20:35:22] <ulm> on the list, there was the example of sys-block/afacli which depends on a package with security issues, but there is no alternative
[20:35:40] <dilfridge> "fun game" is in my opinion not a good reason
[20:35:52] -*- WilliamH agrees with dilfridge 
[20:35:54] <rich0> what is the alternative to unreal?
[20:35:58] <ulm> so if it was removed, users would still install it from elsewhere
[20:36:16] <rich0> ulm: agree
[20:36:22] <WilliamH> rich0: we aren't saying you can't use it, just that it belongs outside the main tree
[20:36:25] <dilfridge> ulm: true but not our problem, since we're not providing it
[20:36:29] <rich0> We're not making anything more secure.  We're just forcing everybody to stick things in overlays
[20:36:55] <WilliamH> rich0: we are cleaning up the main tree
[20:36:56] <rich0> WilliamH: you prefer an overlay with no security warnings to an in-tree package with them?
[20:37:07] <rich0> Why even have a main tree?
[20:37:14] <radhermit> imo, if we ever move to a more multi-repo centric approach then moving to repos makes sense, currently we're not really pushing that so it doesn't imo
[20:37:58] <dilfridge> rich0: but we're providing a maintainership / security / ... "guarantee" for the main tree, and for nothing else
[20:38:22] <rich0> dilfridge: we're not breaking that guarantee
[20:38:27] <rich0> We clearly disclose that the package is vulnerable
[20:38:35] <rich0> Which is more info than users would get otherwise
[20:39:20] <dilfridge> ok
[20:39:26] <blueness> we have control over the tree and so can assure quality there, but not with repos, so be careful about moving stuff to repos
[20:39:37] <dilfridge> this is not really going anywhere, we have different opinions
[20:39:48] <WilliamH> Should we vote on whether packages with security vulnerabilities shoulb be removed from the tree if there are no  fixed versions?
[20:39:52] <dilfridge> I'd propose a vote:
[20:40:33] <dilfridge> "may packages with security vulnerabilities remain in tree package-masked for indefinite time?"
[20:40:48] -*- WilliamH votes no
[20:40:51] -*- dilfridge no
[20:40:55] <rich0> I suggest rewording
[20:40:58] <radhermit> "assuming there are no replacements for them and they have maintainers"
[20:41:06] <radhermit> tack that on
[20:41:09] <dilfridge> ok, that is good
[20:41:10] <blueness> *active* maintainers
[20:41:16] <rich0> "May maintained packages with security vulnerabilities remain in tree package-masked for indefinite time?"
[20:41:29] <dilfridge> "may packages with security vulnerabilities remain in tree package-masked for indefinite time, assuming there are no replacements for them and they have active maintainers?"
[20:41:46] -*- dilfridge votes still no
[20:41:51] -*- ulm votes yes
[20:41:54] -*- blueness yes
[20:41:55] <radhermit> yes
[20:42:11] <WilliamH> Assuming above, yes.
[20:42:42] <dilfridge> dberkholz: rich0?
[20:42:47] <WilliamH> Now my question to the council is, is "games" an active maintainer? I would assume no.
[20:42:55] <rich0> or radhermit's suggestion
[20:43:02] <rich0> dilfridge: what?
[20:43:08] <rich0> lag
[20:43:12] -*- rich0 yes
[20:43:58] <WilliamH> Actually, one more thing.
[20:44:01] <dilfridge> WilliamH: given that I see activity by Mr_Bones updating EAPIs, I would say yes.
[20:44:41] <WilliamH> looking again at the  mask I cited,
[20:44:55] <WilliamH> the mask was put there by kleiber and has never been touched.
[20:45:03] <radhermit> WilliamH: plenty of the games are probably rotting and could be last-rited if Mr_Bones or whoever doesn't step up say they're still maintained
[20:45:10] <WilliamH> so from that pov, kleiber did the masking.
[20:45:23] <radhermit> I'm sure he doesn't care about every single game some random dev has added with "games" as the herd and then retired after a few years
[20:45:42] <WilliamH> radhermit: right.
[20:45:55] <blueness> when we're done voting, can we have a followup on the resolution
[20:46:05] <WilliamH> He hasn't stepped up wrt the last rites I posted.
[20:46:06] <dberkholz> i'd vote no
[20:46:13] <blueness> i think we should add a few comments if we email this decision out
[20:46:14] <dberkholz> overlays are fine
[20:46:27] <dberkholz> (bad connectivity in here, sorry)
[20:46:37] <radhermit> WilliamH: so CC games/him and wipe them later?
[20:46:42] <WilliamH> I would add a qualification...
[20:47:26] <WilliamH> radhermit: why cc games? it was put on g-d-a and dev
[20:47:32] <dilfridge> ok that means 2x no, 5x yes, motion passed
[20:47:47] <radhermit> WilliamH: I dunno, you were sounding hesitant
[20:48:04] <blueness> dilfridge, okay now that we have a yes vote, i think we should also strongly recommend the maintainer communicate the issue to the user
[20:48:16] <dilfridge> yes
[20:48:18] <WilliamH> But I think we should be able to push the maintainer to get a fixed version in the tree and remove the old ones.
[20:48:26] <blueness> say in a pkg_postint say
[20:48:39] <blueness> there should be some mitigation of the risk
[20:48:53] <radhermit> how much stronger can you get than a mask stating the vulnerability?
[20:48:55] <blueness> eg. if you want to play nethack, do it in a sandbox
[20:48:58] <WilliamH> blueness: if you do that with pkg_postinst it doesn't belong in p.mask.
[20:49:19] <blueness> sorry your right
[20:49:23] <WilliamH> p.mask is  not permanent.
[20:49:24] <blueness> it does say pmasked
[20:49:33] <blueness> but then we should have the info in the pmask comment
[20:49:43] <radhermit> if/when people unmask stuff, they should know what they're getting into
[20:49:44] <blueness> s/info/warning/
[20:49:57] <radhermit> yes, as long as there's info
[20:50:01] <WilliamH> If we are going to allow security vulnerable packages to stay in the tree they don't belong in p.mask, use postinst msgs
[20:50:22] <dilfridge> isn't that exactly what the mask message is for?
[20:50:25] <radhermit> yes
[20:50:28] <WilliamH> p.mask is for things that can be fixed.
[20:50:29] <blueness> radhermit, i'm good, it just slipped my mind that p.mask has that comment when you try to emerge
[20:51:00] <radhermit> p.mask is for masking things, full stop
[20:51:10] <WilliamH> I was always taught that p.mask is never permanent.
[20:51:41] <dilfridge> ok
[20:51:53] <dilfridge> do we want to make another vote / motion?
[20:52:08] <creffett|irssi> just to chime in as a security type: which makes more sense, a big warning that says "security issues, unmask at your own risk" or an easily-ignored postinst?
[20:52:09] <blueness> dilfridge, for the warning?
[20:52:41] <dilfridge> "the security issue must be documented in the mask message, with bug number"
[20:52:48] <radhermit> sounds fine
[20:52:56] -*- blueness yes
[20:53:05] -*- rich0 yes
[20:53:07] -*- dilfridge yes
[20:53:13] -*- radhermit yes
[20:53:39] -*- ulm yes
[20:53:41] <dberkholz> of course..
[20:53:54] <dilfridge> k
[20:54:00] <dilfridge> anything else to say here?
[20:54:31] <dilfridge> seems not
[20:54:32] <WilliamH> I se this as an abuse of p.mask to be honest.
[20:54:39] <blueness> (ab)use
[20:55:27] <dilfridge> 4. Open bugs with council involvement (5 minutes)
[20:55:27] <radhermit> and I wish all games released source code after X number of years
[20:55:28] <blueness> WilliamH, it really does depend if this just becomes an easy way around trying to fix something or a last resort
[20:55:39] <WilliamH> http://devmanual.gentoo.org/profiles/package.mask/index.html
[20:56:27] <dilfridge> blueness: indeed. so let's start lastriting ancient stuff and see what happens.
[20:56:30] <dilfridge> anyway
[20:56:32] <dilfridge> 4. Open bugs with council involvement (5 minutes)
[20:56:38] <dilfridge> bug 523828
[20:56:40] <willikins> dilfridge: https://bugs.gentoo.org/523828 "GLEP 42 update: Unify gentoo-news repo and rsync structure"; Doc Other, GLEP Changes; CONF; mgorny:glep
[20:56:49] <dilfridge> any news here?
[20:57:19] <WilliamH> dilfridge: I agree with you, let's start getting rid of ancient stuff.
[20:57:40] <dilfridge> since we decided about it last time, maybe we should just un-cc council and leave the execution to, well, some able executioners?
[20:57:58] <ulm> someone should update that glep
[20:58:22] <dilfridge> the generation code is more critical
[20:58:42] <ulm> it's a trivial change
[20:59:02] <dilfridge> yes but someone needs to do it. wink, wink, wink...
[20:59:27] <ulm> the proponent? :)
[20:59:34] <dilfridge> ok seems nothing to do here. 
[20:59:44] <dilfridge> bug 503382
[20:59:49] <willikins> dilfridge: https://bugs.gentoo.org/503382 "Missing summaries for 20131210, 20140114, and 20140225 council meetings"; Doc Other, Project-specific documentation; CONF; ulm:council
[20:59:59] <dilfridge> well, nothing to do here either. just move along please.
[21:00:15] <dilfridge> 5. Open floor
[21:00:18] <dilfridge> anyone?
[21:00:40] <WilliamH> Well, I'll just comment.
[21:00:55] <WilliamH> Today's debate is a good example of why devs find it hard to be bold and do things.
[21:01:05] <WilliamH> *sigh*
[21:02:12] <blueness> i'm not sure bold/courage is the right issue, its more respect
[21:02:20] <blueness> and coordinating with other devs
[21:02:32] <radhermit> about masks? I still don't see what the issue is about removing ones if no one cares enough to respond for certain pkgs.
[21:03:02] <radhermit> that's what last rites are partially for, questioning maintainership
[21:03:21] <WilliamH> I need to go through the thread again, but I believe I saw someone say that "x is a fun game, so this should be kept in the tree regardless of the risk" a couple of times.
[21:03:49] <rich0> WilliamH: if it were maintained I'd agree with them
[21:03:51] <radhermit> if they didn't want to step up and maintain it... too bad I'd say
[21:03:53] <dilfridge> WilliamH: noone prevents you from starting last rites, and if "someone" doesnt volunteer to maintain it, then "someone" doesn't really count
[21:03:58] <WilliamH> I also saw one that was "Now there is a new version of x that is gpl'd, but we should keep both."
[21:04:06] <rich0> dilfridge: ++
[21:04:26] <rich0> WilliamH: might be worth exploring the reasoning behind such a statement in the latter example
[21:04:41] <rich0> In general though I'm more about informing users than making choices for them
[21:05:02] --> keytoaster (~tobias@gentoo/developer/keytoaster) hat #gentoo-council betreten
[21:05:06] <rich0> Stuff that is just broken or which we can't be sure if it is broken or not, that is a different story.  There is no value to having ebuilds in the tree that don't even build
[21:05:13] <dilfridge> ++
[21:05:21] <dberkholz> are you arguing that insecure software isn't broken?
[21:05:26] <WilliamH> The justification was pretty weak, just like the argument we had a while back about keeping module-init-utils.
[21:05:48] -*- WilliamH thinks insecure software is dangerously broken
[21:06:01] <radhermit> insecure software that you aren't able to fix but have to use is broken in a special way :)
[21:06:26] <dilfridge> and with these words, it's about time... I dont think this further discussion is going anywhere.
[21:06:37] <dilfridge> new arguments next month please.
[21:06:46] <WilliamH> What about the "gentoo is about choice" argument?
[21:06:47] -*- dilfridge bangs the gavel
[21:07:01] <dilfridge> session closed