[gentoo-council] Council log and summary for meeting on 02/12/09

[gentoo-council] Council log and summary for meeting on 02/12/09

[Thomas Anderson]

[-- Attachment #1: Type: text/plain, Size: 19 bytes --]

They are attached.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: #gentoo-council.02-12.log --]
[-- Type: text/plain; charset=unknown-8bit, Size: 23228 bytes --]

15:03 < dberkholz> Betelgeuse, cardoe, dberkholz, dertobi123, dev-zero, Halcy0n, lu_zero -- who's here?
15:03 <@dertobi123> <-
15:03 <@lu_zero> \o
15:03 < dev-zero> me
15:03 < dberkholz> Halcy0n informed me half an hour ago that he couldn't make it because of work obligations that came up
15:03 -!- piotao [i=piotao@p323.math.univ.gda.pl] has joined #gentoo-council
15:04 < dberkholz> didn't have time to find a proxy
15:04 -!- Atigo [n=atigo@azx122.neoplus.adsl.tpnet.pl] has joined #gentoo-council
15:04 < dev-zero> where is cardoe?
15:05 < dberkholz> i just pinged him in #-dev
15:05 < dberkholz> ok, we've got 5 because Betelgeuse was here 6 minutes ago
15:06 < dberkholz> let's get rolling on the secretary thing
15:07 < dev-zero> should I summarize it?
15:07 < dberkholz> sure
15:07 < dev-zero> ok
15:07 < dev-zero> we need someone doing the summary and upload the logs
15:07 < dev-zero> in the past dberkholz did it but he got busy
15:08 < dev-zero> so, to ensure we get those things done I proposed the job of a Secretary
15:08 < dev-zero> option 1) have someone of use doing it
15:08 < dev-zero> possibly in a rotating scheme
15:08 < dev-zero> option 2) have a dedicated person doing it
15:08 < dev-zero> luckily tanderson volunteered
15:09 < dev-zero> has someone a better idea?
15:09 <@dertobi123> no, i like it (that being option 2)
15:09 -!- Cardoe [n=Cardoe@gentoo/developer/Cardoe] has joined #gentoo-council
15:09 -!- mode/#gentoo-council [+o Cardoe] by ChanServ
15:09 <@Cardoe> sorry
15:09 <@lu_zero> I'm fine with both
15:09 < dberkholz> i agree that we should have a dedicated, non-council member do the secretary tasks
15:10 <@Cardoe> Did we have any volunteers?
15:10 < rane> -> tanderson
15:10 < dberkholz> yes, tanderson volunteered
15:10 < dev-zero> I think that's always up to the council deciding what they want
15:10 < dev-zero> since we got a volunteer I'd say we accept the offer :)
15:11 <@Cardoe> I'd agree with that
15:11 < dev-zero> but I think (and that's what I meant with rules) that every council has to clear that question at the beginning of their term
15:11 < dev-zero> and stick to it
15:11 < dberkholz> which question?
15:11 < dev-zero> the question who's doing the job of the Secretary
15:11 -!- en0x [i=en0x@unaffiliated/en0x] has left #gentoo-council ["*Dead girls don't say no*"]
15:11 < dberkholz> oh, sure.
15:12 <@lu_zero> and in what it consists
15:12 < dev-zero> yes
15:12 < dberkholz> ok, here's what i think
15:13  * dev-zero thinks it would be useful to see when someone's typing
15:13 < dberkholz> we should make a decision now about how it works. obviously later councils could change the process if they want, but making them rethink the whole thing every time doesn't make sense
15:13 < dev-zero> good
15:13 < dberkholz> so we should say, at the beginning of each council term, you pick a secretary who is not a council member (for justification previously provided)
15:14 < dberkholz> and you have to pick someone who actually volunteers for it
15:14 -!- PapaDelta [n=PapaDelt@p5B025427.dip.t-dialin.net] has joined #gentoo-council
15:14 < dev-zero> I already prepared something like this: "the council should appoint a Secretary. If possible, a volunteer who's not council member. If not, they can decide whether a council-member is doing it every time or whether they stick to a rotating scheme."
15:14 <@lu_zero> I think you can pick as many people as they voluteer
15:14 <@Betelgeuse> lost connection
15:14 < dev-zero> no, maximum two
15:15 <@lu_zero> dev-zero why?
15:15 <@Betelgeuse> stupid 3G is slow as hell atm
15:15 < dev-zero> lu_zero: avoiding a mess and you surely get the "what, it wasn't my turn, it was his" play
15:15 < dberkholz> i really think you need to give each person sufficient experience to do a good job at it.
15:15 < NeddySeagoon> You want consistancy ... 1 or 2 people max
15:16 <@lu_zero> ok then it's 2
15:16 < dev-zero> ok, do we need to discuss it here or can we just decide that we have a Secretary now and phrase it out on the ml?
15:17 < dev-zero> sorry, shouldn't have been so rude
15:17 < dberkholz> who's ok w/ tanderson as secretary?
15:17 < dev-zero> me
15:17 < dberkholz> i am
15:17  * dertobi123 is
15:17  * lu_zero is
15:17 < dberkholz> ok.
15:18 <@lu_zero> tanderson are you really _sure_ ?
15:18 < dberkholz> i would like a 1-day review period on -council before summaries get posted everywhere else
15:18 < tanderson> lu_zero: yes
15:18 < dev-zero> dberkholz: agreed
15:18 <@dertobi123> dberkholz: agreed
15:18 <@lu_zero> dberkholz ok
15:18 < dberkholz> tanderson: ok it's all you baby. show us what you've got!
15:18 < dev-zero> dberkholz: but organized as "published if no complaints"
15:18 < dberkholz> agreed.
15:18 < tanderson> dberkholz: I'm working on it1
15:18 < tanderson> s/1/!
15:19 < dberkholz> tanderson: just waiting to be impressed after the meeting. =)
15:19 < dev-zero> tanderson: s/1/\!
15:19 < tanderson> dev-zero: hrmph
15:20 < dberkholz> to summarize: tanderson is the new secretary. he will post summaries for 1 day of review on council, after which they default to being posted everywhere. we will work out further details about the process on the list, if people care enough to do so.
15:20 < dev-zero> perfect :)
15:20 <@lu_zero> next item
15:21 < dev-zero> staggered elections?
15:21 -!- comprookie2000 [n=david@gentoo/contributor/comprookie2000] has joined #gentoo-council
15:21 < dberkholz> my opinion's already up =)
15:21 < dberkholz>         DB: Leave as is if 1-year terms. Don't want 6-month staggering.
15:22 <@dertobi123> leave it as is, 6-month are way too short
15:22 <@lu_zero> leave it as is.
15:22 < dev-zero> agreed, 6-month are too short
15:22 < dberkholz> ok, sounds good.
15:22 <@Betelgeuse> as is is fine
15:22 < dberkholz> let's move on then
15:22 < dberkholz> What if we don't get enough candidates?
15:22 < dev-zero> good
15:22 -!- quantumsummers|a [n=quantums@gentoo/developer/quantumsummers] has joined #gentoo-council
15:23 < dberkholz> my thoughts -- Deal with it when it happens. No rules for hypothetical situations.
15:23 < dev-zero> I think this question is important because if you once get there not having enough candidates it might get messy
15:23 <@Betelgeuse> boohoo those running do a reduced council
15:24 < dev-zero> well, it would already help if you would do a second nomination-period for the remaining slots
15:24 < dev-zero> after that we can still say we deal with it when it happens
15:24 <@lu_zero> ok
15:25 <@dertobi123> sounds good
15:25 < dberkholz> fine
15:26 <@Cardoe> trying to come up with every hypothetical situation will waste everyone's time
15:26 <@Betelgeuse> I don't see a need but majority rules
15:26 <@Cardoe> look at most governing bodies, they allow this flexibility
15:26 < dberkholz> we're pretty much just specifying what already happens
15:26 < dev-zero> Cardoe: no, they ruled it all out
15:27 < dev-zero> but we're not a governing body
15:27 < dev-zero> so, simple rules should be applied
15:27 <@Cardoe> dev-zero: we're governing ourselves and our election process
15:28 < dev-zero> Cardoe: allright
15:29 < dev-zero> next?
15:29 < dberkholz> i want to clarify this
15:29 < dev-zero> sorry
15:29 < dberkholz> are we saying that if "reopen noms" turns up in position #6, we will run with the new 5-person council and hold a 2nd election for the last 2 spots?
15:29 < dev-zero> I'd say so
15:30 <@lu_zero> could work
15:30 < dev-zero> put rephrase it to "if not all slots are filled after the first election period a second one should be held"
15:30 < darkside_> and a third? etc
15:30 < dev-zero> no
15:31 < dberkholz> i'd like to avoid a ton of "what if's", so let's move on
15:31 < dev-zero> agreed
15:31 < darkside_> just stop at 2 until the next year
15:31 < dberkholz> we can deal with other stuff if it actually comes up
15:31 < dev-zero> exactly
15:31 < dev-zero> if we get to that point something's wrong anyway
15:32 < dberkholz> ok, i'd like to move on to the next topic, prepalldocs.
15:32 < dberkholz> dev-zero had 2 questions. do we need more info, and should we ask for discussion on -dev?
15:32 < dev-zero> I asked because we didn't decide last time
15:33 < dev-zero> my opinion is basically set, what about yours?
15:33 <@Cardoe> dev-zero: I say we just allow it to happen twice, total
15:33 <@Betelgeuse> The less the better
15:34 -!- Atigo [n=atigo@azx122.neoplus.adsl.tpnet.pl] has left #gentoo-council ["Konversation terminated!"]
15:35 < dberkholz> ok, sure.
15:35 < dberkholz> opinions on prepalldocs in pms (bug #250077)?
15:35 < Willikins> dberkholz: https://bugs.gentoo.org/250077 "prepalldocs should be documented in PMS"; Gentoo Hosted Projects, PMS/EAPI; ASSI; ulm@g.o:pms-bugs@g.o
15:35 < dev-zero> prepalldocs should be kept internal and usage should be avoided
15:36 < dev-zero> reason: internal function and change of it's implementation prooves it
15:36 < dev-zero> if someone want's it's functionality he should propose a solution for a future eapi
15:36 <@Betelgeuse> agreed
15:37 <@dertobi123> dito, agreed on that
15:37 <@lu_zero> sounds sensible
15:37 < dberkholz> Cardoe: any thoughts?
15:38 <@Cardoe> yeah getting a little caught up
15:38 <@Cardoe> but I think dev-zero hit it on the head
15:39 < dberkholz> ok, so what we're saying is prepalldocs won't be in any current EAPI and needs to be removed from ebuilds. is that accurate?
15:39 <@Betelgeuse> I can make a check for repoman
15:39 < dev-zero> yes
15:40 < dev-zero> Betelgeuse: great :)
15:40 <@dertobi123> dberkholz: yep
15:41 < dberkholz> alrighty then
15:41 < dberkholz> open bug status
15:41 < dberkholz> glep 54, any change?
15:42 < ciaranm> most of the objectors to glep 54 have surrendered
15:42 <@Cardoe> putting it that way makes it sounds like something that we'd really want to adopt
15:43 <@Cardoe> "we've managed to beat down anyone opposing until they just can't care anymore or have quit the project"
15:43 <@lu_zero> nobody updated the bug according my thunderbird
15:43 < ciaranm> Cardoe: the person doing the objecting wasn
15:43 < ciaranm> Cardoe: 't a gentoo developer
15:43 < ciaranm> the objections to 54 came from igli aka slong aka ranjit singh
15:43 < ciaranm> and he objected to it because it came from the wrong people
15:43 <@Cardoe> I'm just saying. How you put it wasn't the most positive light possible
15:44 <@Betelgeuse> doesn't 54 still come bundled with 55?
15:44 < ciaranm> Betelgeuse: 54 works best if 55 is also accepted
15:44 < dev-zero> a possibility to avoid *.ebuild-123456789 would be to have it as a separate number being incremented only when needed
15:44 < ciaranm> dev-zero: you're confusing 54 and 55
15:44 < ciaranm> 54's -scm
15:44 < dev-zero> yes
15:45 <@Betelgeuse> ciaranm: there's probably still opposition to that around
15:45  * tanderson confused them in the summary too, dangit
15:45 < dberkholz> i like PROPERTIES=live
15:45 <@Betelgeuse> but if their arguments have merit is an another matter
15:45  * lu_zero likes that too
15:45  * dev-zero likes -scm
15:45 < ciaranm> properties=live doesn't solve anything
15:45 < ciaranm> you can't have proper version numbers just through properties
15:45 <@lu_zero> "proper"
15:46 < dberkholz> you can't put git tag names in a version either
15:46 < ciaranm> there's no way of using the existing version number syntax to correctly express scm versions
15:46 <@Betelgeuse> ciaranm: but it does give some of the things that scm is used to provide
15:46 < ciaranm> Betelgeuse: it doesn't, though
15:46 < ciaranm> scm's designed to solve the lack of proper ordering with existing version syntax
15:46 <@Cardoe> I'm in favor of PROPERTIES=live myself.
15:46 < dleverton> And scm gives all of the things that scm is used to provide.
15:46 <@lu_zero> depends on what you want to put in the tree
15:47 < ciaranm> properties=live does nothing
15:47 <@lu_zero> ciaranm -scm does the same nothing
15:47 < ciaranm> lu_zero: no, -scm provides correct ordering
15:47 < dberkholz> looking at this from a bit different approach
15:47 <@lu_zero> live templates do something
15:47 < dberkholz> having some way to do this seems like a good thing
15:47 <@lu_zero> ciaranm "correct"
15:47 < dberkholz> and having someone who will actively work on finding a solution would be nice
15:47 < dev-zero> and you can't have foo-1.2.ebuild and foo-1.2.ebuild where one of them has "properties=live" in it
15:47 < ciaranm> lu_zero: yes, correct
15:48 <@lu_zero> dev-zero why not?
15:48 < dev-zero> lu_zero: because they're named the same
15:48 <@Cardoe> Again.. people are bringing up hypothetical without any real need or defect discussed
15:48 < dev-zero> Cardoe: wrong, they're not hypothetical
15:48 < ciaranm> Cardoe: the real was covered the first ten times the glep was discussed
15:49 <@lu_zero> and again everything got up in the last 1/2 hour
15:49 < ciaranm> Cardoe: you are aware of the original justifications, right?
15:49 < ciaranm> lu_zero: you too, since you seem to have forgotten them
15:49 < dev-zero> ok, people, let's stop it
15:49 < dberkholz> if they aren't in the glep, they might as well not exist
15:49 < dev-zero> won't have a conclusion now
15:49 < ciaranm> dberkholz: they are in the glep
15:50 < dberkholz> it would be better if it had a comparison with the other suggestions
15:50 < dev-zero> dberkholz: not the point of a glep
15:50 < ciaranm> it's the only suggestion that solves the problem. there. easy.
15:50 < dberkholz> the point of a solution isn't to say why it's the best solution?
15:50 <@lu_zero> false
15:50 < dberkholz> that seems ludicrous to me
15:50 <@lu_zero> and there is a problem defined
15:51 < dberkholz> anyway, i do agree with dev-zero that we won't suddenly resolve this during the meeting
15:51 < dev-zero> good
15:51 < dberkholz> lu_zero: will you pick this up more actively and run with it, or should someone else?
15:51 -!- hparker [n=hparker@gentoo/developer/hparker] has joined #gentoo-council
15:51 <@lu_zero> dberkholz I was waiting for zmedico
15:51 <@Betelgeuse> yeah we should at least put someone actively wroking on these
15:51 < dev-zero> yes
15:51 <@lu_zero> and/or other getting input
15:51 < dev-zero> this is what I proposed on the -ml as well
15:51 < ciaranm> for as long as people think PROPERTIES=live and -scm have anything to do with each other, this won't get solved because they don't have a frickin' clue what the point of either is
15:52 < dev-zero> good, then the person who's taking care of should investigate this
15:52 <@lu_zero> apparently the people using -9999 are happy with it
15:52 < ciaranm> lu_zero: -9999 is a hack and it's wrong
15:52 <@Betelgeuse> ciaranm: from end user view they can be used to provide same things
15:52 <@lu_zero> ciaranm people using it disagree
15:52 < tanderson> my question: does properties=live solve version ordering issues?
15:52 < dev-zero> lu_zero: I agree with ciaranm there
15:52 <@Betelgeuse> ciaranm:  but not all what each other enables of course
15:52 < dev-zero> lu_zero: I'm using it and I agree
15:52 < ciaranm> Betelgeuse: no, they're not the same for end users
15:52 < ciaranm> lu_zero: people using -9999 use it because they have to
15:52 <@lu_zero> dev-zero you hadn't update the related bug
15:53 < ciaranm> lu_zero: they do not use it because it is right
15:53 <@lu_zero> please do now
15:53 < ciaranm> the implications of PROPERTIES=live and -scm are entirely different and largely unrelated
15:53 <@Betelgeuse> ciaranm: what's the problem with doing periodic reinstalls with properties live?
15:53 < dev-zero> ok, people, please
15:53 < ciaranm> Betelgeuse: nothing, but that's not the entire point of -scm, and -scm isn't the only time you'd want periodic reinstalls
15:53 < dev-zero> we have other things to discuss
15:54 <@Betelgeuse> ciaranm: so you validate my earlier point?
15:54 < ciaranm> Betelgeuse: uh, no
15:54 < dberkholz> could you guys bounce this over to #-dev?
15:54 <@Betelgeuse> ciaranm: first you say what I say is wrong and then right?
15:54 <@Betelgeuse> You lost me.
15:54 <@lu_zero> better ml-dev
15:54 < dberkholz> i have another meeting coming up, and i'd like to at least mention the other topics first
15:54 <@lu_zero> next one
15:55 < dev-zero> yes
15:55 < ciaranm> Betelgeuse: i'm saying you've missed the mark by about three miles and are about to fly into a wall
15:55 < dev-zero> lu_zero: are you taking care of this topic?
15:55 < tanderson> Who should I put down as responsible for handling glep 54?
15:55 <@lu_zero> dev-zero I'll poll ml-dev and people and hopefully get the thing discussed again
15:55 <@Cardoe> The only thing you've said so far is "-scm is the only right solution. people don't have a clue about prop=live vs -scm"
15:56 < dev-zero> lu_zero: ok, thanks
15:56 <@Cardoe> the only thing we've gotten thus far are fear mongering statements
15:56 < dberkholz> tanderson: put luca, and say something about us cracking the whip at him
15:56 < ciaranm> Cardoe: read the GLEP
15:56 < ciaranm> PROPERTIES=live and -scm should not be mentioned within the same meeting because they'll just lead to people thinking they're somehow related
15:56 <@Cardoe> ciaranm: I was asking you to provide us with a reasonable issue and how -scm fixes it while prop=live does not
15:56 < ciaranm> Cardoe: ordering
15:56 < tanderson> dberkholz: k
15:57 <@Cardoe> instead we just had 15 minutes of time wasting
15:57 <@Cardoe> next topic since we can't seem to get any info
15:57 < ciaranm> Cardoe: ordering. which part don't you get?
15:57 < dev-zero> the point is that we currently do all ordering by comparing names of the ebuild, prop=live breaks that
15:57 -!- hparker [n=hparker@gentoo/developer/hparker] has left #gentoo-council ["uhm.... bye!"]
15:57 < dberkholz> ciaranm: feel free to continue bringing up glep 54 on the list, since it would be nice to see some progress there
15:57 < dev-zero> good
15:58 <@Cardoe> when I say bring up a concrete example with some details.. providing a one word answer doesn't suffice
15:58 < ciaranm> Cardoe: have you read the glep?
15:58 < dev-zero> Cardoe, ciaranm: stop it -> ml
15:58 < dberkholz> the only real thing left besides glep 54 is glep 55, and i think we'll have to push that to the list, much to my regret.
15:58 < ciaranm> dberkholz: i don't think we're going to get anywhere until Cardoe reads the glep... we're back to my email earlier about people doing their homework...
15:58 < dev-zero> I'd like to know who's going to take care of GLEP-55 and the bash-issue
15:59 <@Cardoe> ciaranm: I have read the GLEP.
15:59 <@Betelgeuse> dberkholz: my opinion still is that 55 needs something using it when it goes in
15:59 <@Cardoe> ciaranm: I'm asking for a concrete example here in the council discussion
15:59 < dberkholz> i really think that glep needs more enhancement. if you keep saying nobody gets it, that means it needs to be improved so people do get it
15:59 < ciaranm> Cardoe: ordering
15:59 <@Cardoe> to explain it clearly to everyone
15:59 <@Cardoe> I think the GLEP is lacking and needs work
15:59 < dev-zero> Cardoe: 55?
15:59 < ciaranm> there's a whole section in the glep on ordering
16:00 < darkside_> 55 is the best glep i have seen =/
16:00 < ciaranm> do you really not understand it?
16:00 -!- Ken69267 [n=Ken69267@gentoo/developer/ken69267] has joined #gentoo-council
16:00 <@lu_zero> Cardoe I'm reading again what was the first thing happened when 54 got proposed
16:00 < dberkholz> i need to go now. dev-zero, could you wrap up the meeting either now or whenever people finish talking?
16:00 < tanderson> which glep are you guys talking about?
16:00 < dev-zero> dberkholz: sure
16:01 <@Cardoe> at this point I would say the meeting is over since there won't be any productive discussion happening on either GLEP
16:01 < dev-zero> tanderson: of 54 and 55 at the same time, thus the mess
16:01 < dev-zero> Cardoe: not yet
16:01 < dev-zero> do we have someone taking care of GLEP-55?
16:01 < tanderson> dev-zero: exactly my dilemma for the summary
16:01 <@Cardoe> dev-zero: we haven't had anyone taking care of it for ages because no one has been interested.
16:02 < tanderson> darkside apparently is
16:02 < dev-zero> Cardoe: then you do the bash-3.1 issue?
16:02 <@Betelgeuse> I will be writing a new GLEP soon so I would like to focus on that.
16:02 <@Betelgeuse> Itäs not related to 54 or 55.
16:02 < ciaranm> no, we haven't had anyone taking care of 55 because every time it gets pushed the same already-answered questions get raised
16:02 < dev-zero> dberkholz is taking care of CoC
16:02 <@lu_zero> ciaranm basically not enough people wants anything about it
16:02 <@Betelgeuse> ciaranm: probably also because zac has not been interested
16:03 <@lu_zero> so is a non-issue to most of the people
16:03 < dev-zero> Betelgeuse: so, do you mind bringing GLEP 55 up on the mailing-list? I'll also join in
16:03 < ciaranm> 55's necessary, it's just that every time it comes along it gets trolled to death by a couple of malcontents
16:03 < dev-zero> ciaranm: can you please step aside for a moment
16:03 <@lu_zero> ciaranm statistics say otherwise
16:03 < ciaranm> lu_zero: please point me to the legitimate technical objections to 55
16:04 <@lu_zero> ciaranm I do not need any
16:04 <@Cardoe> Just because there's no technical objectives to something doesn't mean there's a need for someone.
16:04 <@Cardoe> er something
16:04 <@lu_zero> I could plug it getting portage scream about non undersandable files in it's dirs
16:04 < dev-zero> tanderson: I think we have someone for every point, don't we?
16:04 < ciaranm> which of the many reasons for 55 being necessary do you not accept?
16:04 <@lu_zero> and that is a good behaviour.
16:05 <@Betelgeuse> dev-zero: I thought I said to the contrary
16:05 <@lu_zero> ciaranm the fact it started as a solution looking for a problem
16:05  * NeddySeagoon is reminded of VHS vs Betamax ... marketing beat technical excellence
16:05 <@lu_zero> an hack over a fail tolerance measure
16:05 <@lu_zero> and so on.
16:05 < dev-zero> Betelgeuse: then I didn't understand you :)
16:05 < ciaranm> lu_zero: which of the many problems listed for 55 do you not consider legitimate?
16:05 < dev-zero> Betelgeuse: I'll take care of it then
16:05 < tanderson> dev-zero: would that be you for glep 55?
16:05 < dev-zero> tanderson: yes
16:05 < ciaranm> lu_zero: 55 came about to solve a half dozen real and nasty problems
16:05 < tanderson> ok
16:05 <@lu_zero> ciaranm there is a list of 6 points in the glep?
16:06 < dev-zero> we're done then
16:06 <@Betelgeuse> good I need to go as it's getting late
16:06 < ciaranm> lu_zero: yup
16:06 <@lu_zero> no
16:06 <@Cardoe> Additionally, I would oppose the acceptance of both GLEPs until we had sample code for Portage to implement them as well.
16:06 < ciaranm> lu_zero: the glep lists three bullet points that cover at least six real problems
16:07 < dev-zero> ok, the meeting is over

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 20090212-summary.txt --]
[-- Type: text/plain; charset=unknown-8bit, Size: 2444 bytes --]

