19:59 -!- mode/#gentoo-council [+m] by Betelgeuse
20:00 <Betelgeuse@> Houston we have a go.
20:00 <     jokey@> yep
20:00 -!- mode/#gentoo-council [+v solar] by Betelgeuse
20:00 <Betelgeuse@> Was anyone else proxying?
20:01 -!- mode/#gentoo-council [+v FlameBook] by Betelgeuse
20:01 -!- mode/#gentoo-council [+m] by dberkholz
20:01 < FlameBook+> I don't see JoseJX
20:01 -!- mode/#gentoo-council [+v solar] by dberkholz
20:02 -!- Irssi: #gentoo-council: Total of 79 nicks [8 ops, 0 halfops, 2 voices, 69 normal]
20:03 < dberkholz@> lu was active 10 minutes ago, so not sure he needs a proxy..
20:03 <   lu_zero@> I don't need it
20:03 <   lu_zero@> as I said I was afraid of being in late ^^
20:03 <Betelgeuse@> Anyone seen amne?
20:03 < dberkholz@> if anyone besides solar is proxying, query me now
20:04 < dberkholz@> everyone's spoken in the past ~10 minutes except amne, with solar proxying for vapier
20:05 < dberkholz@> we've got 6 people, let's get started and give amne another 10 minutes to show up before he gets a slacker mark. sound good?
20:06 <     jokey@> yup
20:06 <Betelgeuse@> sure
20:06 <   lu_zero@> ok
20:06 <   lu_zero@> anybody could sms him?
20:06 < dberkholz@> first topic: "Document of being an active developer"
20:06 -!- mode/#gentoo-council [+v araujo] by dberkholz
20:07 < dberkholz@> araujo: anything to say, besides what's in the agenda?
20:07 < FlameBook+> lu_zero: let me
20:08 < dberkholz@> ok, anyone got opinions on http://dev.gentoo.org/~araujo/gcert1.pdf ?
20:09 <Betelgeuse@> should it have links to somewhere?
20:09 <   lu_zero@> dberkholz looks nice
20:09 < dberkholz@> i'm not sure that the trustees are the correct group
20:09 <Betelgeuse@> And a title.
20:10 < dberkholz@> 20:09 <NeddySeago> It needs a date of signing ... and maybe an expiry date
20:11 < dberkholz@> Betelgeuse: like "Developer Certification" on the very top?
20:11 <     jokey@> one year expiration was agreed on wasn't it?
20:11 <Betelgeuse@> dberkholz: something like that yes
20:12 < dberkholz@> (for anyone who hasn't followed this, these certificates are apparently required for some jobs and such. a couple of people had a need for it.)
20:14 <     jokey@> so, given we add an expiration date, I'm all for it
20:14 < dberkholz@> Blackb|rd suggests that we just add a "signed" date instead of an expiration date
20:15 <    araujo+> hello
20:15 <    araujo+> dberkholz, well, I wonder about the infra side to implement this script
20:15 <   lu_zero@> I'm not sure about the expiration date
20:16 <    araujo+> jokey, I don't think that's needed since we specify the year in the cert
20:16 <   lu_zero@> a start date and an issue date should do better
20:16 <    araujo+> we could be more specific with the date
20:16 <    araujo+> yeah lu_zero , that sounds good
20:17 <     jokey@> maybe some url to verify validity
20:17 <   lu_zero@> so "Gentoo developer since $date" "Issued $othe date"
20:17 < dberkholz@> i'm getting lots of queries about expiration dates .... my thinking is that a signed date reflects the same information without trying to know the future
20:17 <   lu_zero@> jmbsvicetto suggests something along "is a Gentoo developer since X/Y/Z and a member ..."
20:18 <    araujo+> jokey, like http://www.gentoo.org/proj/en/devrel/roll-call/userinfo.xml ?
20:18 <     jokey@> araujo: yeah, something like that
20:18 < dberkholz@> astinus suggests that we need contact information to verify this if employers want to do so
20:19 < FlameBook+> amne is having network trouble, so I would suppose he might or might not appear
20:19 < dberkholz@> for example a devrel contact
20:19 <     jokey@> trustees@ would be the right thing then
20:19 <    araujo+> dberkholz, contact information ... like ?
20:19 < dberkholz@> devrel seems like the right group for this HR-related thing, rather than trustees
20:19 <   lu_zero@> I agree with dberkholz
20:20 <    araujo+> Ok, so, Devrel is enough to validate this document'
20:20 <    araujo+> ?
20:20 <     jokey@> works4me
20:20 <    araujo+> ok, and what we could add for the contact information? ... devrel mail?
20:21 <     jokey@> dunno if chrissy wants to give out her phone# ;)
20:21 <     solar+> I doubt that she would want to
20:21 < dberkholz@> arkanoid continues to stress the importance of expiration dates
20:22 <    araujo+> hah ... well ... what if we create a section with the whole contact information for these certs , and use that link then?
20:22 < dberkholz@> one thing we could do to address this is say "XXX has been a Gentoo developer from DATE to DATE"
20:22 <   lu_zero@> I don't see what's the meaning of expiration date
20:23 <   lu_zero@> that the certificate isn't valid?
20:23 <    araujo+> ColdWind says that he doesn't agree with this on devrel, because that's for developer relations only , and this will involve outsiders
20:23 < FlameBook+> what about writing on the certificate an encrypted code that can be verified automatically on the website?
20:23 <   lu_zero@> FlameBook works for me
20:23 < dberkholz@> i don't think we need that, we could just point to the userinfo page
20:23 < dberkholz@> it has a link to retired devs
20:23 <    araujo+> correct
20:23 <   lu_zero@> and HR people could just check the website
20:23 < FlameBook+> dberkholz: to stop possible forgery, if that ever makes sense
20:24 <    araujo+> every time I asked about the best way to validate a developer status, was to chek the developer info page
20:24 <     jokey@> I'm with dberkholz there, maybe making that a bit more obvious where to find "active" and "retired" ones but that should do then
20:24 < dberkholz@> we should try to add some date fields to the retired devs page
20:24 <    araujo+> fmccor agrees with this on devrel , and we can arrange for further contact if necessary, and no to phone numbers. <i agree>
20:25 <    araujo+> I like the idea of the 'start date' and 'issue date'
20:25 <    araujo+> with a link to the userinfo page
20:28 <   lu_zero@> anybody else?
20:28 < dberkholz@> http://dev.gentoo.org/~dberkholz/20080508-summary.txt has 4 suggestions in it. anyone disagree with one or have more to add?
20:29 < dberkholz@> ah right, the title
20:29 <    araujo+> dberkholz, what devrel contact info exactly?
20:29 < dberkholz@> araujo: reload =)
20:29 <    araujo+> ah ok, good
20:30  *   araujo agrees
20:30 <     jokey@> looks good donnie
20:30 < dberkholz@> seems we've covered most points, i'm going to open the floor for further comments on this topic
20:30 -!- mode/#gentoo-council [-m] by dberkholz
20:30 <      amne@> oi
20:31 <      amne@> very sorry about the delay, i had some bloody networking problems
20:31 < FlameBook+> and there comes amne :)
20:31  *     amne goes read the backlog
20:31 <   lu_zero@> =)
20:31 <    araujo+> ok, so we agree about this?
20:32 <   astinus > amne: slacker!
20:32 <     jokey@> araujo: yep, fine with me :=)
20:32 <    araujo+> if we agree about the cert format ... now I have to take care of the design, which I will be sending to -dev later ... I would like to talk about the infra side for the script
20:33 <   astinus > araujo: I'm not sure what you'd need which is special?
20:33 <   lu_zero@> fine for me
20:33 <NeddySeago > araujo, if devrel will sign (in ink) and scan and email, why do you need a script at all ?
20:33 <    araujo+> scribus is basically plain xml , so I guess I am free to choose any available scripting language for it , but I want to know what it is the preferred way to extract this developer information ...
20:34 <     jokey@> araujo: ldap works best afaik
20:34 <   astinus > araujo: from LDAP?
20:34 <Betelgeuse@> araujo: python-ldap should work
20:34 <   astinus > *nod*
20:34 <    araujo+> NeddySeagoon, oh, you have brought a good point :-]
20:34 <     jokey@> unisono heh
20:34 < FlameBook+> NeddySeagoon: would be simpler to scan a signature and add it over the image :)
20:34 <    araujo+> Should this cert be hand-signed (ink) , or can it be generated by a script with the digital of it?
20:35 <    araujo+> Ok, good, ldap ...
20:35 < dberkholz@> who's comfortable with having their scanned signature sitting on a gentoo box?
20:35 <NeddySeago > it should be hand signed and emailed in a signed email
20:35 < Blackb|rd > araujo: only after ten years of service as a dev :D
20:35 <NeddySeago > dberkholz, not me
20:36 < dberkholz@> from our previous discussions, i thought we could just digitally sign it with gpg
20:36 <    araujo+> well, yeah .. this is an important detail we almost miss to discuss ... :-P
20:36 < Blackb|rd > dberkholz: inside the PDF or detached?
20:36 <     pilla > dberkholz: I am not sure that many potential employers will figure it out
20:36 <Betelgeuse@> dberkholz: What's so compromising about signatures?
20:36 < Blackb|rd > araujo: does the pdf generation process support "inline" sigs?
20:36 <    araujo+> I guess this is pretty much up to devrel/trustee ..
20:36 < Blackb|rd > araujo: crypto sigs, that is.
20:37 < dberkholz@> Betelgeuse: anyone could forge my name on any document they cared, if the box gets compromised..
20:37 <     pilla > if the signature is not crypto-protected itself, yes
20:37 <    araujo+> Blackb|rd, will have to check it out
20:37 <   astinus > dberkholz: We can already do that by getting ahold of any document you've ever signed and scanning it.
20:37 <Betelgeuse@> ^
20:37 < FlameBook+> as astinus said
20:37 < dberkholz@> astinus: do you have access to any of those?
20:37 < dberkholz@> are any of them on a gentoo box?
20:38 <   astinus > dberkholz: I'd bet $20 it wouldn't be that hard. Probably easier than hacking an Infra box.
20:38 <Betelgeuse@> any way OT
20:38 <     jokey@> indeed
20:38 < FlameBook+> astinus: it's easy to bet $20 >_>
20:38 <Betelgeuse@> I sign different stuff all the time.
20:38 <     jokey@> special details that can be discussed later
20:38 <     jokey@> and are not subject of general "worksforus"
20:38 <   antarus > hrm, council meeting? :)
20:38 <   astinus > my point was *yes* there is a concern about storing a sig and overlaying onto the PDF, *but* if someone really wants your signature, there's 101 ways to get it.
20:38 < Blackb|rd > If the retired devs page was easier to find, no need for sigs, IMHO
20:39 < dberkholz@> that's up to the people who would have to sign it
20:39 <NeddySeago > lets move on ... its an implementaion detail
20:39 <   astinus > dberkholz: script it so the signature IMG is gpg'd and require it be decrypted each time as part of the certificate generation process?
20:39  *  astinus nods
20:40 <    araujo+> ok, but, we should agree on this
20:40 <     jokey@> NeddySeagoon++; dberkholz: let's note that on summary that this detail has to be discussed with the signing person and move on
20:40  *   araujo is fine with both
20:41 <    araujo+> astinus, we can do that
20:41  *     amne <- finished reading backlog, anyone want me to say anything? :-P
20:41 <   astinus > amne: nah, you're just the token four-letter-nick guy ;)
20:42 <      amne@> heh. in that case i'll just agree to what the others already said
20:42 <    araujo+> I like astinus idea
20:42 <    araujo+> anyone?
20:43 < dberkholz@> sure, and i agree with jokey
20:43 < dberkholz@> discuss that with the signer
20:43 <      amne@> yupp
20:44 < dberkholz@> so, next actions are for araujo to add the suggestions in the summary to the certificate, and to work on a script to acquire info from ldap
20:44 <    araujo+> dberkholz, ok
20:44 <   antarus > araujo: if you need help with ldap
20:44 <   antarus > I am a wizard
20:44 <   antarus > with pointy hat
20:44 <    araujo+> antarus, welcome :-]
20:44 < dberkholz@> araujo: you may also wish to discuss the signing with people in devrel
20:44  *  astinus pops antarus' oversized head :P
20:44 < dberkholz@> anyone else got something new to add to this topic?
20:44 <Betelgeuse@> araujo: or could just use the new slacker script to startt with
20:44 <    araujo+> Betelgeuse, what is that?
20:45 <Betelgeuse@> http://rafb.net/p/5UU0MV64.html
20:45 <     jokey@> dberkholz: doesn't look like it, next topic
20:45 <    araujo+> Betelgeuse, nice :-]
20:45 <     jokey@> just more details for hacking it up which can be adressed in #-dev or somewhere ;)
20:45 < dberkholz@> Betelgeuse, araujo -- feel free to continue talking about details in #-devrel or #-dev, let's move on to the next topic here
20:45 <  ferringb > Betelgeuse: iteritems not items :P
20:45 -!- Irssi: #gentoo-council: Total of 88 nicks [8 ops, 0 halfops, 3 voices, 77 normal]
20:46 <    araujo+> ok, good
20:46 -!- mode/#gentoo-council [-v araujo] by dberkholz
20:46 -!- mode/#gentoo-council [+m] by dberkholz
20:46 < dberkholz@> next topic: slacker archs [vapier]. solar, don't suppose you've got any updates from him?
20:47 <     solar+> He did not make me aware of that topic.
20:47 < dberkholz@> ok
20:47 < dberkholz@> nothing new then, and let's proceed to the new topics
20:47 <     jokey@> was there any "preview" of what he worked on?
20:48 < dberkholz@> not that i know of
20:49 < dberkholz@> next topic: "When are ChangeLog entries required?"
20:49 < dberkholz@> my opinion is "always"
20:50 < FlameBook+> always for me too
20:50 <     jokey@> same here though there is this special changelog in profiles
20:50 <     solar+> that is an interesting topic and I would say the same. but I know the guy that I'm proxing for is the biggest offender of that
20:50 < dberkholz@> with a possible exception for when you're changing the changelog itself in minor ways
20:50 <Betelgeuse@> Or when rewerting a commit.
20:50 <     jokey@> Betelgeuse: imho even that should be noted
20:51 <     solar+> For sure when you touch a package that does not list you in the metadata.xml
20:51 <Betelgeuse@> jokey: Useless noise if it never reaches rsync
20:51 < dberkholz@> on the other side, many people think that stabilization entries in changelogs are just adding spam
20:51 < dberkholz@> do they provide useful information, and is it worth the additional space?
20:51 < FlameBook+> dberkholz: good reason to keep them: you want to know when a package was stabilised last
20:51 <     solar+> it might but as a maintainer it gives me an idea of when XYZ arch marked pkg stable.
20:51 < FlameBook+> and by who
20:52 <      amne@> i think it's useful, so always++
20:52 <Betelgeuse@> dberkholz: They are more useful for maintainers than users.
20:52 <Betelgeuse@> But useful any wa.
20:52 < FlameBook+> let's remember that cvs history needs network access to work
20:52 < FlameBook+> if we had the full history locally, I'd be more likely not to push for always always always, but for now...
20:53 <     jokey@> indeed, just go with "always" and be done
20:56 < dberkholz@> i'm going to open the floor, a few people have things to say
20:56 -!- mode/#gentoo-council [-m] by dberkholz
20:56 <      amne@> had some network fuckup myself earlier ;-)
20:57 <      amne@> oops
20:57 <  ColdWind > just want to agree with all of you: stabilization entries are useful to me both as package maintainer and AT
20:57 < Blackb|rd > always++
20:57 <      amne@> and that was another network fuckup, sorry
20:57 <    fmccor > As long as there is something called ChangeLog present, it seems to me that I should expect it to show some indication of all changes.
20:57 < Blackb|rd > Also, stabiliziation entries should be filterable with a small amount of regex work.
20:57 <     jokey@> anyone objections to "always" ?
20:58 < FlameBook+> we _could_ generate the changelog out of cvs
20:58 <    fmccor > And even when just marking something stable, I add a bit more information to the changelog.
20:58 <   antarus > I object wholly to the stating of the question
20:58 < dberkholz@> amne: can you stop swearing please, we're in the middle of a meeting here...
20:58 <   antarus > I think the opposite question is better ;P
20:58 <  ColdWind > jokey: just that you'll have to make the decision effective
20:58 < FlameBook+> I know I can easily generate it from svn through a modified svn2cl, not sure about cvs though, it doesn't export it as xml
20:58 <      leio > there are things like "Fix whitespace", removal of ancient redundant versions that can spam quite a bit with the removal notice on lots of patches that have been incorporated, and so on
20:59 <     jokey@> ColdWind: I'd be willing to hack up a watcher for commits mailinglist or do it myself
20:59 <      amne@> dberkholz: sorry, that was from a /msg and went into here because my connection died appearently
20:59 <   antarus > it is impossible to enumerate all the cases where a changelog is required and trivial to enumerate the cases where one is not required
20:59 <   antarus > well not impossible, but difficult
20:59 < FlameBook+> leio: removal of a version is something _users_ might want to know about...
20:59 <  ColdWind > jokey: actually I was talking about vapier following the decison
20:59 <   antarus > ColdWind: enforcement is a different issue no?
21:00 <      leio > it's gone from the filesystem, so common sense says it was removed
21:00 < FlameBook+> leio: why? by who? was there a good reason? and so on...
21:00 < FlameBook+> at least I tend to say why I remove something _especially_ if it's ancient
21:00 <  ColdWind > antarus: yes (and here ends my flooding)
21:01 < FlameBook+> if it's just not a stable candidate I can see it not to be so useful, but that's a minimum amount of messages
21:02 <   impulze > what about the size of the tree especially when you consider tons of packages with huge changelogs? will older entries vanish from the file from time to time?
21:02 < FlameBook+> do we have an estimate of how much space do changelog take?
21:03 <   antarus > we can look
21:03 <   antarus > someone want to volunteer or am I doing it? :)
21:03 <   astinus > you just volunteered.
21:03 <     jokey@> you do it (tm)
21:04  *  antarus cvs ups
21:04 < Blackb|rd > 753<
21:04 <   impulze > or probably just keep changelogs for active ebuilds in the tree which would then of course not show why a package was removed
21:04 < Blackb|rd > er M
21:04 < Blackb|rd > (generated from find . -name Changelog|xargs du -h)
21:04 <   armin76 > lol
21:04 <   armin76 > really? how much is the full tree?
21:04 < FlameBook+> reasons for package removal can be found on the mailinglists that's another problem entirely
21:05 <   astinus > armin76: about that.
21:05 < Blackb|rd > armin76: erm. 753M.
21:05 <     jokey@> though where I'm willing to make a cut is "old" history
21:05 < Blackb|rd > There's something amiss :)
21:05 <     jokey@> like if the changelog grows beyond 100kb, gzip the overlapping part
21:05 <     jokey@> (or any other size value we can come up with)
21:05 < Blackb|rd > armin76: ChangeLog, not Changelog.
21:06 < dberkholz@> i got 52M
21:06 < Blackb|rd > 75.9M
21:06 <      leio > basically the cause of raising this was that stabilizations don't get noted and maintainers, arch testers and the users of that arch might want to see it, so there seems to be a reason to have them noted - maybe arguably. I don't know why some trivial thing is useful to someone to see in ChangeLog and they can clutter the useful things indeed as for example vapier also believes. The problem is that own judgments are made on what should be there
21:06 <      leio >  and what not, making it all inconsistent
21:06 < dberkholz@> from this: find /usr/portage/ -name ChangeLog | xargs du -b | awk 'BEGIN { TOT=0 } { TOT += $1 } END {print TOT}'
21:07 <   impulze > yeah so it's pretty "big" already
21:07 <  ColdWind > and that's collaterally related to arches not dealing with arch bugs
21:07 < FlameBook+> dberkholz: full size of your tree?
21:07 < FlameBook+> [please note that most of those changelog wouldn't take up _less_ space if they where shorten most likely, it depends on your blocksize]
21:07 <Betelgeuse@> leio: The only one I am aware of that doesn't record stuff to ChangeLog is vapier.
21:07 < Blackb|rd > dberkholz: you're right. I shouldn't do public shellscripting
21:07 <   astinus > dberkholz: find . -iname 'ChangeLog' -type f | xargs du -bhc
21:08 <   astinus > dberkholz: 3.2MB?
21:08  *     welp wants to be like vapier and not make changelog entries
21:08 <     jokey@> anyway, "always" still holds, doesn't it?
21:08 <      leio > I admit that I sometimes don't record removals of things when they are really ancient and no-one should have been using them for a long time already.
21:08 < Blackb|rd > astinus: du gets called multiple times
21:08 <    fmccor > leio, I always note any change, and if I look at a ChangeLog, I want to see a track of all changes, whatever they are.
21:08 <      amne@> jokey: yeah, seems block size eats more than the actual changelogs
21:08 <   antarus > so to be fair
21:08 <   impulze > astinus: that's for the last directory
21:08 <   antarus > if you want it to happen all the time
21:09 <      leio > I also don't see whitespace fixes being noted in ChangeLogs, and other things (I haven't done research to bring more examples)
21:09 <   antarus > you should automate it]
21:09 <      amne@> jokey: but that's another issue
21:09 <   antarus > because people are fallable
21:09 <   lu_zero@> I'd keep the current behaviour and avoid changelogs if we switch to something saner
21:09 <   astinus > impulze: well, its for the last invocation of du, which isn't necessarily the last directory =)
21:09 <      welp > i just have a little script which updates the changelog with whatever my repoman commit message is
21:09 <   impulze > astinus: true
21:09 <   impulze > yeah the format of the changelog should be clear and specified so one can extract information out of it
21:09 <     jokey@> lu_zero: ++ on that
21:09 < FlameBook+> welp: I suppose we all have it, just need to call echangelog before the commit :P
21:10 <   astinus > welp: maybe you should loan that script to vapier? ;)
21:10 <   lu_zero@> would be nicer have a stock one in gentoolkit
21:10 <      welp > or even make changelog updates a part of repoman commit?
21:10 < FlameBook+> lu_zero: sincerely, it's a two-lines function, do you need a script?
21:10 <  ColdWind > being realistic and pragmatic, is ChangeLog size related to vapier not using it? I don't think so, so that's OT
21:10 <      welp > but keep echangelog available for the profiles/ Changelog
21:10 < FlameBook+> see what welp just said is something interesting
21:10 <     eroyf > that's what inops is supposed to do as well
21:10 < dberkholz@> this doesn't really seem to be going anywhere
21:10 <     eroyf > if i ever finish it
21:11 <   lu_zero@> Flameeyes I need to have it somewhere just in case
21:11 <     jokey@> dberkholz: ++, move on
21:11 <      leio > he doesn't put stabilizations in ChangeLog on purpose on his own judgment of it cluttering the ChangeLog with "useless" information. He has scripts to do most of it already, but I feel a bit uncomfortable paraphrasing him here like that.
21:11 < FlameBook+> lu_zero: man echangelog then
21:11 <      amne@> dberkholz: agreed. i think we talked about what we should talk and agreed on that
21:11 <   antarus > 'always' :)
21:11 <      welp > no-one's discussing my idea
21:11 <      welp > pfft.
21:11  *     welp goes to sleep, gnight folks
21:12 <      leio > (back to own judgments - I want to see consistency and enforcement and dealing with any complaints that might raise)
21:12 <      amne@> welp: it's beyond what we should discuss here imo. sleep well :-)
21:12 <      amne@> so, shall we move on?
21:12 < dberkholz@> ok, we've made this decision
21:12 < dberkholz@> i'd like if the QA people would help enforce it
21:13 < dberkholz@> if not, we'll have to consider what to do ourselves
21:13 <     jokey@> yup, I volunteer if QA is not in the mood
21:13 <      amne@> sounds good (both what dberkholz and jokey said)
21:14 < FlameBook+> fine
21:14 -!- mode/#gentoo-council [+m] by dberkholz
21:14 < dberkholz@> next topic: Can the council help fewer bugs get ignored by arm/sh/s390 teams?
21:14 -!- Irssi: #gentoo-council: Total of 89 nicks [8 ops, 0 halfops, 2 voices, 79 normal]
21:15 < dberkholz@> the work happens, but apparently it's not communicated to anyone and
21:15 <     jokey@> unless it gets more hardware to test with, highly unlikely
21:15 < dberkholz@> has no relationship to whether bugs are open
21:15 <   lu_zero@> how many people are working on it?
21:15 < dberkholz@> is anyone besides vapier working on any of those?
21:15 <     solar+> the arm team afaik is only vaiper. I help out where I can. There has been requests by users in embedded to see arm be an officially supported arch. But the workload there is nearly unfeasible
21:15 <     jokey@> we have an external "bug contributor", me occasionally when I update my devices and vapier for arm
21:16 <     jokey@> for the rest, no idea
21:16 <   lu_zero@> solar so till we don't have more people working on it
21:16 < FlameBook+> as I said before opening, I have a board dusting around, I haven't set it up yet but I might try soon enough
21:16 <   lu_zero@> I think we cannot do any better
21:16 <     jokey@> okay, solar then as well but that's it
21:16 < dberkholz@> should these arches have stable keywords?
21:17 <   lu_zero@> I think it's up to vapier
21:17 < FlameBook+> on my packages they don't disrupt stabilisation too much, sincerely
21:17 <     solar+> yes. there are some pkgs in ~arch that are not stable. While others are. If arm is making other developers lives harder it would be great if we could start seeing bugs
21:17 <     jokey@> dberkholz: I think so, as unstable breaks there lovely. otherwise we have to hack around with profiles which would be rather messy
21:17 < dberkholz@> bugz search -a arm@ --cc=arm@
21:18 < dberkholz@> shows a nice long list of ~175 bugs
21:18 < dberkholz@> x11 on the other hand only has ~180. =)
21:19 <     solar+> yeah. But if you want me to go hog wild. I can give you another 80 bugs for x11 that would make life eaiser for arm ppl.
21:19 <     jokey@> solar: what about assigning them to embedded with arches in CC?
21:20 <     solar+> most of the arm word is done via cross-compiles vs native compiles due to the speed.
21:20 < dberkholz@> the problem seems to not be the number of open bugs, but the inconsistency between open bugs and reality
21:20 <     jokey@> then it's out of the common bugmail stuff
21:20 <     solar+> jokey: while that might make some sense. I'd like to focus for now on things I'm actually doing. The embedde team is pretty much the same thing as the arm team
21:22 <   lu_zero@> ok
21:22 <     jokey@> dberkholz: maybe we should talk with our bug wranglers to make sure the first part in the summary is always the package name, that way tracking that would be easy
21:23 <     jokey@> or add one of the user values in bugzilla for that
21:23 <     jokey@> (unless I'm mistaken bugzie offers such stuff)
21:23 < dberkholz@> basically i think we need to figure out what vapier's workflow is (and other extremely underpowered arch teams) and see if there's anything we can improve
21:24 < dberkholz@> just randomly discussing things isn't likely to get us far, i think
21:24 <     jokey@> anyway not much we can do here without him being around
21:25 <   lu_zero@> ok let's ask him later
21:25 <   lu_zero@> next topic?
21:25 <     jokey@> yup, all for it
21:25 < dberkholz@> we haven't had open floor
21:25 <     solar+> dberkholz: I can tell you that one of the biggest problems we have is either devs with a lack of hardware and a lack of interest in working on slow arches.
21:25 < dberkholz@> if anyone has anything to say, drop me a quick query
21:26 < FlameBook+> solar: and bad support for crosscompile with the current way ebuilds are specified
21:26 < FlameBook+> missing a BDEPEND/TDEPEND/WHATEVERYOUCALLITDEPEND for CBUILD tools
21:26 <     solar+> mostly libtool getting things wrong
21:26 <     solar+> and portage feature/behavior changes
21:26 < FlameBook+> and libtool getting things wrong becaus of .la files
21:26 <   lu_zero@> eh
21:26 < FlameBook+> and pkg-config that is not built for CTARGET by crossdev (I want to tackle this down)
21:26 <     jokey@> getting OT here, let's just move on
21:26 < FlameBook+> jokey: agreed
21:27 <   lu_zero@> I'd push this on the last open floor
21:27 < dberkholz@> leio noted that improving recuitment efforts (perhaps just a better description on the staffing needs) could help
21:28 < dberkholz@> with that, let's move on
21:28 < dberkholz@> next topic: "PMS: Are versions allowed to have more than 8 digits?"
21:29 -!- Irssi: #gentoo-council: Total of 88 nicks [8 ops, 0 halfops, 2 voices, 78 normal]
21:29 <   lu_zero@> do we have some backgrounds on why this limit had been set?
21:29 <     jokey@> if I recall it correctly, this limitation is something wrt [ ] vs [[ ]]
21:29 -!- mode/#gentoo-council [+vv ferringb zmedico] by dberkholz
21:29 < dberkholz@> any paludis devs here to speak?
21:29 <     solar+> 32bit ints is the problem there I think.
21:29 <   lu_zero@> anybody from the involved party could shed some light on the issue?
21:30 <  ferringb+> two limitations
21:30 < dberkholz@> or other tools this limit affects?
21:30 -!- mode/#gentoo-council [+v ferdy] by Betelgeuse
21:30 <  ferringb+> ints, and floats.
21:30 <  ferringb+> (0.000000000000001)
21:30 -!- mode/#gentoo-council [+v ferdy] by dberkholz
21:30 < dberkholz@> ferdy's voiced for paludis
21:30 <Betelgeuse@> zmedico said that using a Portage version with 8 digit limitations would break in other ways with the current tree when I asked
21:31 <     ferdy+> recent portage is fine from what we've checked, paludis and eix are ok too
21:31 <     solar+> portage handles big ints fine.
21:31 <     ferdy+> portage-utils don't (last I checked)
21:31 <     solar+> that is correct. Fixable but afaik only a few pkgs in the tree require the need
21:32 <   lu_zero@> ferringb ?
21:33 <     jokey@> (afaik he's in a meeting atm, hence slower response times)
21:33 <     ferdy+> if the limit is to stay it should be enforced, otherwise, portage-utils should be either fixed or marked as unsupported
21:33 <  ferringb+> jokey: in between 'em atm.  pkgcore is fine, was the first to be...
21:33 <  ferringb+> portage itself has problems there.
21:34 <  ferringb+> give me a second, looking at the version comparison logic for floats (portage/versions.py around line 75)
21:34 <     solar+> ferdy: yeah I said it's fixable. But I'm not a fan of having to change to longs. It will make atom handling slower.
21:34 <   zmedico+> ferringb: portage uses all strings and ints so it's fine
21:35 <     ferdy+> solar: *nod*
21:35 <     solar+> but then the next limit for it would be 16 or so on 32bit arches.
21:36 <  ferringb+> zmedico: the float comparison logic there is broke offhand
21:36 <     solar+> sorry maybe thats long long that is required.
21:36 <  ferringb+> zmedico: try 0.01 vs 0.1.
21:36 < FlameBook+> solar: let's call it uint64_t :)
21:36 <     solar+> FlameBook: patches welcome :)
21:36 <  ferringb+> either way, technically it'll support long long there, just doesn't do the float comparison rules...
21:36 < dberkholz@> my basic philosophy here is that the package manager shouldn't get in the way of the packagers, so if >8 makes some packages easier, it should be allowed
21:37 < dberkholz@> what's using >8 now?
21:37 <     solar+> dberkholz: gradm
21:37 <     ferdy+> net-tools
21:37 <     jokey@> afaik mplayer was one of them, not sure though
21:38 <     solar+> gradm-2.1.11.200804142058 (YYYY/MM/DD/HH/MIN) and to change the logic would be a real pita
21:39 < dberkholz@> sys-process/fuser-bsd
21:39 < dberkholz@> sys-apps/net-tools
21:39 < dberkholz@> sys-apps/gradm
21:39 < dberkholz@> net-im/ntame
21:39 < dberkholz@> media-video/captury
21:39 < dberkholz@> media-libs/libcaptury
21:39 < dberkholz@> media-libs/capseo
21:39 < dberkholz@> sys-block/btrace
21:39 < dberkholz@> www-apache/mod_depends
21:39 < dberkholz@> net-wireless/rt2500
21:39 < dberkholz@> sys-fs/unionfs
21:39 < dberkholz@> those all have 9 or more numbers in a row
21:40 < dberkholz@> anyone have something more to add before we open the floor for discussion prior to the vote?
21:40 <     solar+> so clearly we can see developers have legit reasons for using more than 8 numerics in a row. And we can see the advantage of limiting it to 8.
21:41 <   lu_zero@> solar splitting the value is that problematic for devs?
21:41 < dberkholz@> solar, ferdy: i don't suppose you have any idea what the magnitude of performance loss is when going from int to long
21:41 <   lu_zero@> and vice-versa
21:42 <     ferdy+> dberkholz: such a comparision has never showed up in any of my profiles, so I'd say 0 in a package manager
21:42 <  ferringb+> dberkholz: why would it matter?  this isn't exactly the hotspot of any package manager...
21:42 <     ferdy+> also, versionator.eclass doesn't handle it properly either
21:42 <  ferringb+> ferdy: versionator has a few other bugs iirc anyways
21:43 <     solar+> dberkholz: I think it's the 32bit arches that would take the biggest hit there at the low level. sending 2x as much data over the bus as required for every lookup.
21:43 < dberkholz@> ferringb: solar expressed a concern about portage-utils ... 
21:43 <  ferringb+> parsing is going to cost more then int -> long conversion
21:43 <     ferdy+> ferringb: I don't follow....
21:43 <     solar+> I don't mind changing portage-utils. Thats pretty easy
21:43 <     ferdy+> ferringb: I mean, fine, it has more bugs. But it is also kind of irrelevant to what is being discussed (the 8 digit limit)
21:44 <  ferringb+> ferdy: saying it needs fixing anyways ;)
21:44 <  ferringb+> so not really much of a blocker imo
21:44 <     ferdy+> I'm not touching versionator myself.... the council can find someone to do it :)
21:44 <   lu_zero@> brr
21:44 <     ferdy+> but versionator should be fixed if the limit is to go
21:46 < FlameBook+> if any of the packages using the then-extended limit needs versionator... as long as there is no need for versionator on those ebuilds it can be put in lower priority
21:46 < dberkholz@> ok, let's open it up to see if anyone else has a new point
21:46 -!- mode/#gentoo-council [-m] by dberkholz
21:46 <     ferdy+> that's pretty fragile
21:46 <     solar+> to go? afaik this has never been really discussed. Before opting to vote. Perhaps contacting the devs of the pkgs in question and asking for input from them might help in the council make an informed desision?
21:47 <   lu_zero@> solar agreed
21:47 <  ferringb+> dberkholz: anyone check into the [ ]/[[ ]] issue I mentioned?
21:47 <     ferdy+> I meant to go away from PMS
21:47 <  ferringb+> specifically when bash introduced the double bracket support?
21:47 < dberkholz@> double brackets have been around since 2.05 at least, arrays were in 2.05
21:48 <  ferringb+> 'k.  so... only downside to >8, is that any code using  [ ] goes boom w/ a large enough number.
21:48 <       ulm > this is not exactly related to the package manager, but aren't version components with > 8 digits pretty difficult to read? what's the problem with splitting YYYYMMDDHHMM into YYYYMMDD.HHMM?
21:48 <   lu_zero@> ulm none that I can see
21:48 <   lu_zero@> but the devs managing that could tell us more
21:49 <  ColdWind > ulm: that's really annoying with net-tools, when it comes to dates it's annoying, although it'd be nice to follow it if upstream does it
21:49 <     solar+> ulm: that could probably be done. But then it does not exactly match upstream versioning and becomes a little ulgy to do all the parsing in the ebuilds to get SRC_URI right.
21:49 < dberkholz@> ulm: slightly more annoying to have to parse that into SRC_URI
21:49 < dberkholz@> ulm: particularly once they release 2008050816.1
21:49 <Betelgeuse@> solar: we could write versionator functions for it
21:49 <Betelgeuse@> solar: delete_version_separator N
21:49 <    Cardoe > Betelgeuse: if you wanna maintain versionator...
21:50 < Blackb|rd > Also note that 2^31 is 2147483648 (I suspect that that's the problem). Thats a signed 32-bit int. What's the problem with this? it's more than a hundred years in the future? Even more so for 2^32.
21:50 < FlameBook+> dberkholz: remember to never let you choose a version number for anything ;)
21:50 <    Cardoe > someone keeps trying to pawn versionator off on me.
21:50 <       ulm > dberkholz: you parse it once and then you're done for that package
21:50 <Betelgeuse@> There actually is one already.
21:50 <  ColdWind > if you finally decide to remove the 8 eight limit... please, people should use common sense and don't use such annoying version if there's no good reason (e.g. upstream using that scheme)
21:50 < dberkholz@> ulm: right, so you repeat this thing and add extra code for every package doing it instead of having native PM support
21:50 < dberkholz@> ulm: that sounds like the tool getting in your way
21:50 < Blackb|rd > Oh. H:M. nevermind me.
21:51 <Betelgeuse@> So basically we could keep the 8 digit limit and make people use versionator too.l
21:51 <Betelgeuse@> Or are there issues with that?
21:51 <     ferdy+> it gets in the way of maintainers....
21:51 < FlameBook+> Betelgeuse: slower?
21:51 <     ferdy+> it is always better to use what upstream uses
21:51 <   lu_zero@> I'd ask them first
21:51 < FlameBook+> for once I'm agreeing with ferdy, I'd quite rather follow upstream
21:51 -!- ajp is now known as Ida
21:51 <     solar+> or dump the idea and continue down the existing path. Perhaps limiting it to uint64_t
21:52 <       ulm > solar: how many digits is that?
21:52 <     ferdy+> about 20 iirc
21:53 <       ulm > well, 19 for unsigned and 18 for signed
21:53 < Blackb|rd > ferdy: 20, yes
21:54 <       ulm > Blackb|rd: 2^64 has 20 digits, but you can not represent all 20-digit numbers
21:54 <   impulze > exactly
21:54 <   impulze > the first one is dismissed
21:54 < FlameBook+> portage-utils could probably just use string comparison for sorting to make it accept arbitrarily-sized values
21:54 <   impulze > so it's 19 unsigned and 18 signed just as ulm said :)
21:54 <     ferdy+> the only reason I see to have a limit here is to ease implementation
21:55 < FlameBook+> and pkgcore/portage said above they use strings comparison
21:55 < Blackb|rd > ulm: exactly.
21:55 < FlameBook+> ferdy: I suppose paludis does/could use string comparison too?
21:56 <     ferdy+> paludis supports an arbitrary long revision 'number', yes
21:56 <     solar+> FlameBook: Re:strings. not going to do that to get the equiv of big ints.
21:56 < FlameBook+> solar: I said could :)
21:57 <   lu_zero@> still I'd set a sane limit
21:57 < dberkholz@> ok, so there's 11 packages using >8 digits, and 0 packages using >18 digits. that seems to set a fairly good range where this is useful
21:57 <   lu_zero@> dberkholz ++
21:57 < FlameBook+> yeah and if we need to go over that and we have reasons to do that, we'll discuss it in the future
21:57 <     solar+> so unsigned long long is the desired max limit?
21:57 < FlameBook+> for now < 18 should be fine
21:58 < dberkholz@> and 2 packages using 14 digits, those are the longest
21:58 < FlameBook+> solar: uint64_t (I hate long/longlong)
21:58 < dberkholz@> so i favor a 64-bit limit
21:58 <     solar+> FlameBook: afaik. Don't you get into typecasting problems when trying to printf() on that
21:58 <       ulm > FlameBook: I'd go for <= 18 to play it safe. then it fits into signed 64 bit
21:59 <     solar+> where knowing ulong long will always be "%lu"
21:59 < FlameBook+> solar: "this is a uint64_t: " PRId64 "\n"
21:59 <     ferdy+> actually, the limit should be 18 digits and not a C type
21:59 < dberkholz@> ferdy: expecting negative versions?
22:00 <     ferdy+> I'm not, I just think it is more clear in a document like PMS
22:00 < dberkholz@> (in other words, why not 19?)
22:00 < FlameBook+> solar: for what it's worth, %lu has different size on 32-bit and 64-arches, stdint.h makes it explicit on the size
22:00 <    fmccor > Someone did that once (smalleiffel)
22:00 <     ferdy+> dberkholz: I'm fine with either, honestly :)
22:00 < FlameBook+> fmccor: can we propose upstream sniping if that repeats?
22:00 < dberkholz@> if we're effectively doing this to make things fit into 64 bits, we might as well take the biggest advantage of that as possible and go with <20
22:01 <       ulm > dberkholz: noone is using > 14
22:01 <    fmccor > FlameBook, They were counting up to the release at 0.0 (It's smarteiffel now).
22:02 <     jokey@> I'm also for limiting it on something like 14 or so
22:02 < FlameBook+> they got smart and stopped doing negative versions?
22:02 <     jokey@> rest simply doesn't make sense
22:02 <NeddySeago > Don't design it here
22:02 <     solar+> FlameBook: well I'm all for patches. But dealing with full strings would be kinda ulgy+slow (think arm at runtime). We have a really nice/fast atom parser in portage-utils and I'd love to avoid slowing it down for cases which would probably never exist. (60+ digit etc..).
22:02 < dberkholz@> ulm: what's the reason for creating an arbitrary restriction like 14, when your storage could hold more?
22:02 <       ulm > dberkholz: and 19 doesn't work in bash
22:02 <       ulm > 18 does
22:02 < dberkholz@> ulm: what does work in bash, then
22:03 <       ulm > ^^
22:03 < dberkholz@> ok, presumably bash uses signed longs..
22:03 < FlameBook+> solar: that's why I said we can discuss that _if_ the problem arises
22:03 < FlameBook+> solar: and yeah I would expect it to be slow on RISC... x86 wouldn't probably be affected
22:03 <       ulm > dberkholz: yep
22:03 <   lu_zero@> anyway uint64_t is a good storage for now
22:03 <  ferringb+> mmm.  pkgcore cpy extension probably has a limitation on rev range, although said limitation can be backed out easily enough
22:04 < dberkholz@> the way i'd like to word this is <=18 digits, since someone's already mentioned that having a rule as a C datatype isn't the best..
22:04 <   lu_zero@> fine
22:04 < dberkholz@> date-based versions give 14 digits (yyyymmddhhmmss), and that leaves an additional 4 for whatever other weirdness they think up
22:05 <     solar+> bash is written in c :)
22:05 < dberkholz@> for example milliseconds
22:05 <     solar+> unixtime etc.
22:05 <  RobbieAB > For what it is worth, I think assumeing version numbers are positive is a bad idea, as it's an invitation for someone to do a negative version number... :)
22:05 < dberkholz@> although i pray nobody does that
22:05 <   astinus > dberkholz: yyyymmddhhmmss1337
22:05 < dberkholz@> anyone got a new point, or are we ready to vote?
22:06 <    fmccor > RobbieAB, As I mentioned, it's happened. :)
22:06 <   astinus > dberkholz: I think RobbieAB makes a good point.
22:06 < dberkholz@> we aren't making that assumption, actually... the reduction to <=18 allows for it in a 64-bit number
22:06 < Blackb|rd > astinus: making them integers, asks for reals, making them reals asks for irrationals, irrationals asks for complex.
22:07 <      leio > such long numbers should be heavily discouraged as noted before and not used without good reason (yyyymmddhhmmss isn't one)..
22:07 < FlameBook+> Blackb|rd: complex?
22:07 < Blackb|rd > astinus: just kidding ;)
22:07 <   astinus > leio: We cannot influence upstream.
22:07 < Blackb|rd > FlameBook: imaginary+real
22:07 <     ferdy+> wait, are you suggesting '-r-91828383' ?
22:07 < FlameBook+> Blackb|rd: I know what imaginary is...
22:07 < FlameBook+> err complex is I meant
22:07 <     solar+> that would never parse correctly anyway :)
22:07 <   lu_zero@> =_=
22:07 < FlameBook+> I meant what would they ask after that?
22:07 <      leio > upstream using it is a good reason, our own snapshots unreadable like that without separators isn't (imho)
22:07 <     ferdy+> solar: exactly my point
22:07 <   lu_zero@> let's ignore the issue
22:08 < Blackb|rd > FlameBook: don't look at me, I wouldn't do it, I'm just extrapolating
22:08 < Blackb|rd > FlameBook: after complex? I dunno. Multidimensional vectors?
22:08 < FlameBook+> Blackb|rd: non-arabic numeric systems?
22:08 <     solar+> in version atoms?
22:08 <   lu_zero@> =_=
22:08 < Blackb|rd > FlameBook: nifty. roman numerals would be a nice challenge
22:08 <   lu_zero@> let's stay sane
22:08 < dberkholz@> portage-(2+3i,4+2i).ebuild
22:08 <     ferdy+> ok, can we get this rolling?
22:08 < Blackb|rd > lu_zero: ok.
22:09 < FlameBook+> lu_zero: stay?
22:09 <   lu_zero@> get
22:09 <   astinus > We're way past the 2hr mark and the next topic will be heated. We seem to be getting away from the point too. The suggestion was <=18 and not to be more specific about implementation.
22:09 <   lu_zero@> saner at least
22:09 < FlameBook+> ferdy: D20 or D10?
22:09 < dberkholz@> since nobody's really brought up anything new, let's vote
22:09 < dberkholz@> remoderating
22:09 <   lu_zero@> ok
22:09 -!- mode/#gentoo-council [+m] by dberkholz
22:09 -!- Irssi: #gentoo-council: Total of 88 nicks [7 ops, 0 halfops, 5 voices, 76 normal]
22:09 -!- mode/#gentoo-council [-vvv ferdy ferringb zmedico] by dberkholz
22:09 -!- Irssi: #gentoo-council: Total of 88 nicks [7 ops, 0 halfops, 2 voices, 79 normal]
22:09 <     solar+> dberkholz: what i said till holds. I think there should be no such limitation put in place right now. As for a vote I think you should not vote till asking for input from all the authors of the ebuilds in question.
22:09 <   lu_zero@> I'm fine with the 18 digits limits
22:10 <   lu_zero@> and should be pretty much a sane upper bound
22:10 <      amne@> what solar says makes sense
22:10 <   lu_zero@> the switch between uint32 and uint64 shouldn't hit too much IMHO
22:11 <     solar+> I can't stop at 18 but extending it past 8 would be fine..
22:11 < dberkholz@> i looked at a number of those ebuilds, and they're all based on upstream versioning
22:11 <      amne@> i don't think a vote is necessary right now
22:11 <   lu_zero@> solar could you check the performance hit on small arches?
22:12 <     solar+> lu_zero: I probably wont have time for that.
22:12 <     solar+> but the eclass is what will see the biggest hit
22:13 <   lu_zero@> solar ok
22:13 < FlameBook+> I'm fine with extending to 18 for now and leaving open for the future to be discussed
22:15 <      amne@> are we going to vote on anything right now? because i really have to go get some sleep, i'll have to get up again in 2.5 hours unluckily, so i cannot attend the meeting any longer (but hey, i was marked slacker anyway already)
22:16 < dberkholz@> jokey apparently ran into computer difficulties
22:16  *  lu_zero is almost asleep
22:16 < dberkholz@> it might be reasonable to test the impact of the change in versionator before voting
22:18 < dberkholz@> so we've got 3 options here, let's see where people stand on them
22:19 < dberkholz@> 1) allow <=18 now. 2) keep at 8 digits. 3) further research with package maintainers and testing of the impact
22:19 <Betelgeuse@> Well isn't versionator performance more of an issue with the cache generation machine?
22:19 <Betelgeuse@> And it's not one of the slower arches.
22:20 < dberkholz@> which options do you like, folks?
22:20 < FlameBook+> I'm fine with 1 and 3
22:20 < dberkholz@> 1 or 3 seem ok to me
22:20  *     amne is for 3) and out now
22:20 <   lu_zero@> same
22:20 <   lu_zero@> 1 and 3
22:20 < dberkholz@> we already know solar's for 3
22:21 < dberkholz@> that makes 3 people for option-1, and 5 people for option-3
22:23 <Betelgeuse@> Might as we well go with 3 but say that people can add new >8 if they need to.
22:23 < dberkholz@> i put the details we discussed of the further research into http://dev.gentoo.org/~dberkholz/20080508-summary.txt
22:23 <   lu_zero@> ok
22:27 -!- Irssi: #gentoo-council: Total of 86 nicks [7 ops, 0 halfops, 2 voices, 77 normal]
22:27 < dberkholz@> since it's already getting late for a couple of you, and a couple others aren't here today, here's what i'd suggest
22:28 < dberkholz@> we can cover the background information on the enforced retirement today and plan a special session in the next week or so to make the decisions mentioned in the agenda
22:29 -!- mode/#gentoo-council [+v musikc] by dberkholz
22:29  *   musikc waves
22:29 <   lu_zero@> hi musikc
22:29 -!- mode/#gentoo-council [+v fmccor] by dberkholz
22:29 <    fmccor+> Good evening.
22:30 < dberkholz@> i'd like to ask the directly involved people (council + musikc + fmccor, mainly) to tell us how that works for them
22:30 <    fmccor+> dberkholz, It's fine with me to delay the entire discussion.  It's not time critical.
22:30 <    musikc+> wfm
22:30 <   lu_zero@> I can resist for another hour
22:30 <   lu_zero@> both ways are fine
22:31 < dberkholz@> i'm aware that we really need to get some action one way or the other for everyone's sake, so i don't think we should wait until the next regularly scheduled meeting
22:31 <    musikc+> agreed
22:31 <    fmccor+> dberkholz, sure.
22:31 <    musikc+> i think it will do more to ease the minds of others if we talk about it sooner than later
22:32 < FlameBook+> I'm fine with the reschedule, as I'm probably going away soon, too
22:32 < FlameBook+> [reschedule to special I mean]
22:32 <    fmccor+> Right
22:32 <    musikc+> and for anyone reading in doubt, please do not assume that council made me take a particular course of action. i apologize if that is how it was interpretted but again that is just not how it happened.
22:32 < dberkholz@> how about next week, same bat time, same bat channel as a tentative date -- how's that work for people?
22:33 <    musikc+> sure, i just cant be available for 2+ hours because it is the middle of my work day
22:33 <    fmccor+> Works for me.  Please send a email or something so as not to make a liar of me. :)
22:33 < dberkholz@> that appears to be almost immediately following the trustees meeting
22:33 < dberkholz@> if my calendar is right
22:34 <    fmccor+> trustees are meeting in special session this Sunday and regular meeting a week from Sunday.
22:34 < dberkholz@> hm, apparently the google calendar is wrong
22:34 < dberkholz@> it says thursday may 15
22:34 < dberkholz@> following the may 10 session
22:34 <    fmccor+> That's wrong.
22:35 < dberkholz@> rane: could you fix the calendar, please? looks like you posted the trustees meeting on may 15 three days early
22:35 <    fmccor+> Should say the 11th and the 17th
22:36 < dberkholz@> i was in my localtime...might be different in utc.
22:36 < dberkholz@> ok. do we agree that we'll cover the entire topic in our upcoming special session?
22:36 <    fmccor+> (Er, no.  11th and 11+7 = 18th (11+7 us not 17, I guess)
22:37 <    fmccor+> Should say 11th and 18th, both at 1900UTC
22:38 < dberkholz@> i think it makes more sense than breaking the related subtopics apart
22:38 <    fmccor+> dberkholz, Sorry for the confusion.  Havving problems with addition, I guess.
22:38 <    fmccor+> That works fine for me.
22:38 <   lu_zero@> ^^;
22:38 -!- Irssi: #gentoo-council: Total of 85 nicks [7 ops, 0 halfops, 4 voices, 74 normal]
22:39 <    musikc+> ok, so we all agree to meet same time next week to cover the remaining topic of retirements/how handled/appeals/etc?
22:39 < dberkholz@> amne, Betelgeuse, FlameBook, solar -- rescheduling to a special session work?
22:40 < dberkholz@> ah, FlameBook already said yes
22:40 <Betelgeuse@> o
22:40 <Betelgeuse@> k
22:41 < dberkholz@> looks like amne went to bed
22:41 < dberkholz@> enough of us agree on that, so let's do it
22:41 < dberkholz@> that brings us to the open floor
22:42 < dberkholz@> does anyone else have any topics unrelated to either today's topics or the special session?
22:42 -!- mode/#gentoo-council [-m] by dberkholz
22:42 < Blackb|rd > Thanks, guys (and gal).
22:42 <    fmccor+> Thanks, that works better for me at this point (over 2.5 hours and counting). :)
22:42  * Blackb|r heads for bed now :)
22:43 <   lu_zero@> I'd wait for 10min and then go to bed as well
22:43 <   astinus > this just proves ideas to cut down meeting time *FAIL*
22:43 <      rane > i fixed the calnder
22:43 <      rane > calendar
22:44 <      zlin > yeah, keeping people waiting for 2½ hours just to tell them it gets delayed a week is fucking awesome
22:44 < dberkholz@> yeah, wonder whether we should try all-moderated except the final open floor, and just let people query the chair or other council members
22:44 < dberkholz@> i had no idea the earlier topics would take so long, that was insane
22:45 <    fmccor+> rane, You caught my addition error that 11+7 is 18, not 17?
22:45 <    musikc+> dberkholz, that sounds like a good idea to me
22:45 <   astinus > zlin: Wow, someone forgot to take their calm pills this evening :S
22:45 <  ColdWind > zlin: I agree, but that's mostly due to all the version length nonsense
22:45 <    musikc+> it is prime business hours in the states and close to bed time for a lot of other folks
22:46 <    fmccor+> dberkholz, I don't think the time went to the open floor parts.
22:46  * RobbieAB agrees with fmccor
22:46 <      zlin > fucking waste of time
22:46 <      Sput > basically discussing implementation details for two hours...
22:47 <   astinus > zlin: Actually quite a lot got discussed/agreed.
22:47 <      zlin > ColdWind: and even that was too hard to make a decision on
22:47  *  astinus forcefeeds zlin some positivity potion.
22:47 < dberkholz@> there was a decision, it was "not enough data"
22:48 < dberkholz@> seemant had a nice philosophy of "show me the code", so i tend to agree that seeing the impact in code and real numbers would help
22:49 <      zlin > dberkholz: even if I agree with that it shouldn't take an hour to figure that out
22:49 -!- fmccor is now known as fmccor|home
22:49 <      zlin > s/agree/agreed/
22:49 < dberkholz@> zlin: you're right, i wish it went faster. do you have any advice on how to do that?
22:49 <      zlin > who's going to collect those data btw?
22:50 <  RobbieAB > dberkholz: not ask anyone else for input? It would be much faster that way... </sarcasm>
22:50 <      rane > fmccor|home, yes, i did
22:50 <fmccor|hom+> rane :)
22:51 < dberkholz@> i've gotta migrate to a new location, should be back in ~5 min
22:51 <      zlin > dberkholz: I wouldn't actually give a fuck if I hadn't been sitting and waiting for the outcome of those appeals..
22:51 <  ColdWind > it will make things faster if discussion about negative, complex, and non-arabic versions are banned ;)
22:51 <      rane > zlin, i was doing other stuff while they were busy figuring out if bash support 18+ or not
22:51 <   astinus > zlin: the appeals were never happening today?
22:52 <      rane > zlin, you should try it next time :-)
22:52 <      zlin > astinus: huh?
22:52 <   astinus > zlin: the appeals themselves were not tabled for today
22:52  *   Fieldy passes around some calm pills
22:52  *     rane takes all of them
22:53 <  RobbieAB > ColdWind: negative versioning has occurred, so in the context of lu_zero advocating uint_64t it was relevant.
22:53  * ColdWind goes and release something with complex numbers
22:53 <  ColdWind > :p
22:54 <   astinus > zlin: what was tabled today was fmccor+musikc presenting Council with the facts, and a discussion about how to proceed with the appeals, if at all?
22:54 <   astinus > ie: if they should be held at all. When. Should it involve the whole Council, or a panel of 2-3 to keep things simpler, etc
22:54 <   astinus > unless I'm drastically misreading the agenda :)
22:55 <  RobbieAB > ColdWind: lol.
22:55  *    pilla releases something with a quantic version number
22:56 <      rane > release something with no version number
22:56 <jmbsvicett > astinus: That's not how I read the topic
22:56 <  ColdWind > rane: that's occurs too often already
22:56 <    musikc+> astinus, i wasnt aware that i was presenting anything
22:56 <   astinus > jmbsvicetto: Fair enough, maybe Donnie could clarify.
22:56 <jmbsvicett > astinus: And the appeals were made on time for this meeting
22:57 <   astinus > jmbsvicetto: yet the folks supposedly appealing weren't asked to be present?
22:57 <jmbsvicett > astinus: I'm not a council member ;)
22:57 <    musikc+> here's what is in the summary:
22:57 <    musikc+> What was the council's role in the recent enforced retirement of 3 developers?
22:57 <      rane > we should discuss policies before we start using them
22:57 <    musikc+> Why does the council permit such actions in apparent violation of Gentoo's policy of openness?
22:58 <    musikc+> What is the council's role in an appeal?
22:58 <   astinus > musikc: Part of my point still stands. Other than discussing the role of Council in an appeal process, there is no actual appeal on the agenda, ie: Philantrop's
22:58 <jmbsvicett > musikc: Yes, I noticed. But at least 2 of the members appealed on time for this meeting. I find it reasonable to expect some discussion about the appeals
22:59 <    musikc+> astinus, ahhh... so you wish to know when council will respond to the appeals?
22:59 <   astinus > musikc: no.
22:59 <   astinus > 23:49 < zlin> dberkholz: I wouldn't actually give a fuck if I hadn't been sitting and waiting for  the outcome of those appeals..
22:59 <   astinus > musikc: I was responding to that ^^^^
22:59 <  RobbieAB > jmbsvicetto: council can't table the appeals until it has decided if it is going to hear them...
22:59 <    musikc+> ahhh
22:59 <jmbsvicett > astinus: He sent a mail to council asking for that
22:59 <     p0w4h > hi im learning cisco
22:59 <Betelgeuse@> We should discuss starting the meeting an hour earlier.
23:00 <Betelgeuse@> I am heading for bed.
23:01 <    musikc+> nn Betelgeuse
23:04 -!- Irssi: #gentoo-council: Total of 80 nicks [7 ops, 0 halfops, 3 voices, 70 normal]
23:05 < dberkholz@> since nobody's said anything for 5 minutes, and most of the discussion has been venting, anyone mind if we end the meeting?
23:05 <   astinus > thought we had =)
23:06 < dberkholz@> effectively yes, since everybody's going to sleep
23:06 <jmbsvicett > RobbieAB / astinus: I understand your argument, but I expect the council to make a decision about accepting or not the appeal in a "reasonable" timeframe
23:06 <   astinus > dberkholz: Would you mind clearing up exactly what's meant by the final items on the agenda, and what will be discussed in the special meeting, please?
23:06 <jmbsvicett > My "unreasonable" response time was caused by network connectivity issue
23:06 <jmbsvicett > +s
23:07 < dberkholz@> astinus: the intent was not to make a decision on the appeal, but to explain the council's role so far and to decide exactly how to proceed with it. we haven't done any appeals before, so we need to figure out the best way how.
23:08 <   astinus > dberkholz: But the implication is you're accepting the appeal and are somehow going to hear it, where 'somehow' is TBD?
23:08 <jmbsvicett > dberkholz: By the way, the last point about the council role, only applies if the Council starts the action - that has been my argument and I think Ferris
23:08 <   astinus > or is the decision to accept/reject the appeal also TBD?
23:09 < dberkholz@> astinus: it's kind of a big mess because of some ideas brought up by ferris and co. my opinion is that we can take the appeal, we will take it, we will figure out the best way to handle it, and then we will handle it.
23:09 <jmbsvicett > dberkholz: As long as devrel takes the action, I don't see any "conflict"
23:10 <   astinus > jmbsvicetto: and that's already been cleared up by musikc - she said above that Council wasn't the guys taking that decision
23:10 <    musikc+> jmbsvicetto, *I* took the action
23:11 <jmbsvicett > musikc: sorry, I didn't meant to imply otherwise
23:11 <    musikc+> all council did was say hey, there is talk that devrel doesnt respond to complaints, please do acknowledge these
23:11 <jmbsvicett > musikc / astinus: I was going to finish my thought by saying that I've been told and have no reason to doubt that it was musikc's action
23:12 <   astinus > most of the "devrel hasn't done squat in these types of complaints" ruckus was caused by me, as *previously* DevRel has had great difficulty getting off its rumpus and actually doing anything
23:12 <jmbsvicett > musikc: I'm sorry for not completing the thought. I was caught no /msg
23:12 <   astinus > which I already apologized to musikc for ;)
23:12 <    musikc+> astinus, it's ok, you had a valid point
23:13 <    musikc+> people have expressed similar, that they too felt devrel wouldnt take action. bear in mind i did not do something extreme just to show that we would, i stand by my decisions.
23:14 <    musikc+> the only thing council really did was advise me what devrel had authority to do and to what extent, hence the policy change in devrel, as i was advised it was always policy whether i wrote it or not it always existed.
23:14 <    musikc+> i know some people were upset about a change in policy followed by action, and i have apologized to my team and to anyone who cared to discuss it with me for confusion and lack of communication.
23:14 <    musikc+> <end soap box>
23:15 <   astinus > I think the 'danger' of Gentoo getting bigger is a culture of red tape setting in
23:15 <   astinus > everything has to be discussed and approved by committees of committees of committees, so everything takes 4 years
23:16 <   astinus > personally I'm a fan of trusting the guys in a role -- if policy is slow, and we want change, do it. Folks like Council and Trustees are there to second guess via appeals
23:16 <      Sput > that said, has that particular bug been opened to the public yet?
23:16 <   astinus > and we in turn trust Council via the election/voting process.
23:16 <   astinus > Sput: yes.
23:16 <      Sput > kk
23:16 <   astinus > Sput: there's nothing on it, despite how much people hyped "ZOMG SEKRIT BUG!"
23:17 <      zlin > for about ten minutes. then it was closed to non-devs.
23:17 <      Sput > astinus: not very surprised about that, but I think closing it at all was causing a lot of uproar
23:17 <      Sput > I mean if there is nothing to hide, why pretend there is?
23:18 <   astinus > Sput: part of the problem is it was locked to Infra
23:18 <fmccor|hom+> Sput, Last I knew, it was developers-only.
23:18 <   hparker > Keeps the cabal theories flying
23:18 <   astinus > Sput: which means someone from Infra needs to unlock it =) and relatively few people have that foo