21:00 <@dberkholz> ok, 2000
21:01 <@dberkholz> who's here?
21:01 <@dertobi123> <-
21:01 <@lu_zero> <-
21:01 <@dertobi123> obviously
21:01 <@lu_zero> dertobi123 hmm
21:01 <@lu_zero> project
21:01  * lu_zero is afraid to open that maildir
21:01 -!- billie [n=billie@94.216.9.124] has quit [Remote closed the connection]
21:02 <@dberkholz> project is cool
21:02 -!- billie [n=billie@94.216.9.124] has joined #gentoo-council
21:02 <@dberkholz> anyone know what's up with cardoe this meeting?
21:02 <@dberkholz> dev-zero, Betelgeuse, Halcy0n -- check in please
21:03 -!- billie [n=billie@94.216.9.124] has quit [Remote closed the connection]
21:03 <@Halcy0n> I am here (mostly).  We had a power outage, so I'm bringing up my main desktop.
21:03 <@Betelgeuse> \o/
21:03 -!- billie [n=billie@94.216.9.124] has joined #gentoo-council
21:03 <@lu_zero> cardoe or flameeyes?
21:03 <@dev-zero> dberkholz: hee
21:04 -!- billie [n=billie@94.216.9.124] has quit [Remote closed the connection]
21:04 -!- billie [n=billie@94.216.9.124] has joined #gentoo-council
21:04 <@dberkholz> well, flameeyes didn't even know there was a council meeting so i'm presuming he wasn't asked to proxy for it
21:05 <@dberkholz> i know cardoe also asked dang to proxy at least once
21:05 -!- billie [n=billie@94.216.9.124] has quit [Remote closed the connection]
21:05 -!- billie [n=billie@94.216.9.124] has joined #gentoo-council
21:06 <@dberkholz> dang also heard no proxy request
21:06 <@dberkholz> well, let's get rolling
21:06 -!- billie [n=billie@94.216.9.124] has quit [Remote closed the connection]
21:06 -!- billie [n=billie@94.216.9.124] has joined #gentoo-council
21:07 -!- billie [n=billie@94.216.9.124] has quit [Remote closed the connection]
21:07  * fmccor wonders if there's any way to get billie to stay or to go.
21:07 -!- billie [n=billie@94.216.9.124] has joined #gentoo-council
21:07 <@dberkholz> cardoe's got a .away saying he has little internet access
21:07 <@dev-zero> maybe timesavings again
21:07 < tanderson> fmccor: +b ;-)
21:07 <@dberkholz> ok -- wrt the council size, what are council members' opinions?
21:08 <@dberkholz> keep as is or let it change somehow?
21:08 <@dev-zero> well, mine is that there should be a minimum of 3 and a maximum of 7
21:08 <@dev-zero> and we shall try to reach 7 but not enforce it
21:09 <@Betelgeuse> I have nothing against adding an option to vote for a smaller council. Not really sure how that voting works though.
21:09 <@dertobi123> as is, if it needs to changed i'd like to see at least 5 council members
21:09 <@dertobi123> +be
21:09 -!- billie [n=billie@94.216.9.124] has quit [Remote closed the connection]
21:10 < darkside_> w
21:10 <@dev-zero> but if we decide to do staggered votes, the probability of having too less "worthy" candidates decreases
21:10 <@dberkholz> i think we should also let it change, from 1-7
21:10 <@lu_zero> I'd keep 5+
21:10 <@dberkholz> upper limit to make it small enough to be effective, lower limit to let devs decide on what kind of leadership they want
21:11 <@dev-zero> if you want them to decide what leadership they want you don't set a lower limit
21:11 <@dev-zero> but in the end they voted once for a council and should therefore get a council and not a single person
21:11 <@lu_zero> dev-zero I guess he was referring to the 1-7 range
21:12 -!- billie [n=billie@94.216.9.124] has joined #gentoo-council
21:12 <@dertobi123> dev-zero: agreed, i see no reason nor request nor $whatever to change our leadership model
21:13 <@dberkholz> Halcy0n: any opinion on whether the council size should be variable, and if so, what ranges?
21:13 <@Halcy0n> I don't see a reason to make it variable, and I think it would just complicate things.  If the size should change, I think it should be static.
21:13 <@Halcy0n> (i'm completely back now, I was just catching up)
21:14 <@Halcy0n> I guess I'm not seeing the reason for changing it, or a big request to change the size of the council.
21:15 <@dertobi123> fully ack
21:15 <@dberkholz> well, each additional person makes coming to a decision about anything more difficult
21:16 <@dev-zero> the reason why this was brought up was that since we now have to _reopen_nominations person determining the allowed candidates we might get to the point where we have too less candidates
21:16 <@dertobi123> was it that difficult in the past to get some decisions?
21:16 <@dberkholz> when a vote takes 2 weeks, that's way too long.
21:16 <@dev-zero> agreed
21:16 <@dberkholz> when it takes forever to get everyone to post their thoughts on a mailing list, it cripples progress
21:16 <@Halcy0n> dberkholz: then I'd say we should have people that can be involved and make decisions faster.
21:18 <@dberkholz> even on irc. we've got 7 people, and waiting for everyone to speak up on an issue means the rest of us are just wasting time
21:18 <@dertobi123> dberkholz: well, democracy does take it's time ... if we *need* to make quick decision i'm very confident that we are able to make quick decisions
21:18 <@dev-zero> dberkholz: listening to other's people opinion is not wasting time
21:18 <@Halcy0n> dev-zero: he means it takes some people 5 minutes to finally respond to something.
21:18 <@dberkholz> dev-zero: it is when they aren't even at the computer, and you're waiting for them to look at the screen again
21:19 <@dev-zero> ok, then you've lost me
21:19 <@dberkholz> if 6 of us are waiting 5 minutes for the 7th person to speak up, that's 30 minutes (6*5) that just got wasted
21:19 <@dev-zero> I don't see those people around here
21:19 <@dberkholz> how long does it take us to do attendance at the beginning of a meeting?
21:20 <@dberkholz> that should literally take 30 seconds
21:20 <@dev-zero> 3 minutes
21:20 <@dev-zero> dberkholz: then lets say so
21:20 <@dertobi123> dberkholz: then the solution would be to move to an ansynchronous medium like email ...
21:20 <@dertobi123> but still then you won't come to quicker decisions
21:20 <@Halcy0n> That makes it take even more time.  We want to streamline.
21:20 <@dberkholz> the solution would be for people to actually devote their time when we've got a meeting
21:20 < tanderson> *sigh*, think of all the time that's being wasted right now over this discussion
21:20 <@dertobi123> and who of us isn't doing this?
21:21 <@dberkholz> we get people together at the same time because we're trying to make progress faster, not sit here
21:21 <@dertobi123> tanderson: right, this discussion is a plain waste of time
21:21 <@dev-zero> dberkholz: yeah, so lets do it and stop talk talking about it
21:22 <@Halcy0n> Then no one get pissed when one of us points out that we are completely waiting on you to respond.
21:22 <@dberkholz> ok, we'll just stop waiting for people's responses during meetings from now on and move ahead
21:22 <@dev-zero> good
21:23 <@Halcy0n> Moving this along, I like the idea of longer terms and staggered elections.  I think a 2 year term and having elections every year is a great idea.
21:23 <@dev-zero> dito
21:23 <@dberkholz> i thought solar made a good point
21:23 <@dev-zero> or just when it's needed and to encourage people to stay at least a half a year
21:24 <@dertobi123> staggered terms++, i still think 2 year terms are way too long seeing how many council members we loose within a one year term
21:24 < darkside_> 2 years is too long, think about this year alone.
21:24 < darkside_> right, dertobi123
21:24 <@dberkholz> when we're always replacing a couple of people, doesn't that mean the continuity of the others becomes that much more important?
21:25 <@dev-zero> yes
21:25 <@dev-zero> on staggered terms, the 2 years is just a maximum time until someone has to take a revote
21:26 <@dberkholz> i'm really on the fence about this.
21:26 <@dev-zero> and yes, I think people will still take matters serious enough to not just quit just when they're tired about it
21:26 < darkside_> another point. i think 2 year terms might scare off people from even running for council. not sure if that is good or bad
21:26 <@Halcy0n> I see the arguments for both sides as well.
21:26 <@Halcy0n> darkside_: that might be a good thing actually.
21:27 <@Halcy0n> darkside_: since it would mean that people that actually go through with it are interested in doing the job.
21:27 < darkside_> perhaps, or you lose valuable input from "good people that don't commit to it"
21:27  * darkside_ shrugs and sits back down
21:27 <@lu_zero> darkside_ input?
21:27 <@Halcy0n> darkside_: just because they are not on the council doesn't mean they can't give their input.
21:28 <@dev-zero> darkside_: if they're good people they'd find a way to bring themselves in
21:28 <@dberkholz> re Halcy0n, look at you talking now. =)
21:28 <@dberkholz> (you = darkside_ )
21:28 <@dberkholz> since i'm not convinced there are definite benefits to changing, i'd rather leave things the way they are (pending further convincing, of course)
21:29 <@dberkholz> i believe solar's argument that continuity is provided by good people getting re-elected
21:29 <@dertobi123> ack
21:29 <@dertobi123> that's always been a case in the past and will be in the future
21:29 < ciaranm> most people who stand for reelection end up getting reelected
21:30 < ciaranm> not like it's a whole new council every term, and if that did happen it'd indicate something being severely wrong anyway
21:30 <@dev-zero> well, that's true. Until a council member didn't screw up completely, the probability is high he gets reelected
21:31 <@dberkholz> i think the best point about a longer term is Halcy0n's. 2 years is an awfully long time in gentoo, and i think it would make people really think about the commitment
21:32 <@dev-zero> no, I don't think that it would
21:33 <@dberkholz> ok
21:33 <@Halcy0n> I'm don't feel strongly either way right now, and it doesn't seem that others do either.  I think this should be tabled until it does become an issue.
21:33 <@dev-zero> good
21:33 <@dertobi123> maybe ... but i do expect people to think about a one year commitment, too - and even that didn't work in 2-3 of 7 cases in the past
21:33 < tanderson> I think the oftener the gentoo community gets to pick their council members the better
21:34 <@dberkholz> ok. seems like there's not a whole lot of force for change, as Halcy0n says, so let's move on
21:34 <@dberkholz> that's it for the council meta blah
21:34 <@dberkholz> anyone want to say something about that PMS bug that they didn't have time to get onto the lists?
21:35 <@dev-zero> yes, I don't want prep* in the PMS
21:35 < ciaranm> i'd like the council to make an executive decision to remove prep* from the tree and have done with it
21:35 <@dberkholz> i left a comment on the bug <http://bugs.gentoo.org/show_bug.cgi?id=250077> asking whether vapier & ciaranm were going to reach agreement
21:36 < ciaranm> we could agree on some horribly convoluted weasel wording that essentially allows prep* to do absolutely anything
21:36 < ciaranm> but that's really not something i'd like to see in a specification
21:36 <@dev-zero> yeah, let's cross beams
21:36 <@dberkholz> from my reading, it seems like having a way to tell the PM to compress or not compress docs can be useful
21:37 < ciaranm> dberkholz: it's pointless
21:37 < dleverton> dberkholz: as far as I remember vapier hasn't commented at all since I pointed out that prepalldocs /did/ change behaviour between portage versions.
21:37 <@dev-zero> I'd say that people thinking that prepalldocs is something useful should write a proper spec for a function/way it should work and then have it in a future eapi
21:37 < ciaranm> anyone who cares whether the docs get compressed only cares because it's another pointless option they can change in their config
21:37 < ciaranm> it has no practical effect, beyond giving users the illusion of choice
21:38 <@dberkholz> so the assertion is that packages won't care about the compression status of non-html things in their doc directory
21:39 < ciaranm> if packages care about the compression status, they can't use prepalldocs anyway
21:39 < ciaranm> because prepalldocs can do undefined things
21:39 <@lu_zero> as in?
21:39 < ciaranm> lu_zero: check dleverton's most recent description of its behaviour
21:39 <@dberkholz> my understanding is that you're saying the PM should handle compression on the backend and the EAPI will not provide for any way to control what it does
21:40 < ciaranm> depending upon portage version and user config, prepalldocs can make arbitrary changes or no changes to arbitrary files, and it can do it at a later stage than when it's called
21:40 < ciaranm> dberkholz: i'm saying the package manager shouldn't compress anything
21:40 <@dberkholz> ok, so how should compression happen?
21:40 < ciaranm> if an ebuild genuinely needs something compressed, it should explicitly compress it in whichever way it needs it
21:41 -!- Arfrever [n=Arfrever@gentoo/user/arfrever] has joined #gentoo-council
21:41 <@dberkholz> as in bzip2 doc/* ?
21:41 < ciaranm> except that bzip2ing docs is by and large pointless
21:41 -!- tomaw [i=tom@freenode/staff/tomaw] has quit [Remote closed the connection]
21:42 <@lu_zero> depending on what is in docs...
21:42 <@lu_zero> anyway
21:42 <@dberkholz> i've got half a gig of crap in my doc directory
21:42 < ciaranm> if docs are huge, they can be made optional
21:42 <@Halcy0n> I guess I don't really understand the point to compressing the documents either, and if it should happen, it seems like something the package manager should just do automatically if the user asks for it.
21:42 < ciaranm> dberkholz: and compression makes no practical difference to that
21:42 <@lu_zero> ...
21:42 < ciaranm> compressing a 1KByte file gives you a file that takes up the same amount of real disk space
21:43 <@lu_zero> anyway
21:43 < ciaranm> if you care about space at all, just remove the docs entirely
21:43 <@lu_zero> the issue is about having prepalldocs exposed to ebuilds
21:43 < ciaranm> actually, if you care about space at all, focus on something more useful
21:43 <@lu_zero> or having a way to say "do not compress/compress"
21:43 <@lu_zero> ?
21:44 < ulm> lu_zero: the issue is about properly documenting it
21:44 <@dev-zero> lu_zero: well, then write a function "docdocs" which does that in a clear and documented way
21:44 < ciaranm> the issue is whether the council's prepared to mandate "nuke all prep* calls from the tree and then pretend it never existed"
21:44 < ciaranm> or whether we have to stick with weasel wording that says "prepalldocs can do anything it wants to, or nothing at all"
21:45 <@dertobi123> "but maybe does compress some files"
21:45 < ciaranm> dertobi123: not that simple
21:45 <@dertobi123> heh
21:45 < ciaranm> that's not even what it does when it works
21:45 < ciaranm> it really is "anything it wants to"
21:46 <@dev-zero> so lets nuke it
21:46 <@lu_zero> dev-zero that isn't an answer to my question, ciaranm's is better =P
21:46 -!- tomaw [i=tom@freenode/staff/tomaw] has joined #gentoo-council
21:46 <@Halcy0n> This came up rather late for me to give any useful feedback.  I'm not seeing the great advantage to using it though.
21:46 <@dberkholz> i'm reading through the bug again
21:46 <@dberkholz> so far i've made it to comment #27
21:47 < ciaranm> dberkholz: comment #42 is the useful one
21:47 <@dberkholz> well, let's lay out some possible options
21:48  * lu_zero is grepping the tree out of curiosity
21:48 <@dberkholz> we could get rid of it, and then docs would be compressed or not by the PM, and we don't know if anything breaks till we get bugs
21:48 <@dertobi123> lu_zero: heh ... /me too ... damn slow sata-drives :(
21:48 <@dev-zero> lu_zero: there are a lot of ebuilds using prepalldocs
21:48 < ciaranm> dberkholz: no, then docs would not be compressed at all except where ebuilds say to do so
21:48 <@dberkholz> we could keep it in EAPI=0 and drop it in EAPI=3 or whatever
21:48 < ciaranm> dberkholz: the package manager can't safely compress things unless it's told to
21:49 <@dertobi123> dev-zero: well ... not even a more than handful of packages
21:49 <@dertobi123> -a
21:49 <@lu_zero> dev-zero I was more interested on who is using it
21:50 <@dberkholz> ok, so the consequence of option 1 is that we use extra space. right now we don't really know how much or which packages are affected, and why either of those matter
21:50 < darkside_> fwiw, prepalldocs is not on devmanual.g.o according to google and at least i do not know how/why to use it
21:51 <@Halcy0n> darkside_: none of the prep functions are on there.
21:51 <@lu_zero> from what I see it should force docs to be compressed
21:51 <@lu_zero> or at least comments say that
21:51 < ciaranm> lu_zero: except that compression might be a no-op
21:52 < darkside_> Betelgeuse: i don't think prep*() is on the dev quizzies either, right?
21:52 < ciaranm> lu_zero: also, you have to check both stable and scm portage
21:52 < ciaranm> lu_zero: because it does different things in each
21:52 <@Betelgeuse> darkside_: It's not and has never been asked in reviews either.
21:52 <@lu_zero> ciaranm dual xor is still encryption
21:52 <@Betelgeuse> Ideally it would not show up in public APIs either.
21:52 <@Betelgeuse> If people really need something let's get a new EAPI with it.
21:53 <@lu_zero> ciaranm I think the prep stuff should stay private
21:53 < ciaranm> unfortunately portage doesn't split private and public stuff up too well
21:53 < ciaranm> so it's not always obvious which is which, and some people assume that if it's there it's ok to use it
21:54 <@lu_zero> nothing that cannot be addressed
21:54 <@lu_zero> still
21:54 <@dberkholz> i don't think we're going to get this figured out in the next 7 minutes
21:54 < ciaranm> you could go with the "nuke prep* and pretend it didn't ever exist" solution right now!
21:54 <@lu_zero> ciaranm too easy =P
21:54 <@dberkholz> here's what i want to understand. what concrete benefits do we get from prepalldocs?
21:55 < ciaranm> *cough* absolutely none *cough*
21:55 <@dberkholz> if you install every package that runs it, how much space do you save?
21:55 <@lu_zero> dberkholz I wanted to know that from people using it
21:55 <@dberkholz> is the other option adding a bunch of code to run dodoc 80 times?
21:55 < ciaranm> the other option is to just do nothing
21:56 < ciaranm> there's no guarantee that prepalldocs isn't a no-op anyway
21:56 < ulm> dberkholz: the other option is to remove any files installed by the build system of a package and reinstall them using dodoc
21:56 <@lu_zero> ciaranm no-op isn't a problem
21:56 <@dev-zero> ciaranm: I think dberkholz meant if people want to install compressed docs
21:56 <@lu_zero> ulm doesn't sound that nice
21:56 < ciaranm> if you *need* compression, you can't rely upon dodoc either
21:56 < ciaranm> dodoc isn't guaranteed to compress
21:57 < ciaranm> the only thing you gain by doing what ulm said is using the user's choice of compression, and that should never have been given to the user as a choice to begin with
21:57 <@lu_zero> but marks them as docs
21:57 < ciaranm> dodoc doesn't mark anything
21:58 <@lu_zero> ciaranm if I make dodoc just a no-op
21:58 < ciaranm> dodoc can't be a no-op
21:58 <@lu_zero> (say I do not care about docs)
21:58 < ciaranm> dodoc has to at least copy the docs
21:58 <@lu_zero> rm is a compressor as well =P
21:58 < ciaranm> if you don't care about docs, you nuke them *after* src_install
21:58 < ciaranm> i'm fairly sure some ebuilds will break if you make dodoc use rm as compression
21:59 < ciaranm> because ebuilds assume that dodoc's side effects will happen
21:59 <@lu_zero> ciaranm there are some?
21:59 <@lu_zero> is that expected?
21:59 < ciaranm> dodoc makes directories
21:59 <@dberkholz> we've gotta finish this up on the -dev list
21:59 <@lu_zero> apparently so
21:59 <@dertobi123> yep
21:59 <@dev-zero> unfortunately it seems like, yes
22:00 <@lu_zero> and I think it will lead to more interesting ends
22:00 <@dberkholz> i'm going to post the things i think need to happen for us to make a decision
22:00 <@dberkholz> after i eat lunch
22:00 <@lu_zero> 2 min left
22:00 < ciaranm> is anyone going to update http://www.gentoo.org/proj/en/council/ ?
22:00 <@Halcy0n> dberkholz: sounds good.  I'm going to do a little investigation to see what this actually does give us.
22:00 <@Halcy0n> ciaranm: I would love to, but I don't have the logs.  If someone has them, I'll do it.
22:01 <@dberkholz> http://dev.gentoo.org/~dberkholz/20080122_summary.txt is a very rough summary that i'm still working on
22:01 <@dberkholz> with more my thoughts than an actual summary at the end
22:01 < tanderson> Halcy0n: I have them for some meetings, not all
22:01 <@Betelgeuse> Halcy0n: I can send the logs of this channel for the last couple years
22:01 <@Halcy0n> Are we missing any meetings from that page?  Or did none of them happen?
22:01 <@dberkholz> there are some other summaries in the same place too
22:02 <@dberkholz> woops, s/2008/2009 up there
22:02 <@dev-zero> Halcy0n: the one from December 11th is missing there
22:03 <@dberkholz> Halcy0n: the only interesting one is http://dev.gentoo.org/~dberkholz/20081211-summary.txt
22:03 <@dberkholz> i need to leave now
22:04 <@dberkholz> meeting's over, continue prepalldocs talk on -dev and postpone bug checks to lists/next meeting