Roll Call:
===========
Betelgeuse: here
Cardoe: here
dberkholz: here
dertobi123: here
dev-zero: here
Halcy0n: absent
lu_zero: here
tanderson(secretary): here

Topics:
===========

Secretary:
    - Should the council have a dedicated secretary?
        Previously dberkholz fulfilled this roll, but he became busy.
	Because fulfilling the secretary duties can distract from the
	meeting, a dedicated, non-council member secretary is ideal.
	tanderson(gentoofan23) volunteered and is the new secretary.

	Conclusion:
	   tanderson is the new secretary. Logs and summary are to be
	   posted on the -council mailing list. If no objections to it
	   are raised in 1 day, it is posted to to council page.

Elections:
    - Staggered elections
    	Should there be staggered elections every 6 months where half the
	    council members stand for reelection?

	Conclusion:
	    Leave as-is, elections every 6 months is too cumbersome. Full elections
        will be held once a year.

    - Lack of nominated candidates
    	What happens if there aren't enough candidates nominated to fill all
	    the council seats?

	Conclusion:
	    If the pseudo-candidate '_reopen_nominations' appears in 7th place
	    or higher those candidates that rank above '_reopen_nominations'
	    will be the current council. A second period of nominations will
	    be opened for the remaining council seats.

Technical Issues:
    - Prepalldocs
        Should the 'prepalldocs' be allowed in current EAPIs?

        Conclusion:
            Prepalldocs is banned in current EAPIs(0,1,2). It should be
            removed from ebuilds. Petteri Räty(Betelgeuse) will make QA
            checks for repoman.

