path: root/meeting-logs/20141111.txt

<rich0> ok, let's do roll call. :)
-*- creffett|irssi currently holds the title of "person who has been on the council most without actually being elected to the council"
-*- ulm here
-*- WilliamH here
-*- creffett|irssi here as proxy
<rich0> I think we're all here.
<dberkholz|mob> Hi
<dberkholz|mob> (For roll call)
<rich0> Ok, hopefully a lighter day today.  First topic
<rich0> Should/may maintainers close bugs that have tinderbox logs passed by URL without being attached?
<rich0> (or something to that effect)
<dberkholz|mob> Nope
<rich0> Hopefully this will become somewhat moot as there is an effort to go in and add the attachments after-the-fact.
<creffett|irssi> seems to be largely solved by attachment-adding scripting that people are doing
-*- WilliamH agrees with rich0 
-*- dilfridge here
<creffett|irssi> but as a general question, I'm with dberkholz|mob on this
<ulm> no council action required IMO
<rich0> However, I'm generally not a fan of marking bugs INVALID simply for syntax.
<rich0> If necessary info is missing that is one thing.  If we don't like how it was done, then fix it.
<rich0> Do we want to issue a recommendation that bugs not be marked invalid simply due to the way logs are linked vs attached?
<blueness> leave it at that
<ulm> that shouldn't become general policy
<dilfridge> no
<ulm> we could grant an exception for the tinderbox
<rich0> The alternative is to say the issue is moot and move on.
<ulm> but that does not set a precedent
<dberkholz|mob> Don't let process win over fixing bugs
<dilfridge> we could say that it's bugwrangler team decision
<rich0> In general though I think everybody could afford to be a bit more flexible in this case.
<WilliamH> How about this:
<rich0> I think it is bigger than bugwranglers.  There is the balance in encouraging tinderboxing (albeit with some limitations) vs reducing the effort to handle bugs.
<rich0> If we had 47 people doing tinderboxing then I'd say we could be picky about how they do it.
<rich0> WilliamH: ?
<WilliamH> The council recommends that bugs from the tinderbox not be marked invalid based on whether the logs are attached or pointed to by a URL.
<rich0> How about a two part: "The council recommends that bugs from the tinderbox not be marked invalid based on whether the logs are attached or pointed to by a URL.  The council also encourages efforts to automate the attachment of tinderbox logs to improve the quality of the bugzilla record."
<dilfridge> s/the tinderbox/any developer-run tinderbox/
<rich0> dilfridge: ++
<blueness> that's fine
<ulm> rich0: s/URL/permanent URL/
<ulm> no pastebins
<rich0> "The council recommends that bugs from any developer-run tinderbox not be marked invalid based on whether the logs are attached or pointed to by a permanent URL.  The council also encourages efforts to automate the attachment of tinderbox logs to improve the quality of the bugzilla record."
<dilfridge> ++
<rich0> Of course, no URL is truly permanent.
<rich0> But I get the gist.
<ulm> rich0: yeah, it's about the intention
<ulm> otherwise, +1
<rich0> Any other tweaks before we vote?
<rich0> Ok, let's vote.
-*- rich0 yes
-*- blueness yes
-*- ulm yes
-*- WilliamH yes
-*- creffett|irssi yes
-*- dilfridge yes
<rich0> dberkholz?
<dberkholz|mob> Yes
<rich0> ok, 7-0
<rich0> next topic
<rich0> Future.eclass
<rich0> http://thread.gmane.org/gmane.linux.gentoo.devel/93609
<WilliamH> kill it with fire
<rich0> It feels like the whole spam form letter - will make things better for two months and then we're stuck with it.  :)
<dilfridge> please no
<ulm> I don't see what problem this would solve, and it potentially adds confusion
<creffett|irssi> my notes say that I should vote NAK
<dilfridge> this is not a good idea... helping with specs writing is way better
<creffett|irssi> and I agree with that
<rich0> I get the utility factor.  I'm all for utility eclasses in generall, but not for things imminently to be fixed by EAPI
<rich0> Any contrary opinions?
<creffett|irssi> it basically splits us into EAPI 5.5 (5+future.eclass) and EAPI 6 (properly implemented in package managers)
<dilfridge> fuuuuu
<ulm> features should be either in an eclass or in the PM, not both
<ulm> if something turns out to live better in an eclass then we should remove the feature from the EAPI 6 list again
<blueness> yeah i don't get this, why can we just get EAPI 6 out?
<dilfridge> :)
<ulm> blueness: I hope that the spec will be ready before xmas
<rich0> Ok, how about "The council does not agree with the concept behind future.eclass as it has the potential for confusion.  Efforts would be better focused on preparing for EAPI6 and adopting this."
<dilfridge> sounds good
<blueness> yes
<ulm> +1
-*- WilliamH yes
<rich0> ok, vote
-*- rich0 yes
<creffett|irssi> yes
-*- ulm yes
-*- WilliamH yes
-*- dilfridge yes
<rich0> dberkholz|mob: ?
<dberkholz|mob> Abstain
<blueness> yes
<rich0> Ok, 6-0 with one abstention
<rich0> Next: Allowing die within subshells in EAPI6
<creffett|irssi> radhermit says "should be discussed more on the lists"
<rich0> My comment is already in the agenda.  By all means we can share thoughts but I recommend deferring actual voting until it is discussed on-list.
<ulm> I'd like to first see it solved technically
<rich0> Maybe we don't even have to vote on it at all if it reaches consensus there.
<ulm> doesn't make sense to allow die in subshells if it doesn't work reliably
<dilfridge> I have absolutely no clue about the background. What is it supposed to do when called in a subshell? die or return?
<ulm> dilfridge: per PMS it's undefined
<floppym> Currently portage dies at the end of the current phase I beleive.
<dilfridge> and paludis ignores it? :P
<ulm> in principle it should die, but then the PM would have to kill the process tree
<rich0> Short of moving to a language with better exception-handling than bash, I'm not sure we have great options here anyway.
<ulm> not sure if that can be done in a sane way
<dilfridge> ulm: it could probably with cgroups, but...
<rich0> systemd-emerge? 
<dilfridge> oh dear
<ulm> dilfridge: yeah, that would open a new can of worms :)
<WilliamH> heh
<WilliamH> cgroups != systemd
<blueness> ulm, how is this die in a subshell supposed to work?  does it do it by return value or by some sort of signal?
<rich0> WilliamH: I know.  couldn't resist.  :)
<dilfridge> FEATURES=cgroup Use  Linux  control  group  to control processes spawned by ebuilds. This allows emerge to safely kill all subprocesses...
<ulm> blueness: no idea, I haven't seen a working implementation so far
<dilfridge> ^ man make.conf
<blueness> ulm, well who came up with the idea?
<WilliamH> I guess the disadvantage of cgroups is it is Linux specific.
<ulm> blueness: mgorny
<floppym> mgorny's eclasses abuse it, by accident.
<blueness> floppym, i'd like to see this, but later
<blueness> the only sane way i can see is by getting a signal to the portage parent
<floppym> Well, portage currently does some IPC magic that I'm unfamiliar with.
<mgorny> well, it's something that definitely can be solved technically
<rich0> kdbus to the rescue...
<blueness> i don't feel comfortable voting on something that i don't understand
<WilliamH> me neither
<blueness> mgorny, i'd like to see poc
<dilfridge> this should go to the lists first
<rich0> we're not going to vote on anything unless somebody feels strongly about it
<mgorny> poc? portage has it working already
<rich0> But, whoever cares can read our logs.  :)
<ulm> can we defer it to mailing lists please?
<mgorny> i'm not saying the impl is perfect
<mgorny> but it works
<ulm> sounds like a topic for gentoo-pms
<blueness> mgorny, then show me
<blueness> say look at the code here and here and here
<mgorny> blueness: didn't any python-r1 ebuild fail for you? :P
<blueness> please just point out the cod
<rich0> ulm: ++ - the poc is good but I'd like portage and other PM input on it.
<mgorny> portage code is not worth showing :P
<blueness> on the list we can talk later
<mgorny> but the idea can be relatively simple
<rich0> Ok, anything else worth discussing here now?
<WilliamH> Yeah let's defer this to the lists for now
<mgorny> like passing the parent PID and SIGTERM-ing on it from die
<blueness> mgorny, let's see it in the lists
<mgorny> it's just plain IPC
<blueness> simple enough that you can show it :)
<mgorny> there's the problem of killing orphans but then, the problem was always there
<creffett|irssi> mgorny: enough, to the lists with you :P
<blueness> indeed!
<ulm> mgorny: it doesn't work in 100% of cases
<mgorny> what doesn't work?
<ulm> killing all subprocesses
<rich0> We can implement this when we implement separate namespaces for emerge.  :)
<mgorny> and it will never work in 100% of cases
<rich0> Then you just kill -9 -1 :)
<mgorny> die in a subshell, processes left in ebuild phases...
<mgorny> src_compile() { setsid foo; die; }
<rich0> Ok, to the lists with this.  We can always chat after the meeting or in AOB.  
<rich0> Likely to end early
<blueness> thank you
<rich0> Next topic.  :)
<rich0> Deprecating and killing the concept of herds - any follow-up here?  I suggest we defer again since we didn't really get too far with it on the lists.
<WilliamH> Yeah I don't think there is much for us to do here yet
<ulm> +1 for deferring to lists
<mgorny> ...
*** Mode #gentoo-council +o dberkholz|mob by ChanServ
<rich0> I did send a proposal, but we need to actually get something ready to go before we go ahead with it.
-*- mgorny mumbles something about death of gentoo :P
<dberkholz|mob> Sigh.
<mgorny> rich0: btw i liked your proposal
<mgorny> didn't reply because didn't have any comments
<blueness> rich0, i think the council needs to have a deprecation scheme spelled out
<ulm> mgorny: because of herds? that's a tiny problem we have
<mgorny> yes, we have many big problems nobody bothers to solve
<blueness> what happens to the current herd info
<rich0> mgorny: thanks.  Probalby makes sense to maybe proof-of-concept it by running some queries/etc and posting lists of packages/etc.
<mgorny> we have small problems nobody bothers to solve because they're small
<rich0> blueness: I did cover that somewhat in my proposal.  I think gathering some data might help with decisions there.  I don't mind talking about my proposal further or others, but I don't think we're ready to pull the trigger this second.
<rich0> There is no reason that we can't compile the necessary data now.
<blueness> rich0, i know much of this was discussed, but its scattered (at least in my mind now)
<blueness> so maybe a summary for the cuoncil meeting when it comes
<blueness> that'll reduce discussion at that time
<rich0> blueness: http://permalink.gmane.org/gmane.linux.gentoo.devel/93587
<rich0> Agree
<blueness> ty
<rich0> Let's do a bit more with it and discuss next time.
<rich0> Anything else on this?
<rich0> Ok, Status of Games Team - anything worth talking about here?
<creffett|irssi> radhermit mentioned that vapier said people are free to join the herd if they want
-*- WilliamH has seen absolutely no movement on this
<WilliamH> creffett|irssi: ok, I didn't know about that.
<creffett|irssi> and apparently didn't mention anything re games.eclass
<rich0> We already decided that anybody can maintain a package without games.eclass if they want to.
<WilliamH> Who is the lead -- I thought it was radhermit?
<rich0> Maintainers get last word on whether their package goes in the herd.
<rich0> WilliamH: I believe so
<ulm> WilliamH: they haven't had a new election yet, AFAIK
<rich0> Without radhermit I'm not sure we'll get much farther with this.
<WilliamH> Right.
<ulm> so radhermit would still be interim lead
<dilfridge> to be honest, this is not so important anymore (since anyone can add games, and since games don't have to stick to games team policies)
<rich0> Obviously fixing the games team requires folks to step up, but there are no roadblocks so again not super-urgent.
<rich0> dilfridge: ++
<dilfridge> so if anyone wants to join games team, fine, if not, also fine
<blueness> the original issue, especially revolving around multilib, seems to be resolved
<blueness> its not blocking anything urget
<blueness> so maybe just announce open season on games and let people who want join
<mgorny> the remaining issues were supposed to be solved via QA
<mgorny> which brings us to the topic of whether QA works :P
<blueness> if nothinghappens, then let it die of its own accord
<mgorny> because *nobody* replied to my mail yet
<blueness> who is QA lead?
<creffett|irssi> blueness: hi
<blueness> i thought so
<dilfridge> so how about we just let the topic (on the council side) rest and have sleeping beauty^H^H^H^H^H^Hgames team rest in the corner?
<blueness> so creffett|irssi is QA malfunctioning?
-*- creffett|irssi sighs
<mgorny> (sent 12 Oct)
<rich0> dilfridge: I'm fine with dropping this until somebody asks us to pick it up again.
<creffett|irssi> blueness: not so much malfunctioning, but nobody is stepping up to do anything lately, and I don't exactly have the motivation to nudge people constantly to do stuff
<mgorny> i don't mind lack of specific work but some discussion would be helpful
<ulm> creffett|irssi: maybe we should have qa team meetings? :)
<mgorny> otherwise, it's like i declare games.eclass bad because nobody else from QA replied
<mgorny> and it doesn't seem right to create policies this way
<creffett|irssi> ulm: I'l leave that discussion for another time
<rich0> Do we want to put out a call for volunteers for games/QA?
<blueness> mgorny, suppose you are right and games.eclass is bad, how bad is it to just leave it for now ... this is not a rhetorical question, its is breaking anything seriously?
<creffett|irssi> games yes, though we've done several of those so far I thought
<mgorny> at the point, i think not anymoer
<mgorny> though lack of consistency is bad
<mgorny> confuses users
<blueness> mgorny, i understand but since QA is overworked, you may have to choose your battles
<creffett|irssi> blueness: it's not overworked
<creffett|irssi> it's underperforming
<rich0> I'm hesitant to rip off the bandaid until somebody actually steps up and wants to do something serious with games.
<mgorny> like when we have stuff installed in /usr/lib, /usr/lib/games and /usr/games/lib
<mgorny> (the last one being gentoo invention)
<blueness> mgorny, yeah that seems to be the second QA issue (after the multilib problems)
<ulm> mgorny: follow the fhs when in doubt
<rich0> If somebody really cares about improving games I'd like them to step up, rather than us just coming in with a club and bashing a few things.
<rich0> QA is no different - somebody has to step up and care.  :)
<mgorny> the problem with improving stuff is that many of the games are simply old ebuilds that nobody has distfiles for...
<dilfridge> well, joining a team requires you to work with other people...
<blueness> can't QA just cull a bunch of those ancient ebuilds?
<mgorny> of course, we could just overcommit them all with removing the eclass for the sake of consistency
<blueness> mask them en masse and be done with?
<mgorny> but that looks like a request for revert
<creffett|irssi> blueness: I'd like somewhere to dump all of them
<blueness> a repo
<dilfridge> how about we write a tool that generates statistics on installation numbers?
-*- dilfridge runs and hides
<mgorny> inject a trojan into portage
<mgorny> also make it open ssh access for us to do more research when necessary
<blueness> here's what i recommend, let's put a final call out for games herd
<dilfridge> but seriously, how about having an official overlay for games where the files are not publically available?
<creffett|irssi> ++
<ulm> dilfridge: doesn't pfl do that?
<rich0> I think that it isn't too much for QA to ask that any package that doesn't have freely-accessible DISTFILES be actively maintained by a named individual 
<blueness> if the falters, then i recommend we ask QA to just deal with the problem in any way they see fit, like mosking and dumping a bunch of ebuilds ot an overlay
<rich0> Somebody should have to vouch that they actually work.  I'm happy to take somebody's word for it.
<rich0> However, right now we just have what might be a lot of cruft.
<creffett|irssi> yes
<mgorny> dilfridge: that doesn't solve the issue, just shove it under the carpet
<creffett|irssi> I'd suggest we say "here's a list of no-distfiles games with no maintainer, speak up and say that it works/offer to help or we punt them to overlay"
<blueness> rich0, the question is who takes care of the cruft?  if there is no games team and no one steps up, then let's see if QA is willing to clean it out
<rich0> creffett|irssi: ++
<creffett|irssi> or, you know, punt entirely
<blueness> yeah that works creffett|irssi
<mgorny> well, so far the idea is that games team does the commits when user provides necessary changes
<creffett|irssi> threatening to remove stuff generally seems to motivate people to care for a while :)
<WilliamH> We also have a lot of games with security masks, and it is known they won't ever be fixed.
<WilliamH> imo they don't belong in the main tree
<mgorny> WilliamH: but having those packages makes users happy
<rich0> At this poitn I think this is a matter of who cares more - those who want to get rid of them, or those who want to keep them.  :)
<mgorny> like 'i choose gentoo because i can find the packages i want without adding 2 dozen random repos'
<rich0> Right now it is a battle of apathy.  :)
<WilliamH> mgorny: that's what overlays are for
<WilliamH> mgorny: in an overlay they wouldn't have to be masked.
<creffett|irssi> mgorny: then some of those users need to step up and at least say that the game still works
<blueness> mgorny, at this point they are a maintenance burdon
<mgorny> WilliamH: but imagine now, we fix the main tree and remove games.eclass
<rich0> I don't mind proprietary games in the main tree.  I just want somebody to pretend that they're maintaining them.
<mgorny> the whole overlay is broken now
<blueness> there are lots of broken overlays
<blueness> we are not going to go fix them all
<mgorny> and that is a problem
<mgorny> but we're going offtopic now
<mgorny> i'm going to forget my open floor items!
<WilliamH> mgorny: not for us, for the overlay maintainer.
<dilfridge> there are a lot of maintained overlays
<WilliamH> mgorny: we don't have to worry about overlays.
<dilfridge> they are all fixing perl ebuilds right now :P
<rich0> Ok, anything else we actually want to do on games/QA/etc?
<blueness> rich0, do we have a statement here?
<mgorny> dilfridge: like the official sunrise project overlay
-*- rich0 wants to save 2 min in the agenda to bug dberkholz about his summaries :)
<dilfridge> that is a special beast
<WilliamH> mgorny: that is still independent from the main tree. if it is broken it is up to that project to fix it.
<dilfridge> and I would even fix some ebuilds there if I could "just commit"
<blueness> rich0, how about we 1) make a second call for open season on games (as per radhermit) and 2) say if there is no interest games will be culled
<creffett|irssi> +1
<rich0> blueness: proprietary games I assume you mean?
<blueness> rich0, the problematic ones, proprietary are one, but there may be othres
<blueness> let QA decide
<dilfridge> I guess with 2) you mean "some games ebuilds will be culled", not "games team will be..."
<blueness> creffett|irssi, ^^^ does this work for QA?
<creffett|irssi> blueness: yes
<blueness> dilfridge, yes, i type faster than i think --- i code that way too :)
<rich0> I have no issue with that, though it really isn't a change in the status quo.  QA can already cull stuff that is broken.
<WilliamH> Right, it really isn't a change.
<blueness> rich0, we should emphasis the degree here maybe?
<rich0> In fact, didn't we already announce that QA is free to have at the games herd?
<blueness> i'm not sure, a second more emphatic email might help
<rich0> "Council deferrs to radhermit to continue working with the games team on
<rich0> the organization issues for another month.  Council will reach out to
<rich0> QA/Treecleaners and support their reviewing games packages as any other
<rich0> as far as bugs/security/QA/etc goes."
<rich0> That was last meeting.
<rich0> We could always +2 it I suppose.  :)
<WilliamH> heh
<blueness> maybe set a date, one month and QA *will* have at it
<rich0> Ok, how about this "Council will repeat a call for games volunteers and reiterates that QA is free to cull packages that have quality issues."
<rich0> blueness: Only QA can commit to that.
<blueness> creffett|irssi, can you follow up with such a timeline?
<creffett|irssi> blueness: sure, I can follow up on it
-*- rich0 looks at watch and does not want to have another meeting just for open floor
<blueness> something like "per the councils decision, we will start culling packages with QA issues starting on ..."
<rich0> Can we take the rest of this after the meeting closes?
<rich0> It really is QA speaking, not the council for the rest.
<blueness> i'm done, i just wanted to get this games thing off the table once and for all
<rich0> Ok, any need to vote or do you want me to just regurgitate our previous decision?  I suggest that there is nothing new here.
<blueness> are we on open floor?
<rich0> blueness: not yet
<WilliamH> Real quick, I just chatted with creffett|irssi. I am going to start announcing last rites on some of these packages and giving folks a week or two to move them to an overlay.
<rich0> next topic
<rich0> WilliamH: thanks
<rich0> Bug #503382 - Missing summaries for 20131210, 20140114, and 20140225 council meetings
<dberkholz|mob> Cool
<willikins> rich0: https://bugs.gentoo.org/503382 "Missing summaries for 20131210, 20140114, and 20140225 council meetings"; Doc Other, Project-specific documentation; CONF; ulm:council
-*- rich0 glances at dberkholz|mob
-*- blueness shutters!
<dberkholz|mob> Uhhhhh
<dberkholz|mob> I'm at a dinner in Berlin right now. Still 2/3 done.
<rich0> No desert for you...
<dberkholz|mob> Hope not. I prefer dessert.
<rich0> Ok, open floor.  :)
<mgorny> so
<mgorny> EAPI 6!
<mgorny> do you think we could drop runtime USE & || stuff from it? :D
<mgorny> nobody's going to do the work for portage, so there's no point pretending we can have improvement in non-shell area
<dilfridge> ...
<WilliamH> If the features aren't ready, they just don't go in. :-)
<mgorny> and wait till next summer to have EAPI 6
<ulm> mgorny: runtime USE is approved
<dberkholz|mob> +1 williamh
<mgorny> i think all other features are ready already
<dilfridge> runtime USE would be very nice to have
<rich0> Really up to the PMS team to recommend if they want to drop anything and get it done.
<mgorny> and Zac expressed that he'd rather have it deferred for EAPI 7
<WilliamH> ulm: yes, but there is no implementation, so he is asking that we drop it.
<ulm> mgorny: || ( ) approved under the condition that an implementation is ready
<mgorny> i know
<mgorny> the question is more about runtime USE
<rich0> We gave pre-approval to a bunch of stuff, but that doesn't commit PMS 100%.
<WilliamH> right
<blueness> mgorny, i'd like to hear Zac directly on what he wants to do with it
<ulm> I'm fine with deferring the two to EAPI 7
<rich0> blueness: ++
<rich0> I think this is up to the portage/PMS/etc teams.
<blueness> yes
<mgorny> could we then change runtime USE to add the condition like for ||?
<rich0> The initial approvals are a guideline so that they don't waste time on stuff we won't approve in the end.  
<blueness> i mean if we approve a feature and portage/pms says, wow, that's almost impossible to code, then what?
<ulm> maybe remove dohtml in EAPI 6 instead :)
<rich0> It isn't a commitment.
<blueness> if the feature is difficult and can't go in with a reasonable amount of time, we'll approave eapi6 without it
<WilliamH> Right, , the initial approvals do not mean the things we approve must be there in the end.
<blueness> so let portage come forward with that concern
<ulm> mgorny: sorry, I didn't get your last comment
<rich0> Yup, that was the whole reason of not giving the "real" approval until the reference implementation is done.
<mgorny> i'm going to ask Zac if we could put the current code as eapi6_pre1
<mgorny> ulm: i was asking if we could just add the same condition to runtime USE: if an implementation is ready
<ulm> mgorny: let's just drop it for EAPI 6
<ulm> since also syntax isn't clear yet
<mgorny> ok
<mgorny> so we have EAPI 6 ready now!
<mgorny> :P
<mgorny> just someone needs to write the PMS text
<blueness> good no need for future.eclass!
<ulm> (i.e. IUSE_RUNTIME vs syntax in IUSE)
<dilfridge> sigh, that was the one feature I was most looking forward to... :|
<ulm> mgorny: I'm at it for most of the features
<mgorny> dilfridge: feel free to code it
<mgorny> Zac's going to give you a hand
<dilfridge> only if you accept Perl
<mgorny> i don't mind perl
<blueness> hey let's rewrite portage in perl :)
<mgorny> not sure how you integrate it into the portage but that's not my problem
<WilliamH> or go ;-)
<mgorny> also https://wiki.gentoo.org/wiki/User:MGorny/Draft:install-qa-check.d
<dberkholz|mob> Gotta run, folks
<mgorny> nobody seems to care, portage patches are ready
<dberkholz|mob> Beer awaits
<rich0> dberkholz|mob: no problem - no more votes today
<dilfridge> mgorny: I like it.
<WilliamH> mgorny: I haven't looked at it, but is that even eapi related?
<mgorny> loosely
<dilfridge> mgorny: just that I'd use the same sort of "log levels" for qa as for the normal e* commands, i.e. info, log, warn, error
<mgorny> it extends ebuild's EAPI
<blueness> guys i've got to run too
<rich0> blueness: ok
<blueness> mgorny, looks good
<rich0> I'm going to call the official meeting here
<rich0> But, by all means continue discussion.