path: root/meeting-logs/20080410.txt

19:55 <    tsunam > all full now
19:59  *     amne reports in
20:00 <Philantrop > amne: You're one minute early!
20:00 <    tsunam > amne: don't leave a hanging chad on your clock in...else you'll not be counted as in
20:00 <    tsunam > <----proxy for Diego
20:01 <      amne@> tsunam: ack, he sent an email about it
20:01 < dberkholz@> i'm having some issues building the latest pms, just got a slightly older version, could someone post a pdf
20:02 <       spb > did he give a reason he can't appear?
20:02 < dberkholz@> he's sick
20:02 <Betelgeuse@> I will hit the toiled and join then.
20:02 <      amne@> Betelgeuse: TMI :-P
20:02 <   astinus > Betelgeuse: toiled? You going Welsh on us? ;)
20:03 <   Halcyon > http://dev.gentoo.org/~spb/pms.pdf
20:03 <Betelgeuse@> astinus: Whatever let's call it paskahuussi then.
20:03 <   ciaranm > http://paludis.pioto.org/~ciaranm/pms.pdf
20:03 <   ciaranm > is probably a few days more up to date than spb's version
20:04 < dberkholz@> thanks
20:05 <      amne@> Agenda: http://archives.gentoo.org/gentoo-dev/msg_46bf3619625ec081d4c5c858e375c011.xml
20:05 <      amne@> dberkholz: or do you have it somewhere on your devspace?
20:06 < dberkholz@> hasn't change since i posted it =)
20:06 < dberkholz@>  changed*
20:06 -!- amne changed the topic of #gentoo-council to: Meeting now - Agenda: http://archives.gentoo.org/gentoo-dev/msg_46bf3619625ec081d4c5c858e375c011.xml
20:06 <      amne@> dev-zero said he may be able to show up, but earlierst in half an hour an probably later
20:07 <      amne@> so i'd suggest we move glep 46 towards the end and hope he can make it
20:08 < dberkholz@> we could just figure out whether we have any questions, if so wait, if not just get through it
20:08 -!- Irssi: #gentoo-council: Total of 69 nicks [5 ops, 0 halfops, 1 voices, 63 normal]
20:08 < dberkholz@> we're still missing a few folks
20:08 <    vapier@> moo
20:08 < dberkholz@> lu_zero and jokey aren't even in the channel..
20:08 <    vapier@> guess i'll be back in an hour
20:09 <    vapier@> or not
20:09 <Betelgeuse@> back
20:10 < dberkholz@> we might as well get on with the first stuff and see if lu and jokey show up soon
20:10 < dberkholz@> vapier: any news on the slacker archs idea?
20:10 <    vapier@> i'm finishing it up ... have it posted tonight
20:11 < dberkholz@> great!
20:12 < dberkholz@> still nothing i know of for araujo's active dev documentation. it's on him to start making some progress if he cares about it
20:13 -!- mode/#gentoo-council [+o jokey] by ChanServ
20:13 <      amne@> oi jokey
20:13 <     jokey@> meh, should update my reminder
20:13 -!- Irssi: #gentoo-council: Total of 72 nicks [6 ops, 0 halfops, 1 voices, 65 normal]
20:13 < dberkholz@> well, that's 6 at least
20:14 < dberkholz@> does anyone have questions on glep 46, or are we ready to vote?
20:14 <NeddySeago > dberkholz, with 2 missing, is this meeting quorate ?
20:14 < dberkholz@> NeddySeagoon: 1 missing ... tsunam is proxy for flameeyes
20:14  *    jokey doesn't have any questions
20:14 <      amne@> since the stuff suggested last time was implemented it works for me, no further questions
20:16 -!- mode/#gentoo-council [+v tsunam] by dberkholz
20:16 < dberkholz@> maybe that'll prevent some confusion
20:16 -!- Irssi: #gentoo-council: Total of 73 nicks [6 ops, 0 halfops, 2 voices, 65 normal]
20:16 < dberkholz@> Betelgeuse, tsunam, vapier -- any glep 46 questions?
20:17 <    tsunam+> none here
20:17 <Betelgeuse@> no
20:19 <      amne@> time to vote then?
20:19 < dberkholz@> ok. let's vote, then. glep 46 -- yes or no
20:19 < dberkholz@> yes
20:19 <      amne@> yes
20:19 <    tsunam+> yes
20:20 <Betelgeuse@> yes
20:21 < dberkholz@> jokey, vapier -- care to vote?
20:21 <     jokey@> yes
20:23 < dberkholz@> alright, that's 5 yes votes, 1 abstain 
20:23 < dberkholz@> let's move on to the next topic
20:23 < dberkholz@> Minimal activity for ebuild devs: Current is 1 commit every 60 days. Should it be higher?
20:23 <     jokey@> yep
20:24 <     jokey@> imho every dev should be able to do 4-5 commits every month
20:24 <    tsunam+> I would say at least one a month should be a basis
20:24 <    tsunam+> If a developer only maintains a package or two, and they don't update often...
20:25 <      amne@> while i agree with all the shoulds, what's the positive effect for gentoo if we do that?
20:25 <     jokey@> amne: main issue is that quite a bunch of packages have a number of bugs open, then maintainer appears, does a commit and hides again
20:26 <Philantrop > What's the *reason* to change that? Does a dev with "only" one commit every 60 days hurt anyone?
20:26 <    tsunam+> Philantrop: you have a point there
20:26 <      amne@> jokey: then we should address that problem, as well as being unresponsive and letting packages bit-rot while others were willing to take over
20:26 <Philantrop > jokey: And with your suggestion not even that one bug will be taken care of. :-)
20:26 <      amne@> jokey: i just don't think introducing an arbituary number of commits will help with that
20:27 <    tsunam+> amne: that's a larger issue with "posession"
20:27 < dberkholz@> so do you think it should be more of a case-by-case thing?
20:27 <      amne@> tsunam: yeah, heh
20:27 <      amne@> dberkholz: yes
20:27 <Betelgeuse@> The point of the suggestion was to give undertakers the powers to start poking with lesses activity.
20:27 < dberkholz@> some devs have this obvious trend of drive-by commits and then disappearing
20:27 <     jokey@> I mean if you're really interested in working as a dev, why don't actually do something?
20:27 <Betelgeuse@> We don't really need to start arbitrary limits if we trust undertaker judgment.
20:28 <      amne@> Betelgeuse++
20:28 <     jokey@> Betelgeuse++
20:28 <    musikc > Betelgeuse, undertakers is phreak and rane atm, and neither seemed to have wanted this
20:28 <    tsunam+> does the new items increase the load of some of our teams
20:28 <    tsunam+> such as undertakers and infra
20:28 < dberkholz@> musikc: "this" being a higher limit?
20:28 <    tsunam+> as there will be more tracking to do and poking and
20:28 <    tsunam+> just general pain in the arse busy work as well
20:28 <    musikc > increases for undertakers, saying 60 days to 7 days means more work
20:28 <    tsunam+> cause really it is busy work
20:29 <Philantrop > jokey: Most of you don't have a job or a family. Some of us older ones have and, thus, different priorities while Gentoo is still important to us.
20:29 <    vapier@> dberkholz: sorry, yes to 46
20:29 <    vapier@> btw, the e-mails are wrong in the glep
20:29 <    vapier@> in case anyone cares ;)
20:29 <     jokey@> Philantrop: looking at your stats, even you managed to do more than 5 commits ;)
20:30 <     jokey@> and if one is away for a month for whatever reason, we have devaway
20:30 <Philantrop > jokey: Yes, but I'm an idiot. :)
20:31 < dberkholz@> musikc: but if it was 1/60 days to 8/60 days, it would be the same work with a different number
20:31 <Betelgeuse@> musikc: I thought rane liked my script.
20:31 <jmbsvicett > musikc / dberkholz: I saw rane comment that he didn't want to the one to have to do the judgement
20:31 <    musikc > i like Philantrop's point though, many devs have full time jobs or substantial college obligations, in addition to family and trying to have a life some of the time. once a week is a lot and do we really want to lose those few commits entirely
20:31 <Betelgeuse@> I would propose we make the slacker script output the activity of everyone and post it to public.
20:31 <jmbsvicett > musikc / dberkholz: As I understood it, he wanted a clear policy
20:31 <    tsunam+> Can it not be said that we increase it slowly?
20:31 <    tsunam+> start with say 2 ever 60
20:31 <    musikc > jmbsvicetto, he wanted a clear policy when people started saying policy was going to change; he said he wanted to know what the change would be
20:32 <    tsunam+> then revisit it some months down...
20:32 < dberkholz@> to build on what Betelgeuse said earlier, isn't this something that is just not a council decision, but rather undertaker policy?
20:32 <    musikc > Betelgeuse, rane told me he did not want to have to sort through extra information
20:32 <jmbsvicett > I would also like to point out that the script only looks at cvs - no svn or git
20:32 <Betelgeuse@> dmwaters: imho council should set undertaker policy
20:32 <      rane > i like tsunam's proposal the most, a slight increase, say 4 commits per 60 days
20:33 <      rane > and we'll see what happens
20:33 <Betelgeuse@> s/dmwaters/dberkholz/
20:33 <jmbsvicett > That means most (almost all?) overlays don't count
20:33 <    musikc > what about cvs and svn, does the script include both?
20:33 <NeddySeago > comitts alone are a poor measure. A dev with one or two packages rare upstream updates and no bugs has no reason to commit
20:33 <    tsunam+> hmm
20:33 <Betelgeuse@> musikc: the script was posted to -dev and it does not do svn yet
20:33 <Betelgeuse@> musikc: but neither does the current script
20:33 < dberkholz@> NeddySeagoon: my question would be, why isn't that dev doing more?
20:33 <Betelgeuse@> NeddySeagoon: That's why there is the manual step.
20:33 <    tsunam+> the question also becomes how many commits will happen just to "commit"
20:33 <    tsunam+> if it increases
20:34 <      amne@> how about not taking in the positive count (like commits) but rather negative stats like being unresponsive for long times without devaway etc?
20:34 <jmbsvicett > Betelgeuse: My point about svn / git is that it probably should count
20:34 <Betelgeuse@> NeddySeagoon: It's not run script --> autoretire
20:34 <    tsunam+> is it a quality or a quantity that we are after?
20:34 <  blackace > why is there such a focus on getting rid of slacking devs?  surely rather a slacker dev than no dev at all?  or is a .forward on woodpecker so expensive?
20:34 <     jokey@> tsunam: both
20:34 < dberkholz@> i mean c'mon, if all i maintained was colordiff, that would be pretty sad.
20:34 <NeddySeago > Betelgeuse, I understand that.
20:34 <Betelgeuse@> blackace: Because coming back is easy.
20:34 <    tsunam+> dberkholz: by all accounts I maintain nothing in the tree...I do help on some packages though
20:35 < dberkholz@> my feeling is that low commit count may mean that the dev isn't doing enough stuff to maintain his/her quality level
20:35 <NeddySeago > dberkholz, no time ? no interest in other stuff ?  The measure needs to include open bugs
20:35 <    musikc > Betelgeuse, if the intent is to improve, we should try to include both
20:35 <    vapier@> perhaps if the proxy stuff was more streamlined, there wouldnt be a need for drive by devs
20:35 <Betelgeuse@> blackace: Also it does require some attention to keep up with latest ebuild standards.
20:35 <  blackace > Betelgeuse: every 60 days?  seems like that would be a waste of time for undertakers
20:35 <Philantrop > dberkholz: And you want undertakers to judge on the dev's skills/quality level?
20:36 < dberkholz@> maybe instead of retiring these devs, we should make sure their commits get reviewed
20:36 <Betelgeuse@> dberkholz: They don't get retired if they answer a simple mail atm.
20:36 <    musikc > all, sorry but i have another meeting to go to. again im agreeable to an increase, say at least once a month instead of 2 months, and continue to allow undertakers to talk to the dev and their leads to determine real involvement, commits alone arent all that happens around here
20:36 <  blackace > dberkholz: that would actually be a great idea, gentoo has a severe lack of code review...maybe we could use a reviewboard
20:36 < dberkholz@> Betelgeuse: ok, that doesn't really address my concern one way or the other, though
20:37 <Betelgeuse@> blackace: Anyone can do it via gentoo-commits mailing list.
20:37 < dberkholz@> it would be pretty easy on an individual level to take the commit-count script output and use some cutoff as a procmail filter for rare committers
20:37 <Betelgeuse@> I wouldn't mandate review as we have enough problems keeping stuff up2date as it is.
20:38 <Betelgeuse@> dberkholz: Yes, I can setup something like that with robbat2 when he has the time.
20:38 <Betelgeuse@> dberkholz: We will already be setting up new develop watching at some point any way.
20:38 <Betelgeuse@> He's just damn busy.
20:40 < dberkholz@> vapier: i'm hoping that we can get some sort of dscm going in the not-distant future to help that
20:40 <kingtaco|w > dberkholz, would you write some procmail foo for that in any event?  that info would be useful in general
20:41 < dberkholz@> kingtaco|work: does woodpecker allow user cron jobs?
20:41 <kingtaco|w > dberkholz, no, but I can make an exception for something like this
20:41 < dberkholz@> what we'd want to do is periodically grab the list and insert an update.
20:41 < dberkholz@> anyway, details for discussion elsewhere
20:42 <kingtaco|w > WFM
20:42 <     jokey@> though I like the idea of just posting stats to -dev ml (or some other list if needed)
20:42 <     jokey@> that way you can easily stab your fellow to do somethin ;)
20:43 <    tsunam+> I would not like that honestly
20:43 <    tsunam+> we shouldn't rat out/ paint our own developers with bright red paint
20:43 < dberkholz@> i think it would be neat to have a commit stats page around
20:43 <nightmorph > just to clarify -- this minimum commit requirement is strictly for ebuild devs, correct?
20:43 <    tsunam+> the point isn't to drive people away
20:43 <    tsunam+> its to gently nudge them into commiting more if possible
20:43 <     jokey@> nightmorph: yep
20:43 <     jokey@> tsunam: exactly
20:44 <    tsunam+> but as musikc said, what a developer commits isn't always all they have worth for
20:44 <     jokey@> and if a (good) friend of yours nudges you, the chance you actually do something is way higher imho
20:44 <Betelgeuse@> tsunam: The info is available via anoncvs any way.
20:45 <    tsunam+> Betelgeuse: but its not Tsunam has done : 2 commits these last 2 months
20:45 <Philantrop > jokey: And chances are higher that commit competitions are the result. Great for quality, I'm sure. :-)
20:45 <    tsunam+> and having say...spb, Betelgeuse, vapier, blackace all go Dude COMMIT MORE! YOU SUCK!
20:45 <Betelgeuse@> tsunam: I am going to add gentooRoles to the script and from that it should be quite clear if someone should commit or not.
20:46 <      rane > blackace who didn't commit anything in last 6 months is quite unlikely to bash for lack of commits
20:46 <    tsunam+> Betelgeuse: how accurate are the gentooRoles
20:46 <  blackace > rane: yeah, I'm not one to talk ;)
20:46 <    tsunam+> Betelgeuse: I'm sure mine are nowhere close to be honest
20:46 <     jokey@> Philantrop: that's why we have a commit mailinglist for public review
20:46 <Betelgeuse@> tsunam: probably not that but one can always change them
20:46 < dberkholz@> where "public" seems to mean "donnie reviews" in most cases.. =P
20:47 <  blackace > rane: but then, I don't have cvs access anymore either...any script looking at commits should take into account permission to commit
20:47 <nightmorph > it's already noted that nothing is checking for SVN commits i believe
20:48 <    tsunam+> there are quite a few catchpa's *nods*
20:48 <    tsunam+> ultimately its up to the undertakers to decide the relative merits
20:48 <    tsunam+> with assistance from a script and discussion with the developer in question
20:49 <Betelgeuse@> Perhaps we should mail the results to -core.
20:49 <    tsunam+> Where capable, I don't think 1 commit a month is asking too much, even from a dedicated father/employee/ grad student/college student+part time worker
20:49 <Betelgeuse@> As things like KDE keywording would be missleading to the public.
20:51 <    tsunam+> s/father/parent/
20:51 <Philantrop > tsunam: Just a minimal summary to make sure I understand this: There's no real identifiable benefit but literally something to lose - commits, devs, maintainership. And yet we want to ask for more?
20:51 < dberkholz@> for all of our committing mothers. =)
20:52 < dberkholz@> Philantrop: i pointed out the potential problems with code quality
20:52 <    tsunam+> Philantrop: dberkholz's point, as well as the mattter of 1 commit in 60 days is 6 commits a year. How much real benefit is there in that potential?
20:53 <NeddySeago > if the script is an undertakers aid, let undertakers set the limits so its useful to them
20:53 <  blackace > dberkholz: code quality is pretty much impossible to solve with any blanket rule though
20:53 < dberkholz@> anyway, more tests could be done here. for example, how many devs would this actually affect, over the course of the last year?
20:53 <jmbsvicett > dberkholz: I think the "quality" problems should be addressed directly and not through commits - that's something for qa
20:53 <    tsunam+> aye
20:53 <    tsunam+> Halcyon: thoughs on the qa aspect of that?
20:54 <Betelgeuse@> Philantrop: Rotting bugs in bugzilla?
20:54 <Philantrop > tsunam: I say, we should take what we get. Better than nothing.
20:54 < dberkholz@> jmbsvicetto: depends on whether there's correlation, and that's hard to say right now
20:54 <Philantrop > Betelgeuse: And by getting rid of devs we solve that problem?
20:54 <Betelgeuse@> Philantrop: at least they go to maintainer-wanted
20:55 <   Halcyon > Philantrop: getting rid of them reveals the truth that we don't have people working on things.
20:55 <Betelgeuse@> instead of the user expecting someone to act
20:55 <Philantrop > Betelgeuse: People will expect some of us to act anyway if the package is in the tree. And they're right.
20:55 <   Halcyon > tsunam: which part?
20:55 <Betelgeuse@> Could also be easier to recruit new people when our developer stats are truthful.
20:55 <    tsunam+> Betelgeuse: would you agree, that maintainer-wanted is bit-rot as well?
20:55 <Philantrop > Halcyon: That's why I fired half of the KDE herd recently.
20:55 <Betelgeuse@> tsunam: it is
20:55 <    tsunam+> Halcyon: the qa with quality
20:56 <   Halcyon > tsunam: with devs putting things into the tree that are subpar?
20:56 <    tsunam+> Halcyon: yes as that was an issue discussed about people who seldom commit
20:56 <   Halcyon > tsunam: we have that problem now anyway, with people that are active...
20:57 <    tsunam+> so you consider it a non issue then as there is not a visual difference with people who commit frequently vs infrequently
20:57 <   Halcyon > Not really.  They might be more prone to screwing up, but that's not something we can easily address.
20:57 <    tsunam+> Well there you go
20:58 <   Halcyon > Having easily available documentation and improving our qa tools is really the only way.
20:58 <   Halcyon > I can't force people to read policy or documentation though.
20:58 <    tsunam+> Its  sounding like "put this in the hands of the undertakers to decide"
20:58 <    tsunam+> as there is no consensus
20:58 <    tsunam+> and its up to them ultimately
20:59 <      rane > so let's double what we have now (like musikc suggested) and see what happens
21:00 < dberkholz@> heh, ramp it all the way up to once a month? that seems extreme to me =P
21:01  *   tsunam has a feeling the discussion is done on the matter
21:02 <Betelgeuse@> So what about mailing the slacker script to -core?
21:02 < dberkholz@> tsunam: that is a consensus
21:02 <jmbsvicett > Betelgeuse: np with that
21:02 <    tsunam+> I'd vote no on the mailing the slacker script to core
21:04 <    vapier@> why e-mail ?  just put it on the web
21:04 <    vapier@> this isnt magic hidden data
21:05 <    vapier@> anyone can calculate it
21:05 < dberkholz@> 20:43 < dberkholz@> i think it would be neat to have a commit stats page around
21:05 <   astinus > cia.vc?
21:05 <   astinus > why reinvent the wheel?
21:05 <     jokey@> astinus: way too much offline
21:05 <     jokey@> aka not accurate
21:05 <    tsunam+> dberkholz: like http://tsunam.org/gentoo-dev.html?
21:06 < dberkholz@> ohloh might do it
21:06 <    vapier@> which may eventually hit the same problem as cia
21:06 <   ciaranm > ohloh can't handle gentoo-x86 at all until someone sends them a cvs dump of the entire repo
21:06 < dberkholz@> tsunam: among other things. kinda like the lwn article i wrote a while back anyway
21:06 <    vapier@> people seem to be jumping onto ohloh
21:09 <     jokey@> other option would be we fetch cia sources and run  that page on our own servers
21:09 <     jokey@> as the sources are public anyway
21:09 <Betelgeuse@> vapier: The results can be a bit missleading.
21:10 <   ciaranm > and someone would have to patch ohcount to recognise ebuilds and eclasses. which would take about ten minutes, admittedly
21:13 <Betelgeuse@> Any way let's move on.
21:13 < dberkholz@> ok, nobody's said anything for 3 minutes.
21:14 < dberkholz@> we have zero conclusions so far, afaict
21:14 <Betelgeuse@> dberkholz: I think nobody objected to undertakers setting their own limits.
21:15 <Betelgeuse@> dberkholz: The posting to -core can be revisited after svn etc are included
21:15 < dberkholz@> ok
21:15 <      amne@> Betelgeuse: imho they should just do what makes sense rather than sticking to more or less useful numbers
21:15 <     jokey@> Betelgeuse: agreed
21:16 <      amne@> Betelgeuse: but i don't really object, too
21:16 < dberkholz@> does anyone want to seriously look into ohloh?
21:16 <   ciaranm > i spoke to the ohloh people about gentoo-x86 already
21:16 <Betelgeuse@> that's 4 so we can move on
21:16 <   ciaranm > they'd need a copy of the full cvs repo to do anything, since cvs co is too slow
21:17 <Betelgeuse@> ciaranm: you mean operations like cvs log would be too slow?
21:17 <   ciaranm > Betelgeuse: ohloh needs every revision ever with full logs and every file and everything
21:17 <   ciaranm > Betelgeuse: they were getting that using cvs co, but they killed it because it was taking too long for the initial checkout
21:18 <    tsunam+> heh
21:18 < dberkholz@> so they get the initial dump, and then from there they could just use anoncvs?
21:18 <   ciaranm > if someone can provide a tarball of the full repo, they can use that instead
21:18 <    tsunam+> considering the size of it *nods*
21:18 <   ciaranm > dberkholz: yes
21:18 <   ciaranm > someone would also have to make ohcount recognise ebuilds. i've done stuff with ohcount before, so i could do that pretty quickly if it's going to be worthwhile
21:19 <  dev-zero > hi everyone
21:19 <Betelgeuse@> I can tar up the repo if everyone agrees.
21:19 <    tsunam+> I don't see why anyone wuold disagree
21:20 <     eroyf > hallå
21:20 <     eroyf > er i dumme eller sådan noget?
21:21 <     jokey@> Betelgeuse: it's open stuff anyway
21:22 <     eroyf > hey
21:22 <     eroyf > in the logs right
21:22 <     eroyf > it's my birthday
21:22 <     eroyf > say happy birthday eroyf
21:22 <     eroyf > i'm 19 now
21:22 <    tsunam+> eroyf: in the middle of a meeting
21:22 <     eroyf > sorry
21:23 <    tsunam+> what's the next order of business?
21:23 < dberkholz@> the cool one
21:23 < dberkholz@> Initial comments on PMS: Are there any major changes needed, or just tuning details?
21:24 <Betelgeuse@> Hmm. I wonder if just tarring up is bad as there will be commits while it's doing it.
21:25 < dberkholz@> ciaranm: is there a TODO around, or just looking at open pms bugs?
21:25 <   ciaranm > dberkholz: i mailed a list to -dev@ a while ago
21:26 < dberkholz@> ah, march 19. Subject: [gentoo-dev] Remaining PMS todo list etc
21:26 <gentoofan2 > I probably should have mentioned to -dev that dohtml is done
21:26 <   ciaranm > a few things on that are done now
21:27 < dberkholz@> ciaranm: some of the features only in kdebuild-1 eapi, before they get too set in stone, will they / have they already been discussed with portage/pkgcore people?
21:28 <   ciaranm > dberkholz: you'll have to ask the kde people for details. but as i understand it, zac has said that use deps for portage aren't ever going to happen, and the kde people have said that use deps aren't a negotiable requirement
21:28 <   ciaranm > dberkholz: so i've no idea how that one's going to work out
21:28 <Betelgeuse@> ciaranm: How does whether the ebuidl is interactive or not affect the PM?
21:29 <   ciaranm > Betelgeuse: it affects parallelism... if an ebuild is interactive, a PM can't build two things at once
21:29 <Philantrop > dberkholz: They have been presented to -dev. I've had no response from the authors of other PMs, though. So I guess they're fine with it.
21:29 <    tsunam+> Philantrop: have you tried contacting the developers directly
21:30 <Philantrop > tsunam: No, that's what mailinglists are for.
21:30 <    tsunam+> I don't personally consider -dev as always the best place to get people's attention
21:30 <Betelgeuse@> ciaranm: without I gui true but can't require that either
21:30 <    tsunam+> Philantrop: again....it doesn't always get everyone involved. Its not hard to go "oh well shit, 130 emails to -dev, they're shite and delete the whole lot"
21:30 <     jokey@> there's only one important thing (imho)... if those features won't make it into portage, we can't put such (k)ebuilds into gentoo-x86
21:30 <    tsunam+> it takes an extra 2 cc's
21:31 <   ciaranm > for the kdebuild stuff... we can flip a switch and remove it from the generated PDF for PMS if people really want. but i'd rather leave it in there, because it makes things easier for package manager authors
21:31 < dberkholz@> it seems to be reasonably clear, thanks to the eapi tables, which features are in which eapi
21:31 <jmbsvicett > jokey: They're only being used for live ebuilds
21:31 <   ciaranm > whether or not kdebuild goes into the tree, and whether or not all the kdebuild features make it into EAPI 2 is a whole different topic
21:32 < TehCaster > I thought PMS approval will only concern in-tree EAPI's and the kdebuild-1 etc while useful for some is not the subject right now?
21:32 <Philantrop > tsunam: They've both discussed it so they obviously know it. :-)
21:32 <Betelgeuse@> ciaranm: FEATURES userpriv checking at least could probably be switched to some UID based check
21:32 <    tsunam+> 14:29 < Philantrop> dberkholz: They have been presented to -dev. I've had no  response from the authors of other PMs, though. So I guess  they're fine with it.
21:32 <    tsunam+> ^^^ doesn't seem to say so
21:32 <   ciaranm > TehCaster: i don't see there being an issue with PMS being approved with the kdebuild stuff in... doesn't mean kdebuild is legal in the tree
21:32 <    tsunam+> in the case of standards "no answer" should not be considered a default yes
21:32 <Philantrop > tsunam: No response by mail. They've discussed it on IRC, though.
21:32 <   ciaranm > Betelgeuse: yeah. that one's a detail though. details can be worked out on #-dev
21:33 < TehCaster > ciaranm: yeah so why set them to stone now as dberkholz suggested
21:33 <   ciaranm > TehCaster: mm?
21:33 < dberkholz@> ciaranm: anything in particular you're curious about, things you think maybe should be in there but aren't?
21:33 <Betelgeuse@> ciaranm: But it is probably quite widely used in overlays and such that won't be fixed.
21:33 <Philantrop > TehCaster: Because we want a *stable* EAPI.
21:33 <    tsunam+> erm, the point is to make standards that all package mangers know and expect to have presented with
21:34 <   ciaranm > dberkholz: i'm moderately happy with it, except for the details, just now
21:34 <   ciaranm > tsunam: the numbered EAPIs, yes
21:34 <    tsunam+> ciaranm: I would hope we don't have undocumented EAPI's that are not agree'd to running around
21:35 < dberkholz@> on the big picture level, nothing really struck me in there
21:35 <   ciaranm > my view on the kdebuild stuff is that it's more useful being in PMS than being hidden, since it's a stable EAPI. but the paludis-1 stuff shouldn't be in there, because it's not stable and not considered suitable for general use. but then, i can just flip a switch and turn the kdebuild stuff off in the PDF if people really want
21:35 < dberkholz@> there was one spot where it wasn't clear to me that when saying ebuild, it really meant the state of the ebuild after eclasses were inherited
21:36 <   ciaranm > dberkholz: there're probably lots of little details like that
21:36 < TehCaster > right, stable and documented but not subject to approval of council until we are to use it in tree, that's my only point
21:36 <Philantrop > TehCaster: Yes, that's right.
21:37 <  ferringb > ciaranm: personally, I'd rather the kdebuild crap be out of pms- rather keep the stable/official stuff in there and not mix unofficial.  reasoning pretty much comes down to avoiding anything bleeding in from kdebuild (people make mistakes)
21:37 <Philantrop > TehCaster: I didn't seek council approval yet for kdebuild-1 anyway. :)
21:37 <Sweetshark > ciaranm: kdebuild stuff in pms do not matter for the decision if those are allowed in the portagetree. But a packagemanager should be pms-compliant without implementing kdebuild (for now). Would it be possible to make a clear destinction between those (maybe by making kdebuild features an optional requirement or something)
21:38 <   ciaranm > ferringb: that's solved by having the package manager enforce EAPI. which any package manager supporting kdebuild is required to do anyway
21:38 <    tsunam+> If its in the PMS then its part of what is expected behavior
21:38 < dberkholz@> should /etc/portage/ be involved in any way?
21:38 <Betelgeuse@> dberkholz: why?
21:38 <   ciaranm > Sweetshark: that's easily done by habing a list of which EAPIs are required and optional for gentoo-x86. probably outside of PMS
21:38 <   ciaranm > dberkholz: no
21:38 <  ferringb > ciaranm: eh?  I'm talking about the document itself
21:38 <    tsunam+> you can't have a moving EAPI table
21:39 <    tsunam+> the point of EAPI's is to ensure universal support
21:39 <   ciaranm > dberkholz: user configuration really shouldn't be in there...
21:39 <     eroyf > s
21:39 < TehCaster > btw zmedico just said use deps in portage are rather close, not "never going to happen"
21:39 <    tsunam+> IF kdebuild is not fully confident by all..then it should not be part of it
21:39 <Betelgeuse@> TehCaster: indefinately under work :D
21:39 <   ciaranm > tsunam: EAPI 1 isn't supported by everything. should it not be in there either?
21:39 <   Halcyon > tsunam: its not to ensure universal support, but to ensure feature sets are defined.
21:39 <    tsunam+> ciaranm: Personally, I would say no. However, we're stuck with it at this point =)
21:40 <   zmedico > Betelgeuse: I think they are getting very close to possible about now
21:40 <   ciaranm > TehCaster: he's also said that every time someone asks for them he's going to delay them for six months...
21:40 <Betelgeuse@> zmedico: Heh I remember you saying doing them duringdoing summer 07
21:41 <Betelgeuse@> zmedico: But great to hear that progress is happening on that front
21:41 <   zmedico > well, it's much closer now than before
21:41 <   ciaranm > tsunam: looking at it the other way... what gain do you see from not having kdebuild documented in the same place as the core EAPIs?
21:41 <Betelgeuse@> Discussing kdebuild is a bit OT imho as it can easily be turned off.
21:41 <   ciaranm > what Betelgeuse said
21:42 <    tsunam+> ciaranm: I see that we have an EAPI=0 and EAPI=1 that might be considered finalized sooner, rather then 20 revisions later..that look nothing like the current revisions
21:42 <   ciaranm > tsunam: huh?
21:42 < dberkholz@> ferringb, zmedico -- you guys got thoughts on the matter?
21:42 <     jokey@> mmm personally with the option for improvements and eapi0 and 1 in it, I'm willing to accept it
21:43 <   ciaranm > jokey: it's not ready for being accepted
21:43 <     jokey@> ciaranm: that's why I'm saying "with the option for improvements"
21:44 <Betelgeuse@> I would rather accept it when there aren't any known issues.
21:44 <    tsunam+> jokey: shouldn't be a option to improve really, should be new eapi's that might modify existing ones or other aspects in the future
21:44 <     solar > You might want to chime on on the dont use -r0 ever
21:44 <   zmedico > dberkholz: I'm not sure what's at stake right now. can you fill me in? are you deciding something?
21:45 <Betelgeuse@> tsunam: Well it's quite likely to find corner cases later.
21:45 <    tsunam+> Betelgeuse: aye, that's always a case
21:45 < dberkholz@> zmedico: 21:23 < dberkholz@> Initial comments on PMS: Are there any major changes  needed, or just tuning details?
21:45 <   zmedico > thanks
21:45 <    tsunam+> Betelgeuse: no code or standard will be 100% complete for all cases
21:45 <    tsunam+> Betelgeuse: however future issues can be handled at that time
21:45 <Sweetshark > ciaranm: its just harder to see which paragraphs can be skipped for the most basic pms-compliant implementation. If it wouldnt be so much work, I would think it would be better to have that stuff as an appendix. after being baisc pms-compliant one can look there how to support kdebuild etc ... just an opinion though.
21:46 <   ciaranm > Sweetshark: how is it hard?
21:46 <    tsunam+> Sweetshark: at that point, its fully part of the "standards"
21:46 <bonsaikitt > optional and non-optional bits mixed in the text
21:46 <  ferringb > dberkholz: don't believe kdebuild belongs in there for the reasons I mentioned above; there are a couple of loose spots in it that need correction (recent package.use for example, iirc portage now allows inline comments but isn't documented in PMS)
21:46 <  ferringb > dberkholz: would have to review it fully again, which is kind of hard considering I can't even get the damn thing to generate properly anyways ;)
21:47 < TehCaster > package.use is config, is that in pms?
21:47 <      zlin > tsunam: new eapi's cannot modify existing eapi's once it's stable and accepted
21:47 <Betelgeuse@> zlin: You would have to clarify what you mean by that.
21:47 <Betelgeuse@> zlin: Later EAPIs can change the behaviour defined in earlier ones.
21:48 <  arkanoid > no, they can override it
21:48 <      zlin > they can do something different. they cannot change what the existing eapi should do.
21:48 < dberkholz@> i think we're all saying the same thing
21:48 <   ciaranm > what everyone's clumsily trying to say is that future EAPIs can do things differently to current EAPIs, but can't change what current EAPIs do
21:48 < dberkholz@> the earlier eapi remains what it was, the later eapi may have different behavior
21:49 <    tsunam+> ^^^
21:49 < TehCaster > which is something different than correcting a glitch in the spec
21:50 <Sweetshark > ciaranm: there would be some need for tearing stuff apart (e.g. dep ranges into the appendix). its hard to judge the amount of work for that (at least for me)
21:50 <   ciaranm > Sweetshark: the paragraph's already indicated as not being available in all EAPIs
21:50 <Philantrop > Sweetshark: You know that you can just turn the kdebuild stuff off when "compiling" PMS, right?
21:51 <   ciaranm > it gets a lot harder to read if you start splitting up things like dep specs into different areas depending upon EAPI
21:51 <    tsunam+> also...the 2.2 section and 2.3 section seems to include -scm related materials. I thought that had been pushed back?
21:51 <   ciaranm > tsunam: kdebuild requires it
21:51 <Sweetshark > only if you plan to implement all eapis frontup
21:51 <    tsunam+> ciaranm: ah
21:51 <   ciaranm > tsunam: it should say that it's EAPI dependent
21:52 <   ciaranm > if it doesn't it's easily changed
21:52 <    tsunam+> don't see it being said in there but I'm looking over the section closer
21:52 <  ferringb > mmm.  metadata/cache segment still is missing mtime
21:53 <      zlin > use deps and -scm were the most important requirements for kdebuilds
21:53 <   ciaranm > ferringb: we weren't discussing details
21:53 < TehCaster > just generate pms without kdebuild and then discuss :)
21:53 <  ferringb > what are discussing then?  whether it's ready to go or not?  If so, then details matter
21:53 <   ciaranm > ferringb: no. please stick to the agenda.
21:53 <  ferringb > *what are we, pardon multitasking and failing and all tasks ;)
21:54 <   ciaranm > i was really hoping to avoid the exact thing you're doing here, and i phrased the request very specifically for that reason
21:54 <       spb > the agenda item was "are major changes needed, or just refinement of the details?"
21:54 <  ferringb > spb: thank you.
21:54 <       spb > as such, the details are irrelevant
21:54 <bonsaikitt > I would ask for a general cleanup of the language, it's overly complicated and ambiguous in places
21:54 <Betelgeuse@> I think we can just say it's the latter and conclude.
21:54 <    tsunam+> I would say yes to changes needed without the kdebuild
21:54 <   ciaranm > bonsaikitten: more specifically?
21:54 <  ferringb > tsunam: that's my opinion.
21:54 <Betelgeuse@> And move the discussion of details to gentoo-dev.
21:54 <bonsaikitt > ciaranm: double negations, overly long sentences, ...
21:54 <   ciaranm > bonsaikitten: more specifically?
21:55 <   Halcyon > bonsaikitten: file bugs where you don't find it to be clear.
21:55 <  blackace > ciaranm: you just said you didn't want to discuss details...
21:55 <Betelgeuse@> ciaranm: ^
21:55 <bonsaikitt > ciaranm: details are irrelevant here, I'll file bugs as soon as I have it cleaned up enough
21:55 <   ciaranm > blackace: yes. i'm assuming that bonsaikitten is making a general comment here, rather than discussing details, so i want to know what he's on about
21:55 <   ciaranm > if bonsaikitten thinks major wording changes are needed, i want to know where and why
21:56 <  blackace > which would be details
21:56 <Betelgeuse@> blackace: let's not argue that point now
21:56 <Betelgeuse@> Point noted and let's move on.
21:56 <   ciaranm > blackace: but since bonsaikitten brought the issue up after we said "no details", i'm assuming there's a major issue to discuss, and i need to know what he means
21:56 <  blackace > ciaranm: as Betelgeuse said, let's move on.
21:56 <      amne@> yupp
21:57 <   ciaranm > well, i'd like to hear from bonsaikitten... does he think there's a major issue, or is it just a details thing?
21:57 <  blackace > ciaranm: <bonsaikitten > ciaranm: details are irrelevant here, I'll file bugs as soon as I have it cleaned up enough
21:57 <   ciaranm > if there's a lot of wording change needed, that's the kind of thing i need to know now
21:57 <  blackace > now let's move on.
21:57 < TehCaster > is there anything left?
21:58 <Betelgeuse@> TehCaster: open floor
21:58 <   ciaranm > i would kinda like to know which way the council is going to go with the kdebuild stuff... because if there's no objection to stay in, i can remove a load of the conditionals and make the source a bit easier to work with
21:59 <   ciaranm > but if it's going to be one of those things that takes ages to decide, i'll just leave it as a conditional and submit both PDFs when it's ready
21:59 <Betelgeuse@> I say to keep the conditionals.
21:59 <Betelgeuse@> If it starts to get unmaintainable, we can reconsider.
22:00 <Sweetshark > ciaranm: i think bonsaikitten means there are quite some little fixes to be done, none serious in itself, but in sum there is still some work to do.
22:00 <       spb > Sweetshark: which would be "details"
22:00 <   ciaranm > Sweetshark: so he just said what we all already know and agreed not to discuss?
22:00 <Philantrop > ciaranm: Let it go. It's bonsaikitten. It can only be nonsense.
22:00 <     eroyf > haha.
22:00 < dberkholz@> i don't really care one way or the other about inclusion of not-yet-approved eapis
22:00 <Betelgeuse@> Philantrop: useless comment
22:01 <      amne@> ok folks keep it civil please
22:01 < dberkholz@> it might be kinda nice to have a doc that was just approved ones
22:01 <   ciaranm > dberkholz: would it really make things easier for anyone to have that?
22:01 <      igli > some rationale would be useful
22:01 <      igli > and a tighter spec
22:02 <    tsunam+> ciaranm: I believe so
22:02 < dberkholz@> ciaranm: learning ebuild authors, perhaps
22:02 <Betelgeuse@> ciaranm: How easy would it be to change for example background color with kdebuild?
22:02 <   ciaranm > dberkholz: learning ebuild authors shouldn't be touching PMS
22:02 <  blackace > I would like to ask the council for the status of the complaint filed against Philantrop, has the council discussed it and will it be on the next meeting's agenda?
22:02 < dberkholz@> ciaranm: people hoping to learn from it, i guess is what i'm saying
22:02 <    tsunam+> ciaranm: as people could easily confuse a section for approved when its still in the working stage
22:02 <   ciaranm > Betelgeuse: dunno. we were trying to do a nice cute sidebar colour, but opfer failed us and none of the rest of us know how to get that
22:02 <Philantrop > blackace: Oh, a complaint? Would have been nice to have known it exists. :-)
22:02 <     eroyf > a complaint against Philantrop?
22:03 <   ciaranm > dberkholz: mm, our target audience already knows what the different EAPIs are
22:03 <   ciaranm > tsunam: every EAPI documented in PMS is 'final', in that the only thing that'll change are spec screwups
22:03 <Betelgeuse@> dberkholz: Why weren't the complaints included in the agenda btw?
22:04 <    tsunam+> ciaranm: as far as I'm aware, EAPI=0 and EAPI=1 are both considered "drafts" that are just in full production use
22:04 <    tsunam+> approved for use by council
22:04 <   ciaranm > tsunam: 0 and 1 are supposed to be feature locked now
22:04 < TehCaster > being able to leave it out makes it easier to read for people not involved with implementing it in PM nor writing ebuilds for it
22:04 <   ciaranm > tsunam: 0 was supposed to have been locked as soon as portage supported EAPI
22:04 <   ciaranm > TehCaster: does it really?
22:05 <    tsunam+> ciaranm: was suppossed bothers me =)
22:05 <   Halcyon > This is a details thing guys, if you want to argue the merits either way, take it to g-dev@
22:05 <   ciaranm > i suppose what i'm saying is that i don't see how having it there hurts anyone, and i do see how having it there helps
22:05 < TehCaster > ok, for me, if for others that's up to voting I guess
22:05 <Sweetshark > ciaranm: it would make it easier for me to read the basics for example. so there is a gain. An document with kdebuild included can still exist, however it shouldnt be the official or "default" doc as long as those are not even used in the official tree.
22:05 <    tsunam+> ciaranm: its a doc we're saying is approved, having it there...in essence says "its approved in this form"
22:06 <   ciaranm > Sweetshark: PMS contains no basics
22:07 <      igli > the fundamentals then
22:07 -!- TehCaster is now known as Caster
22:07 <Sweetshark > ciaranm: pms should contain everthing i need to know for implementing a package manager handling offical gentoo ebuild.
22:07 <   ciaranm > there aren't any parts of PMS that aren't fundamental
22:07 <bonsaikitt > *sigh*
22:08 < dberkholz@> we don't seem to be making progress toward the one point ciaranm wanted a decision on
22:08 < dberkholz@> could we get back to that
22:08 <    Caster > just continue the vote :)
22:09 < dberkholz@> i'm fine with kdebuild being in the pms
22:09 <      igli > have the GLEPs been agreed?
22:09 <    tsunam+> igli: 46 yes
22:09 < dberkholz@> glep 46 was much earlier in the agenda, and yes it was approved
22:09 <      igli > k thanks
22:10 <    Caster > dberkholz: more specific it was about being able to build pms without it or removing the conditionals
22:11 < dberkholz@> that's sort of a halfway decision to the real point, we could settle for "leave conditionals" if we can't agree that kdebuild-1 should stay in
22:11 <   ciaranm > yeah, specifically the questions are a) whether anyone thinks anything's majorly wrong, and b) whether i can remove the conditionals on kdebuild or whether the council would rather i left them in so that that issue can be decided later on
22:11 <      igli > well can we take the scm stuff out then? it makes the names thing hard to read and conflicts with existing impl (even if you don't use conditional bit)
22:11 <    tsunam+> ciaranm: I would say leave the conditionals in unfortunately
22:11 <   ciaranm > igli: scm is conditional on kdebuild, and required by kdebuild
22:12 <      igli > yeah but cvs is undocumented and it's been part of existing impl for over 2 years as well as an alternative impl
22:12 <    Caster > ciaranm: am I wrong thinking that if you wanted to distinguish it by color you would have to mark it somehow anyway which is not that different from conditionals?
22:12 <Betelgeuse@> ciaranm: a) no b) no
22:12 <   ciaranm > igli: the cvs stuff is currently considered to be in the same category as ( ) : ( ) deps
22:12 <    tsunam+> Caster: be slightly different but
22:12 <    tsunam+> Caster: same basics yes
22:13 <   ciaranm > Caster: it's different in that the latex is less messy to just do the latter
22:13 <    Caster > maintenance-wise
22:13 <   ciaranm > latex buggers up spacing if you do conditional sentences
22:13 <   ciaranm > stopping it from doing that is moderately not fun
22:13 <   ciaranm > essentially, it treats a not taken conditional as a word or a paragraph unless you use some scary voodoo to stop it
22:14 <    Caster > mmm thought it was better than that :)
22:14 <    Caster > preprocess? :)
22:14 <   ciaranm > was trying to avoid that too
22:15 <   ciaranm > basically, any way we have of doing conditionals is a bit icky. not massively icky, but icky enough that it makes my life easier if the council decides that nuking the conditionals is fine
22:16 <    tsunam+> ciaranm: I don't see an issue if say...items not yet solitified are for instance red...
22:16 <    tsunam+> that's me personally
22:16 < dberkholz@> ok. maybe we can do two binary votes to make this a little easier
22:16 <   ciaranm > dberkholz: please
22:17 < dberkholz@> since the kdebuild thing seems to be a 3-way choice
22:17 < dberkholz@> 1. are you ok with kdebuild-1 and other unapproved eapi's being in pms?
22:17 <    tsunam+> 1) no
22:17 <     solar > no
22:18 <NeddySeago > You will approve the document - unapproved stuff must be removed
22:18 < dberkholz@> amne, Betelgeuse, vapier, jokey: time to wake up =)
22:19 <      amne@> dberkholz: was just asking if this still an official vote since it's open floor
22:19  *    jokey is awake and reading
22:19 <Betelgeuse@> NeddySeagoon: Already voted.
22:19 <Betelgeuse@> 01:12 <@Betelgeuse> ciaranm: a) no b) no
22:19 <      amne@> dberkholz: no
22:19 < dberkholz@> amne: i'd say so
22:20 < dberkholz@> alright. that's a no from tsunam, Betelgeuse, and amne on inclusion of kdebuild-1 in the spec to approve
22:21 <Betelgeuse@> dberkholz: Well I didn't vote on the inclusion.
22:21 <Betelgeuse@> dberkholz: I voted on whether to remove the conditionals.
22:21 <     jokey@> add a no from me for kdebuild incluseion, dberkholz
22:21 <     jokey@> *inclusion even
22:22 < dberkholz@> Betelgeuse: ok, then vote on this
22:22 <Betelgeuse@> dberkholz: no
22:22 < dberkholz@> righto.
22:22 < dberkholz@> ciaranm: you've got your answer. gotta keep the conditionals, it seems
22:23 <   ciaranm > ok
22:23 <    tsunam+> dberkholz: well not entirely
22:23 <     solar > seems like you just asked ppl to vote on "kdebuild-1 and other unapproved eapi's being in pms" then changed it to keeping conditionals
22:24 < dberkholz@> that's the way the logic works in my head
22:24 < dberkholz@> if they're to be in a draft state, and removed when we vote, they must be conditional
22:24 <    vapier@> pms is only approved stuff
22:25 <    vapier@> if it isnt approved, then it's a proposal, and thus not part of pms
22:25 <    vapier@> seems pretty straight forward to me
22:25 <     solar > exactly
22:25 <   ciaranm > the kde people consider kdebuild-1 to be final. as in, not a proposal.
22:25 <    tsunam+> vapier: exactly =)
22:25 <    tsunam+> ciaranm: kde is not the concil
22:25 <    tsunam+> council*
22:26 <    vapier@> if you want to write stuff in the overlay that uses things that arent in the pms, then whatever, that's your business
22:26 <    vapier@> but it obviously cant go into the tree
22:26 -!- billie80 is now known as billie
22:26 <    Ingmar > We don't have any such plans either..
22:27 <   ciaranm > is there any reason kdebuild can't just be kept in the official document but clearly indicated in the big master EAPI table at the start as "Only for use in overlays where the overlay owner has approved its use"?
22:27 <   ciaranm > rather than switching it off entirely for the official version?
22:27 <    vapier@> a spec is not a dumping ground for unofficial pieces or proposals
22:28 <      zlin > it's not a proposal. it's a spec for something that won't be used in gentoo-x86.
22:28 <     solar > putting anything in there that is not targeted at being official sets a bad precedent I'd think.
22:28 <Philantrop > vapier: It is a spec for kdebuild-1. It's not a proposal but final.
22:28 <Betelgeuse@> ciaranm: As it's rendered now it's not clear where the conditionals go so it's better turned off.
22:28 <    vapier@> then maintain it with your overlay
22:28 <Betelgeuse@> ciaranm: But if the borders are clearer I will reconsider.
22:28 <    vapier@> pms covers the tree
22:28 <    vapier@> not random overlays
22:28 <   ciaranm > Betelgeuse: mm, how is it not clear which bits are EAPI specific?
22:29 <Philantrop > vapier: Oh, I thought PMS covers the Package Manager Specification, not the tree...
22:29 <      igli >   
22:29 <   ciaranm > the EAPI specific stuff is something we want to have done clearly anyway, kdebuild or not
22:29 <  blackace > obviously, the reason is that it's confusing
22:29 <   ciaranm > blackace: confusing how, specifically?
22:29 <    tsunam+> Philantrop: do you disagree that currently gentoo-x86 is the main repository?
22:29 <    Caster > Philantrop: next it can cover rpm's!
22:29 <  blackace > ciaranm: see above for examples
22:29 <    vapier@> the pms was born of the tree
22:29 <Philantrop > tsunam: Nope.
22:29 <   ciaranm > i was under the impression that EAPI specific stuff was all marked as EAPI specific
22:30 <bonsaikitt > if it's not approved, why should it be in PMS at all?
22:30 <   ciaranm > blackace: well, where isn't it clear what's EAPI specific?
22:30 <Philantrop > Is there a problem with keeping it in *with* the conditionals?
22:30 <      amne@> if it's in PMS, every PM should support it, right? so should every PM support kdebuild?
22:30 <       spb > if it's in PMS, then PMS defines what it is
22:31 <   ciaranm > Philantrop: it's staying in. the question is whether i can remove the conditionals or not
22:31 <NeddySeago > Philantrop Do you need the council to approve  kdebuild-1 ?  If not, it should not be in PMS
22:31 <       spb > if it's on the council's list of supported and allowed EAPIs for gentoo, then any package manager that supports gentoo must support it
22:31 <    vapier@> if it isnt, then it doesnt belong in pms
22:31 <       spb > the one does not necessarily imply the other
22:32 <      igli > i think the answer to the conditional question was given 20 minutes ago
22:32 <    tsunam+> spb: of course it does!
22:32 < dberkholz@> are we all defining pms the same way yet?
22:32 <      igli > or maybe it just felt like 20
22:32 <Sweetshark > Philantrop: not if the vote is for the rendered pdf without kdebuilds ;-)
22:32 <    tsunam+> Good lord guys
22:32 <    Caster > this is ridiculous, and it was voted already so why keep this on
22:32 < dberkholz@> pms == the approved copy, not the git repository where work happens
22:33 <    tsunam+> PMS is approved copy of what is APPROVED for the Package Managers, and because of it the TREE
22:33 <  blackace > pms should be approved or disapproved in it's entirety
22:33 <    tsunam+> bingo!
22:33 <    tsunam+> not helter skelter
22:33 <  blackace > if something goes in it that isn't approved, the whole thing is disapproved
22:33 <   ciaranm > could someone please state the specific reason that we should make life more difficult for the target audience for PMS by removing all mention of kdebuild-1?
22:33 <     solar > Sweetshark: all unapproaved EAPI's
22:34 <    tsunam+> -_-
22:34 <  blackace > just like passing a bill through congress, if you put earmarks in people don't like, the whole bill doesn't pass
22:34 <    tsunam+> ^^^
22:34 <      igli > the target audience isn't people using kdebuild. PM implementors seem to know it quite well and discuss with each other. who else?
22:34 <    vapier@> the generated PMS is what package managers should be implementing
22:34 <    Caster > come on, council voted that it won't be part of PMS, so if you want to keep it in the source it must be conditional, end of story
22:34 <    vapier@> if you want to add something to the PMS, you get it approved
22:34 <  blackace > like an amendment
22:34 <    vapier@> how is this difficult to fathom
22:35 <    tsunam+> vapier: beyond me too :(
22:35 <     solar > it's not. So call an end of the meeting so I can steal tsunam for some paying work
22:35 <    tsunam+> lol
22:35 <   ciaranm > vapier: is there a specific reason that the council can't approve PMS with kdebuild included, but state that only 0 and 1 are allowed in the tree?
22:35 <      amne@> ciaranm: because it doesn't belong there
22:35 <    tsunam+> ciaranm: because 0 and 1 were approved in previous PMS's
22:36 <    vapier@> i generate the pms for reference.  it better not include anything that hasnt been approved.
22:36 <    tsunam+> kdebuild has not
22:36 <     solar > EAPI=1 should of never been allowed in this tree.
22:36 <    vapier@> if you want to add something, get it approved
22:36 <    vapier@> that is how it works
22:36 <    tsunam+> spb: we're stuck with it
22:36 < dberkholz@> let's not rehash that again...
22:36 <       spb > lol.
22:36 <Sweetshark > ciaranm: Well, I am target audiance. I reading the spec because im toying with writing a depresolver. I dont care at all about some fancy eapi thats never used in the official tree. keeping that stuff in is _not_ helping.
22:36 <    tsunam+> erm...
22:36 <     eroyf > lol.
22:36 <     eroyf > haha.
22:36 <    tsunam+> solar: ^^^ se above
22:36 <   ciaranm > Sweetshark: you don't care about something used in an official gentoo overlay?
22:36 <Betelgeuse@> EAPI 1 addition will not be rediscussed now.
22:37 <Sweetshark > ciaranm: not in the first step
22:38 <    vapier@> what exactly is left to be decided ?
22:38 <    vapier@> sounds like we've agreed
22:38 <      amne@> yupp
22:38 <Betelgeuse@> vapier: nothing?
22:38 <      amne@> and i gotta go anyway
22:38 <  blackace > ok, before the meeting is ended, I'd like to get an answer to my question that was buried in the above discussion, has the council discussed the complaints against Philantrop, eroyf, and spb?  and will the complaints be on the agenda for the next meeting?
22:38 <       spb > there was a complaint against me? on what grounds?
22:38 <     eroyf > against me?
22:38 <     eroyf > what.
22:39 <kingtaco|w > tsunam, btw, are you proxying for flameeyes?
22:39 <    Caster > isn't the first step devrel?
22:39 <    tsunam+> kingtaco|work: that is correct
22:39 <Philantrop > I'd like to know about that, too. Especially since there's no DevRel bug against me.
22:39 <     eroyf > i'm not even a developer so how the hell would there be any complaints about me blackace?
22:39 <kingtaco|w > tsunam, kk
22:39 <     eroyf > blackace: care to answer?
22:40 <jmbsvicett > eroyf: In theory there could be some userrel action about a user
22:40 <    vapier@> blackace: yeah, start there
22:40 <     eroyf > jmbsvicetto: indeed. but ther ehaven't been any that i know of.
22:40 <    vapier@> eroyf: you have +v in #-dev which can be punted
22:40 <  blackace > eroyf: my question is for the council members.
22:40 <  arkanoid > eroyf: that's classified information
22:41 <Philantrop > Betelgeuse, dberkholz, jokey, vapier, tsunam: Can I please get an official answer about that complaint against me?
22:41 <    vapier@> blackace: is that sufficient or were you looking for something more ?
22:41 <     eroyf > i haven't done anything in #gentoo-dev that's weird except for tonight where i've been out due to my 19th birthday party vapier.
22:41 <     eroyf > blackace: i'd like to know about any complains about me as well given that i'm involved.
22:41 <  blackace > vapier: is what sufficient?  did I miss an answer to my question?
22:41 <     eroyf > and i haven't seen any so i doubt there's any.
22:41 <    vapier@> blackace: start with devrel rather than council
22:41 <    tsunam+> someone who's a member of the council in general able to give an appropriate answer to Philantrop
22:42 <    tsunam+> as I'm just a proxy
22:42 <    vapier@> we'd prefer not to be the starting point, or set an example of being the starting point
22:42 <  blackace > vapier: complaints were sent to council@, I am asking for status on those complaints since council has not responded nor put it on the agenda.
22:42 <     eroyf > why haven't any involved members been told about that?
22:42 <    vapier@> blackace: and i just said
22:42 <nightmorph > yeah, but that'd be like asking the docs-team why an ebuild isn't stabilized on a missfiled bug, blackace
22:43 <nightmorph > if it's the wrong team to begin with, why should they have to respond?
22:43 <Betelgeuse@> blackace: We are not that far yet.
22:43 <     eroyf > for once, what nightmorph said.
22:43 <Betelgeuse@> blackace: But I did see your mails :)
22:44 <  blackace > nightmorph: no, council is the highest body, there is no reason people can't compain to the council directly
22:44 <  blackace > s/compain/complain/
22:44 <Betelgeuse@> blackace: Or was it someone else who sent them don't remember.
22:44 <    vapier@> blackace: there is a reason
22:44 <  blackace > Betelgeuse: someone else
22:44 <     eroyf > you should go complain via the normal channels
22:44 <    vapier@> we have the devrel group in place for complaints
22:44 <     eroyf > which you obviously fails to do.
22:44 <    vapier@> eroyf: shut up
22:44 <Betelgeuse@> blackace: You don't start in the supreme court.
22:44 <    vapier@> you're just adding noise at this point
22:44 <Philantrop > Betelgeuse: So does this mean the council rejected the complaints?
22:45 <  blackace > Betelgeuse: well, this isn't a legal system
22:45 <    tsunam+> eroyf: devrel is aware of issues and has officially had complaints to it against members stated above as well
22:45 <    vapier@> Philantrop: that sentence doesnt make any sense
22:45 <     eroyf > no i am not. i'm saying that he should take it up with devrel / userrel ((devrel for Philantrop and spb) and userrel for me)
22:45 <    Caster > blackace: but there are defined escalation procedures
22:45 <  blackace > Caster: which have been followed afaik
22:45 <    tsunam+> eroyf: I have no proble taking it up with you if you'd like :-D
22:46 <Philantrop > tsunam: Interesting. So why wasn't I even informed as the accused party?
22:46 <    Caster > then I don't know the one that says "start with council" :)
22:46 <     eroyf > tsunam: fine with me, but i don't want to see my name mentioned in any coucil log by blackace when i've no clue what he's talking about.
22:46 <    tsunam+> eroyf: lol
22:46 <     eroyf > tsunam: if it was taken up with userrel, fine. i'd listen to you guys.
22:46 <  blackace > again, I am not here to argue, I am here asking the council if they will have an agenda item at their next meeting.
22:46 <    tsunam+> eroyf: just saying if you'd like to talk to userrel
22:46 <     eroyf > i'm fine talking with userrel and i'd listen to whatever you might say.
22:47 <    tsunam+> there are area's that directly state the council for issues
22:47 <     eroyf > nod
22:48 <Philantrop > Can I get a straight answer from anyone here?
22:49 <Sweetshark > blackace: not the right time to ask - depends on if devrel etc. will need to escalate. bothering the council now with it is just ... bothering
22:49 <    vapier@> Betelgeuse will take it over, i'm outs
22:49 <Philantrop > tsunam: "<tsunam> eroyf: devrel is aware of issues and has officially had complaints to it against members stated above as well" - would you kindly enlighten me?
22:50 <  blackace > Sweetshark: and you're not council, I'm not asking you a thing.
22:51 <Philantrop > And while we're at the subject of enlightening people: "<wltjr>	NeddySeagoon: other than we are losing GNi in like ~20 days now, nope" - we're losing GNi? As in "as a sponsor"? Or what?
22:51 <  arkanoid > blackace: afaik, two members of council told you this was the wrong place to start. Is that not an answer?
22:51 <Betelgeuse@> Philantrop: We haven't rejected them or acted on them yet. Sorry to be a bit vague at this point but we need to decide internally first on how to go forward.
22:51 <    tsunam+> Philantrop: that is not entirely the case
22:52 <    tsunam+> Philantrop: and that is strictly a Foundation issue
22:52 <     solar > great. So is this meeting over?
22:52 <    tsunam+> Philantrop: its being handled by the Foundation and the infrastructure team
22:52 <  blackace > Betelgeuse: thanks, that is actually a partial answer to my question.
22:53 <     eroyf > gentoo's losing gni?
22:53 <     eroyf > isn't gni the main sponsor of gentoo?
22:53 <    tsunam+> eroyf: they are a large sponsor for Gentoo yes
22:53 <Betelgeuse@> Any council members oppose ending the meeting?
22:53 <     eroyf > don't they host bugzilla and stuff?
22:53 < dberkholz@> alright, we're getting more and more away here
22:53 <    tsunam+> eroyf: they do yes
22:53 <Betelgeuse@> eroyf: The sky is not falling.
22:54 <Philantrop > Betelgeuse: Strange way to handle complaints... Keeping the accused people in the dark about it.
22:54 <     eroyf > anyways
22:54 <     eroyf > before you end
22:54 <    tsunam+> Philantrop: why invove the accused, if no decision to even do anything has been decided
22:54 <     eroyf > as Philantrop, i'd like to hear about any complains about me.
22:54 <  arkanoid > Philantrop: they had great success with that in the medieval times too
22:54 <     eroyf > and not directly from blackace since i don't care about him. but from the council / devrel / userrel.
22:55 <    tsunam+> Philantrop: I am sure if anything was to be decided to happen, you would be informed and be giving a chance to discuss the matter in a fair way
22:55 <  blackace > eroyf: careful, you're gonna hurt my feelings saying things like that :)
22:55 <Philantrop > tsunam: It's a very rude way, I must say. Letting this going public but not even letting me know what it is about.
22:56 <Betelgeuse@> Philantrop: If it wasn't brought up here you would have gone on happily until we possibly would contact you. I don't see any harm in that.
22:56 <Betelgeuse@> Philantrop: We didn't let the genie out of the bottle.
22:56 <  arkanoid > Betelgeuse: but it's out nonetheless :)
22:56 <Betelgeuse@> Yes it's valid a question to ask where it's going of course.
22:56 <    tsunam+> I call for an end to the meeting for today
22:56 <Philantrop > Betelgeuse: It has been brought up here so I'd say I have a right to know about it.
22:56 <    tsunam+> Anyone second
22:57 <    tsunam+> as this is beyond the confines of the meeting
22:57 <     eroyf > Philantrop's question needs to be answered first tsunam.
22:57 <     solar > No it does not
22:57 <     solar > it's so fscking off topic
22:57 <Betelgeuse@> tsunam: yeah
22:57 <    tsunam+> eroyf: Its been answered "not sufficently" for Philantrop's expectations, but answers have been given
22:57 <Philantrop > solar: No, two involved parties have asked the council for an official statement.
22:57 <     jokey@> right, so anyone having anything left for this meeting?
22:58 <     solar > Philantrop: and the council already said this is not the proper channel
22:58 <     eroyf > solar: Philantrop and I've asked the council for an official statement. That should be enough.
22:58 <     solar > so.. Please.. End this meeting. You are waiting everybodies time.
22:58 <Betelgeuse@> I already said that we can't give a public statement at this point.
22:58 <Betelgeuse@> But yes we have received said complaints.
22:58 <  arkanoid > Betelgeuse: I'm sure just telling the involved parties about it would be satisfactory for them :)
22:59 <  arkanoid > no need to inform the rest of us
22:59 <Philantrop > Ok, that's enough. I'll give it a night to sleep over but I'm probably going to retire from Gentoo for this absurd and *perverted* handling of complaints.
22:59 <    tsunam+> it would appear its not even at the preliminary point
22:59 <Betelgeuse@> arkanoid: again the council did not start this line of discussion
22:59 <    tsunam+> I'm gone
22:59 <Sweetshark > eroyf: council resolved the bug as INVALID DOWNSTREAM. Everything else is just that it was inapproprate to bring this up here, but thats not councils job either, i guess (devrel again).
22:59 <    tsunam+> night all
23:00 <  arkanoid > Betelgeuse: nope, but know that they know about it, it does seem appropriate to inform them (and only them) properly. but then again, it was just a proposal to reach an understanding between you
23:00 < dberkholz@> here's a summary, feel free to suggest changes before i mail it out in a little while
23:00 < dberkholz@> http://dev.gentoo.org/~dberkholz/20080410-summary.txt
23:01 <   ciaranm > dberkholz: could you include the rationale for the kdebuild-1 decision please?
23:01 < dberkholz@> ciaranm: sure, do you have any quotes handy or should i dig 'em up
23:01 <Philantrop > dberkholz: Would you please add the unwillingness of both council and devrel to even inform the accused of what they're accused of?
23:02 < dberkholz@> sure
23:02 <   ciaranm > dberkholz: i ask because i don't think i understood the rationale part, and i'd like to see it rephrased
23:04 <Betelgeuse@> Philantrop: As some members already left I didn't want to take actions into my own hands.
23:06 <Betelgeuse@> Philantrop: And you caught us off guard any way as this wasn't supposed to be handled in this meeting.
23:06 <Betelgeuse@> Philantrop: Well not you but blackace.
23:06 <Philantrop > Betelgeuse: It's pretty much a moot point now. If the council didn't reject the complaint against me yet, I should be informed about its contents. If it did reject the complaint, I don't care. But hearing that DevRel has obviously received a complaint against me and isn't even informing me about it, is something I consider in extremely bad taste.
23:06 <    Fieldy > if i may chime in, that may be something to talk to devrel about.
23:07 <   astinus > and the reason it was raised direct with Council
23:07 <   astinus > is because DevRel does precisely nothing, in almost all cases
23:07 <   astinus > and this has gone far enough, Gentoo is simply *not* fun any more when stuff like this keeps happening.
23:07 <nightmorph > badmouthing one group doesn't help anything
23:08 <       spb > it is, on the other hand, rather amusing when stuff like this keeps happening
23:08 <   astinus > spb: Not when it costs us good developers.
23:08 -!- mode/#gentoo-council [+o lu_zero] by ChanServ
23:08 <       spb > oh, the good developers are already gone
23:08 <       spb > not much to worry about really
23:10 <Philantrop > spb: Thank you. ;->
23:12 <Betelgeuse@> I need to go to bead now.