Open Bugs
=========

Technical:
    - GLEP 54(-scm package version suffix)
        There are two approaches to the problem of version ordering with
        so-called 'live' packages, '-scm' and 'properties=live'.o

        Conclusion:
            No decision. The council cracked the whip on Luca(lu_zero) and
            he's going to handle the issue.

    - GLEP 55(.ebuild-$eapi ebuild suffix)
        Should .ebuild-$eapi be approved?

        Conclusion:
            No decision. Tiziano(dev-zero) will be handling this bug.

Non-Technical:
    - Code of Conduct
        No discussion.

        Conclusion:
            No decision. Donnie(dberkholz) will be handling this bug.

Re: [gentoo-council] Council log and summary for meeting on 02/12/09

[Thomas Anderson]

On Thu, Feb 12, 2009 at 04:49:25PM -0500, Thomas Anderson wrote:

As I'm sure you've noticed, my dates are not UTC. I've fixed that
locally. Sorry about that.

Re: [gentoo-council] Council log and summary for meeting on 02/12/09

[Tiziano Müller]

[-- Attachment #1: Type: text/plain, Size: 881 bytes --]

Am Donnerstag, den 12.02.2009, 16:49 -0500 schrieb Thomas Anderson:
> They are attached.

Looks good, I'm missing a couple of things (like my comments about
having the rules (and obligation) to choose a Secretary on the council
page, but that's fine since we decided that this should be discussed on
the -council ml anyway.

Really missing in the summary is the bash-in-the-tree issue which we
didn't discuss. Cardoe will formally take care of it with me as a backup
(since he still has limited connectivity due to the moving).

Thanks a lot for your work,
Cheers,
Tiziano

-- 
-------------------------------------------------------
Tiziano Müller
Gentoo Linux Developer, Council Member
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin
E-Mail     : dev-zero@gentoo.org
GnuPG FP   : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-council] Council log and summary for meeting on 02/12/09

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 2146 bytes --]

