Rename log to correct name (.txt instead of .log). Reported by Duncan.

1 files changed, 795 insertions, 0 deletions

diff --git a/meeting-logs/20080508.txt b/meeting-logs/20080508.txt
new file mode 100644
index 0000000..c07a4c6
--- /dev/null
+++ b/meeting-logs/20080508.txt
@@ -0,0 +1,795 @@
+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