On 16:49 Thu 12 Feb     , Thomas Anderson wrote:
> Secretary:
>     - Should the council have a dedicated secretary?
>         Previously dberkholz fulfilled this roll, but he became busy.
> 	Because fulfilling the secretary duties can distract from the
> 	meeting, a dedicated, non-council member secretary is ideal.
> 	tanderson(gentoofan23) volunteered and is the new secretary.

You don't need to say this twice (once here and once below). Delete this one.

> 	Conclusion:
> 	   tanderson is the new secretary. Logs and summary are to be
> 	   posted on the -council mailing list. If no objections to it
> 	   are raised in 1 day, it is posted to to council page.

"posted to the council page and lists." (only one "to" and add "lists")

Please post to -dev, -dev-announce, and -council (set Reply-To: 
-council). Take a look at the summaries I've sent, for example:

To: gentoo-council@lists.gentoo.org
Cc: gentoo-dev@lists.gentoo.org, gentoo-dev-announce@lists.gentoo.org
Subject: [gentoo-council] Council meeting summary for 23 October 2008

Hi all,

Here is the summary from Thursday's council meeting. The complete log
will show up at http://www.gentoo.org/proj/en/council/ shortly.

> 	Conclusion:
> 	    If the pseudo-candidate '_reopen_nominations' appears in 7th place
> 	    or higher those candidates that rank above '_reopen_nominations'
> 	    will be the current council. A second period of nominations will
> 	    be opened for the remaining council seats.

We also agreed that 2 is enough, and we wouldn't have a 3rd.

> Technical:
>     - GLEP 54(-scm package version suffix)
>         There are two approaches to the problem of version ordering with
>         so-called 'live' packages, '-scm' and 'properties=live'.o

I think this could be phrased better. For example, what are the problems 
GLEP 54 is trying to fix? Version ordering is not the only one. Which of 
those overlap with PROPERTIES=live? How about the other suggested 
solution on the bug, the .live thing?

-- 
Thanks,
Donnie

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-council] Council log and summary for meeting on 02/12/09

[Luca Barbato]

Thomas Anderson wrote:
> They are attached.
> 
Missing reference to

- migration path http://dev.gentoo.org/~lu_zero/glep/migrationpath.rst
- live templates http://dev.gentoo.org/~lu_zero/glep/liveebuild.rst
- related bug http://bugs.gentoo.org/show_bug.cgi?id=234711

lu

PS: do we have a bug for glep 55 related stuff?

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

[gentoo-council] prepalldocs (was: Council log and summary for meeting on 02/12/09)

[Torsten Veller]

* Thomas Anderson <gentoofan23@gentoo.org>:
> Technical Issues:
>     - Prepalldocs
>         Should the 'prepalldocs' be allowed in current EAPIs?
> 
>         Conclusion:
>             Prepalldocs is banned in current EAPIs(0,1,2). It should be
>             removed from ebuilds. Petteri Räty(Betelgeuse) will make QA
>             checks for repoman.

You only did half of your job.

Do we want some docs being compressed, others not?
Do we want to have compressed docs at all?
What do you expect from maintainers now?

To me it means: Instead of using prepalldocs I will move the docdir to
a temporary place and dodoc every file back to docdir. Insane.
Maybe I add a function named prepalldocs to the ebuilds that does the job.

Thanks.

Re: [gentoo-council] Council log and summary for meeting on 02/12/09

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 1063 bytes --]

Donnie Berkholz wrote:
> On 16:49 Thu 12 Feb     , Thomas Anderson wrote:
>> Secretary:
>>     - Should the council have a dedicated secretary?
>>         Previously dberkholz fulfilled this roll, but he became busy.
>> 	Because fulfilling the secretary duties can distract from the
>> 	meeting, a dedicated, non-council member secretary is ideal.
>> 	tanderson(gentoofan23) volunteered and is the new secretary.
> 
> You don't need to say this twice (once here and once below). Delete this one.
> 
>> 	Conclusion:
>> 	   tanderson is the new secretary. Logs and summary are to be
>> 	   posted on the -council mailing list. If no objections to it
>> 	   are raised in 1 day, it is posted to to council page.
> 
> "posted to the council page and lists." (only one "to" and add "lists")
> 
> Please post to -dev, -dev-announce, and -council (set Reply-To: 
> -council). Take a look at the summaries I've sent, for example:
> 

Why can't we follow the normal policy of selecting only one mailing list
+ -dev-announce?

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: [gentoo-council] prepalldocs

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 1128 bytes --]

Torsten Veller wrote:
> * Thomas Anderson <gentoofan23@gentoo.org>:
>> Technical Issues:
>>     - Prepalldocs
>>         Should the 'prepalldocs' be allowed in current EAPIs?
>>
>>         Conclusion:
>>             Prepalldocs is banned in current EAPIs(0,1,2). It should be
>>             removed from ebuilds. Petteri Räty(Betelgeuse) will make QA
>>             checks for repoman.
> 
> You only did half of your job.
> 
> Do we want some docs being compressed, others not?
> Do we want to have compressed docs at all?
> What do you expect from maintainers now?
> 
> To me it means: Instead of using prepalldocs I will move the docdir to
> a temporary place and dodoc every file back to docdir. Insane.
> Maybe I add a function named prepalldocs to the ebuilds that does the job.
> 
> Thanks.
> 

Please read the logs. prepalldocs has no clearly defined behavior so it
should not be used by ebuilds. Maintainers should use the public APIs
available to them. If they have a justified need beyond those, they
should open a request for adding needed things to the next EAPI.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

[gentoo-council] Re: prepalldocs

[Torsten Veller]

* Petteri Räty <betelgeuse@gentoo.org>:
> Torsten Veller wrote:
> > * Thomas Anderson <gentoofan23@gentoo.org>:
> >> Technical Issues:
> >>     - Prepalldocs
> >>         Should the 'prepalldocs' be allowed in current EAPIs?
> >>
> >>         Conclusion:
> >>             Prepalldocs is banned in current EAPIs(0,1,2). It should be
> >>             removed from ebuilds. Petteri Räty(Betelgeuse) will make QA
> >>             checks for repoman.
> > 
> > You only did half of your job.
> > 
> > Do we want some docs being compressed, others not?
> > Do we want to have compressed docs at all?
> > What do you expect from maintainers now?
> > 
> > To me it means: Instead of using prepalldocs I will move the docdir to
> > a temporary place and dodoc every file back to docdir. Insane.
> > Maybe I add a function named prepalldocs to the ebuilds that does the job.
> > 
> > Thanks.
> 
> Please read the logs.

| 15:35 < dev-zero> prepalldocs should be kept internal and usage should be avoided
| 15:36 < dev-zero> reason: internal function and change of it's implementation prooves it
| 15:36 < dev-zero> if someone want's it's functionality he should propose a solution for a future eapi

It is not an internal function. And it's a strange way to prove anything.
Around 250 ebuilds use it. So there is probably someone who actually uses this functionality.

> prepalldocs has no clearly defined behavior so it should not be used
> by ebuilds.

It was possible to rectify it. You chose to remove the function completely.

> Maintainers should use the public APIs available to them.

It's in ebuild.5 for years.
And as recruiting lead you probably know that the Developer Handbook contains it as well
<http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1>.

> If they have a justified need beyond those, they should open a request
> for adding needed things to the next EAPI.

I will probably do it after i got answers to the questions above.

Thanks.

Re: [gentoo-council] Re: prepalldocs

[Thomas Anderson]

On Fri, Feb 13, 2009 at 02:40:39PM +0100, Torsten Veller wrote:
> It was possible to rectify it. You chose to remove the function completely.

As was pointed out, since portage changed the functionality between
releases, it was easier to eliminate it entirely from current EAPIs and
allow for a proposal(with definite functionality and implementation) to
be made for a future EAPI.

Re: [gentoo-council] Re: prepalldocs

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 1566 bytes --]

Torsten Veller wrote:
> 
> | 15:35 < dev-zero> prepalldocs should be kept internal and usage should be avoided
> | 15:36 < dev-zero> reason: internal function and change of it's implementation prooves it
> | 15:36 < dev-zero> if someone want's it's functionality he should propose a solution for a future eapi
> 
> It is not an internal function. And it's a strange way to prove anything.
> Around 250 ebuilds use it. So there is probably someone who actually uses this functionality.
> 

And what functionality is that exactly? It's not like we would have
mandated the removal of prepalldocs from Portage. How do you propose
other PMs would implement prepalldocs when you have no idea which
behavior the ebuild authors were expecting at the time they wrote their
ebuilds?

More discussion happened in the meeting before the one yesterday I think.

>
>> Maintainers should use the public APIs available to them.
> 
> It's in ebuild.5 for years.
> And as recruiting lead you probably know that the Developer Handbook contains it as well
> <http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1>.
> 

If someone would have put the work into it that doc would have died ages
ago. Any way I changed the text there to mention that new ebuilds should
not use it.

> 
> I will probably do it after i got answers to the questions above.
> 
> Thanks.
> 

I would much rather see the energy put into creating a well specified
replacement for prepalldocs than trying to get prepalldocs to behave.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: [gentoo-council] Council log and summary for meeting on 02/12/09

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 542 bytes --]

On 14:08 Fri 13 Feb     , Petteri Räty wrote:
> Donnie Berkholz wrote:
> > Please post to -dev, -dev-announce, and -council (set Reply-To: 
> > -council). Take a look at the summaries I've sent, for example:
> > 
> Why can't we follow the normal policy of selecting only one mailing list
> + -dev-announce?

The goal is to get everyone seeing it. If you think people won't miss it 
if it doesn't show up on -dev, that's fine.

-- 
Thanks,
Donnie

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-council] Council log and summary for meeting on 02/12/09

[Thomas Anderson]

[-- Attachment #1: Type: text/plain, Size: 138 bytes --]

On Thu, Feb 12, 2009 at 04:49:25PM -0500, Thomas Anderson wrote:
> They are attached.

Revised summary attached, thanks for the comments.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: councilsummary-20090212.txt --]
[-- Type: text/plain; charset=unknown-8bit, Size: 3613 bytes --]

Roll Call:
===========
Betelgeuse: here
Cardoe: here
dberkholz: here
dertobi123: here
dev-zero: here
Halcy0n: absent
lu_zero: here
tanderson(secretary): here

Topics:
===========

Secretary:
    - Should the council have a dedicated secretary?
        Previously dberkholz fulfilled this roll, but he became busy.
	Because fulfilling the secretary duties can distract from the
	meeting, a dedicated, non-council member secretary is ideal.

	Conclusion:
	   tanderson is the new secretary. Logs and summary are to be
	   posted on the -council mailing list. If no objections to it
	   are raised in 1 day, it is posted to the council page and lists.

Elections:
    - Staggered elections
    	Should there be staggered elections every 6 months where half the
	    council members stand for reelection?

	Conclusion:
	    Leave as-is, elections every 6 months is too cumbersome. Full elections
        will be held once a year.

    - Lack of nominated candidates
    	What happens if there aren't enough candidates nominated to fill all
	    the council seats?

	Conclusion:
	    If the pseudo-candidate '_reopen_nominations' appears in 7th place
	    or higher those candidates that rank above '_reopen_nominations'
	    will be the current council. A second period of nominations will
	    be opened for the remaining council seats. No third period of
	    nominations will be opened in the event '_repoen_nominations'
	    ranks higher than the candidates necessary to fill the council.

Technical Issues:
    - Prepalldocs
        Should the 'prepalldocs' be allowed in current EAPIs?

        Conclusion:
            Prepalldocs is banned in current EAPIs(0,1,2). It should be
            removed from ebuilds. Petteri Räty(Betelgeuse) will make QA
            checks for repoman.

    - BASH version allowed in the tree.
        PMS states that ebuilds can only rely on BASH 3.0 features. However,
        some code in gentoo-x86 uses BASH 3.1 features('+=' being the most
        notable) and so is not in conformance with PMS. It was suggested that
        BASH versions newer than 3.0 be allowed in a future EAPI. Ciaran
        Mccreesh, however, commented that this would require GLEP 55 being
        accepted so that a package manager would not have to source the ebuild
        before knowing what BASH version it requires.

        Conclusion:
            No decision. Doug(Cardoe) will follow this up with
            Tiziano(dev-zero) as a backup.

Open Bugs
=========

Technical:
    - GLEP 54(-scm package version suffix, bug 234711[1])
	    GLEP 54 solves two problems, version ordering and periodic reinstall
	    of live packages. The Live Template proposal[2] overlaps in that it also
	    allows for periodic reinstall of live packages. The Live Template Proposal
        does not, however, provide correct ordering.

        Conclusion:
            No decision. The council cracked the whip on Luca(lu_zero) and
            he's going to handle the issue.

    - GLEP 55(.ebuild-$eapi ebuild suffix)
        Should .ebuild-$eapi be approved? This ties in with "BASH version
        allowed in the tree" issue mentioned above.

        Conclusion:
            No decision. Tiziano(dev-zero) will be handling this bug.

Non-Technical:
    - Code of Conduct
        No discussion.

        Conclusion:
            No decision. Donnie(dberkholz) will be handling this bug.

References:
[1]: http://bugs.gentoo.org/show_bug.cgi?id=234711
[2]: http://dev.gentoo.org/~lu_zero/glep/liveebuild.rst

Re: [gentoo-council] Council log and summary for meeting on 02/12/09

[Luca Barbato]

Thomas Anderson wrote:
> On Thu, Feb 12, 2009 at 04:49:25PM -0500, Thomas Anderson wrote:
>> They are attached.
> 
> Revised summary attached, thanks for the comments.
> 

Live template provide correct ordering since generates ebuilds with a 
proper version.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

Re: [gentoo-council] Council log and summary for meeting on 02/12/09

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 590 bytes --]

On Fri, 13 Feb 2009 18:20:34 +0100
Luca Barbato <lu_zero@gentoo.org> wrote:
> Live template provide correct ordering since generates ebuilds with a 
> proper version.

*sigh* Please stop pushing your epic fail of a non-solution until you
understand the issue at hand.

There is no way of using conventional version rules to accurately
represent scm versions across multiple version-branches. _pre does not
order correctly, since you don't know what the next release will be,
and it collides with upstream release names.

We have been over this before.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-council] Council log and summary for meeting on 02/12/09

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 636 bytes --]

Donnie Berkholz wrote:
> On 14:08 Fri 13 Feb     , Petteri Räty wrote:
>> Donnie Berkholz wrote:
>>> Please post to -dev, -dev-announce, and -council (set Reply-To: 
>>> -council). Take a look at the summaries I've sent, for example:
>>>
>> Why can't we follow the normal policy of selecting only one mailing list
>> + -dev-announce?
> 
> The goal is to get everyone seeing it. If you think people won't miss it 
> if it doesn't show up on -dev, that's fine.
> 

All devs are on announce and for users there are better places like GMN
than gentoo-dev so using announce and council is better IMHO.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: [gentoo-council] Council log and summary for meeting on 02/12/09

[Luca Barbato]

Ciaran McCreesh wrote:
> On Fri, 13 Feb 2009 18:20:34 +0100
> Luca Barbato <lu_zero@gentoo.org> wrote:
>> Live template provide correct ordering since generates ebuilds with a 
>> proper version.
> 
> *sigh* Please stop pushing your epic fail of a non-solution until you
> understand the issue at hand.

go back to 4chan.

> There is no way of using conventional version rules to accurately
> represent scm versions across multiple version-branches. _pre does not
> order correctly, since you don't know what the next release will be,
> and it collides with upstream release names.

pre works perfectly fine with snapshots.

you cannot track separate branches/versions w/out the very same issues 
you have merging separate versions of normal packages, and glep54 
doesn't say anything about how it should track multiple branches in any 
different way than the current version components.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

Re: [gentoo-council] Council log and summary for meeting on 02/12/09

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1526 bytes --]

On Fri, 13 Feb 2009 20:33:31 +0100
Luca Barbato <lu_zero@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> > On Fri, 13 Feb 2009 18:20:34 +0100
> > Luca Barbato <lu_zero@gentoo.org> wrote:
> >> Live template provide correct ordering since generates ebuilds
> >> with a proper version.
> > 
> > *sigh* Please stop pushing your epic fail of a non-solution until
> > you understand the issue at hand.
> 
> go back to 4chan.

No. Really. You need to step back and think before you try to solve a
problem.

> > There is no way of using conventional version rules to accurately
> > represent scm versions across multiple version-branches. _pre does
> > not order correctly, since you don't know what the next release
> > will be, and it collides with upstream release names.
> 
> pre works perfectly fine with snapshots.

No it doesn't. _pre1, _pre2 etc does not accurately represent how
upstream do releases.

> you cannot track separate branches/versions w/out the very same
> issues you have merging separate versions of normal packages, and
> glep54 doesn't say anything about how it should track multiple
> branches in any different way than the current version components.

Uh... There's no merging involved. And GLEP 54 solves the entire thing.
It lets you have foo-scm tracking master, foo-2.0-scm tracking the 2.0
branch and foo-1.0-scm tracking the 1.0 branch, and the ordering all
works correctly. It's the only solution anyone's come up with that gets
this right.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]