path: root/meeting-logs/20080110.txt

# Log started, 10.01.2008 21:00 CET

[21:01:22] jokey gives betelgeuse another 3 minutes
[21:02:08] <fmccor> He's active in !c#gentoo-devrel
[21:04:06] <@jokey> well ok, let's start, roll-call 
[21:04:12] <@lu_zero> ok
[21:04:25] welp [n=welp@!hgentoo/developer/colchester-lug.member.welp] has joined !c#gentoo-council
[21:04:47] <@jokey> amne: ?
[21:05:28] Betelgeuse [n=betelgeu@!hgentoo/developer/Betelgeuse] has joined !c#gentoo-council
[21:05:28] ChanServ [ChanServ@!hservices.] has set mode +o Betelgeuse
[21:05:42] <@jokey> Hi Betelgeuse
[21:05:49] <@amne> oi
[21:05:49] <@jokey> we're just about to start ;)
[21:05:53] <@Betelgeuse> hmm a couple minutes late
[21:06:09] <+musikc> <----  dberkholz's proxy
[21:06:50] <@lu_zero> who's missing?
[21:07:00] <@jokey> all alive :)
[21:07:22] <@jokey> so, !c#1 is GLEP 54: scm package version suffix
[21:07:33] <@vapier> discussion, not voting
[21:07:51] <@lu_zero> who is going to start?
[21:07:58] ferdy [n=ferdy@!hgentoo/developer/ferdy] has joined !c#gentoo-council
[21:08:17] <@jokey> first of all, everyone read it, right?
[21:08:30] <@vapier> i dont think roll-call finished ;)
[21:08:49] <@vapier> FlameBook = ?
[21:09:02] <welp> Flameeyes
[21:09:07] <@FlameBook> vapier, I'm here, I'd just be lesser profile than usual (because of a cold0
[21:09:12] <welp> oh
[21:09:24] welp thought vapier didn't know who FlameBook was
[21:10:36] <@Betelgeuse> Well the GLEP is not in a hurry as it needss a new Portage version.
[21:10:40] <genone> if I may say somehing about it
[21:10:50] <@jokey> sure genone
[21:11:15] <@vapier> input from genone / zmedico / friends surely welcome
[21:12:44] <genone> I have three issues with it: 1) no statement about compability/implementation plans 2) while a distinction between CPV and atom may not be techincally required, I still think it's useful to have 3) (minor) if the version part is optionl there could be some complications
[21:13:26] <genone> 1) is somewhat related to glep55, but also an issue if that would be accepted
[21:14:09] <genone> 3) is mostly my dislike for special cases required by the glep
[21:14:41] <@lu_zero> hmm
[21:14:51] <genone> (haven't brought those up on the ML as they would just have resulted in other endless threads)
[21:16:46] <@jokey> I'm with genone on 1) at least
[21:17:00] <peper> genone: pkg-1a PN-PV or PN?
[21:17:21] <genone> peper: former
[21:17:50] <@vapier> anyone know the bug !c# for the original request for a "cvs" version string ?
[21:17:57] <@lu_zero> hmm btw in what it differs than the -cvs?
[21:18:11] <peper> genone: why?
[21:18:13] <@jokey> backwards compatibility is certainly important as people may start with 2007.0 stages and then face that problem as a sidenote
[21:18:20] <peper> genone: pkg-1a is a valid package name
[21:19:24] <@Betelgeuse> Well IMHO we should first decide whether we think the idea itself is something we want to have.
[21:19:42] <@Betelgeuse> If we are against the idea then there is no point in disgussing the technical details.
[21:19:42] <igli> it's also a valid PF
[21:20:02] <genone> vapier: http://bugs.gentoo.org/show_bug.cgi?id=9202
[21:20:16] <peper> igli: that's the point
[21:20:33] <@vapier> Betelgeuse: i think the concept has been long outstanding
[21:20:41] <@amne> Betelgeuse: also define what the idea is. i) having some support for SCM ebuilds (good idea imho) ii) doing it via changing the naming scheme
[21:21:00] <@vapier> i started using -9999 because Bug 9202 was outstanding
[21:21:05] <jeeves> vapier: https://bugs.gentoo.org/9202 enh, P2, x86, sbc28@cornell.edu->dev-portage@gentoo.org, RESOLVED, DUPLICATE, Better support for CVS Ebuilds...
[21:21:15] <@jokey> amne: idea behind is obvious imho
[21:21:21] <@lu_zero> vapier still I see some problems in the idea of usage
[21:21:34] <@vapier> i'm trying to see why "-scm" (which would require quite a bit of changes everywhere) is better than "_scm" (which would be trivial to drop in everywhere)
[21:22:02] <@lu_zero> since -9999 ebuild should stay p.masked
[21:22:02] <peper> b/c scm is different than other suffixes we have
[21:22:22] <igli> peper: so as a random string it matches PF regex; hence it's parsed as PF with no context. what's your point?
[21:22:36] <@amne> http://bugs.gentoo.org/show_bug.cgi?id=9202
[21:22:38] <@amne> oops
[21:22:46] <@amne> sorry, copy and paste error
[21:22:59] <@FlameBook> vapier, I sincerely find myself comfortable with -9999 and x.y.9999 versioning too, needing no extra support...
[21:23:06] <@jokey> peper: I don't agree that it's any different from CPV pov
[21:23:43] <@jokey> FlameBook: the idea is to follow _pre versions and just make it scm aware (so you get the next stable release without any major work)
[21:24:01] <genone> to make it clear: I don't have a problem with the idea itself (portage already has a similar, though unused extension), I'm just not completely comfortable with the details
[21:24:17] <@FlameBook> jokey, see amarok: 1.4.9999 will follow any 1.4.9_preXXXXX version
[21:24:27] <peper> igli: I think you are confused...
[21:24:53] <igli> *plunk* not any more
[21:24:57] <@FlameBook> 2.9999 will build the amarok-2 branch as soon as it's in a state that users might want to look at :P
[21:24:59] <genone> peper: just tested, foo-1a isn't a valid package name
[21:25:15] <@jokey> FlameBook: but when 2.0 comes out then, you won't notice it
[21:25:22] <peper> how did you test that?
[21:25:44] <@FlameBook> jokey, hm? if one is using live svn it shouldn't notice if a new version comes up, no?
[21:25:50] <genone> created a matching ebuild and called emerge with it as argument
[21:26:00] <@lu_zero> FlameBook another issue about usage
[21:26:08] <@lu_zero> something not covered by this glep
[21:26:11] <peper> well, portage accepts '*' as a pkgname, is it valid then?
[21:26:33] <genone> peper: huh?
[21:26:46] FlameBook just can't find any good reason at the moment for switching from -9999/.9999 to something different
[21:27:25] <peper> 9999 is a dirty hack, for one
[21:27:34] <genone> FlameBook: there are some _potential_ benefits outside ordering, like implicit masking
[21:27:43] rbrown [n=rbrown@!hgentoo/developer/paludis.rbrown] has joined !c#gentoo-council
[21:27:45] <genone> or grouping
[21:28:06] <@jokey> plus having scm functions available from pkg manager
[21:28:14] <@jokey> so the eclass hacks can disappear
[21:28:27] <@lu_zero> jokey eclass hacks got just moved
[21:28:29] <@lu_zero> at best
[21:28:34] <@vapier> genone: your opinion on -scm vs _scm ?
[21:28:55] Pesa [n=Pesa@!halpha.tat.physik.uni-tuebingen.de] has joined !c#gentoo-council
[21:29:39] <@FlameBook> genone, I find explicit masking better, actually
[21:29:45] <genone> vapier: if it's used for more than ordering (likely), -scm seems better to me
[21:30:56] <genone> FlameBook: everyone has his preferences ;)
[21:31:29] <@FlameBook> jokey, so you'd have to have a package manager to support all kind of scm? cvs, svn, bzr, git, hg, darcs?
[21:31:30] <@lu_zero> I find implicit masking wrong
[21:31:47] <@lu_zero> you forgot monotone and perforce
[21:31:53] <@FlameBook> what about dependencies? would the ebuild have to depend on the correct client package?
[21:31:55] <@vapier> monotone is irrelevant
[21:32:03] <@lu_zero> vapier pidgin
[21:32:06] <genone> lu_zero: was just an idea what could be done with a special tag
[21:32:09] <@lu_zero> sadly
[21:32:18] <@jokey> FlameBook: yep, given that including layman is something feasible, it would be needed eitherway, you can avoid code duplication
[21:32:22] <@vapier> still irrelevant, mt is terrible
[21:32:34] <@FlameBook> because if the ebuild have to do that by hand... then it would be quite a mess imho
[21:32:35] <@lu_zero> vapier I know
[21:32:38] hydrogen [n=hydrogen@!hc-75-68-137-232.hsd1.nh.comcast.net] has joined !c#gentoo-council
[21:32:49] <@FlameBook> having part of the code laying on the package manager side and partly on the ebuild/eclasses
[21:33:08] <@vapier> can we envision any other possible uses ?  extending the version syntax isnt trivial, so doing it one off for scm's when it isnt usable by anything else ...
[21:34:08] <@jokey> I don't see something else than scm atm
[21:34:14] <igli> which these benefits are not available with existing -cvs[0-9]* ?
[21:34:17] <igli> of^
[21:34:34] <@Betelgeuse> periodic reinstall but that could probably be done with 9999 too
[21:35:06] <igli> ty
[21:35:27] <@vapier> except for the projects that actually use 9999 in their version ;)
[21:35:45] <@Betelgeuse> vapier: yeah
[21:35:48] <@FlameBook> Betelgeuse, as far as I can understand it, if you have package set you can easily take care of periodic reinstall without having to add extra support to the package manager
[21:35:59] <@jokey> well if we agree on using that version(part) for live ebuilds, even that can be done
[21:36:17] <+musikc> fwiw, this proxy's stance on the topic is neutral
[21:36:20] p-y [n=p-y@!hgentoo/developer/p-y] has joined !c#gentoo-council
[21:36:46] <genone> FlameBook: the nice thing would be that we could create a dyamic package set containing all -scm installs, rather than each user having to maintain a static list
[21:37:07] <@FlameBook> genone, and that can't be achieved in any other way?
[21:37:42] <peper> what's the scm version of pkg which currently has version '20060621' in your 999 syntax?
[21:37:43] <@FlameBook> what about a possible AUTO_PACKAGE_SETS variable in ebuilds? (so one could also have a "xorg-drivers" dynamic package set, or a "gstreamer-plugins" package set, ...)
[21:37:45] <genone> FlameBook: well, we'd somehow have to identify such installs, the version tag is an easy and reliable way, but not the only one
[21:38:40] <genone> well, package sets as implemented in portage are extremely flexible, just need the data
[21:38:47] <@lu_zero> <peper> what's the scm version of pkg which currently has version '20060621'
[21:38:47] <@lu_zero>           in your 999 syntax?
[21:38:59] <@lu_zero> what do you mean?
[21:39:03] <@vapier> FlameBook: pretty much everything could be done if we codified the meaning of "9999", but arbitrarily reserving a number is wrong and can lead to false positives
[21:39:09] <peper> I mean that 9999 is a hack
[21:39:14] <peper> which need to die
[21:39:16] <@vapier> sticking scm in there conversely leads to no false positives
[21:39:17] <@FlameBook> 99999999 probably, looks nasty, but works
[21:39:42] <@Betelgeuse> vapier: yeah
[21:39:43] <@FlameBook> peper, might be an hack, but I don't see any good reason to change the versioning spec just to kill off that hack
[21:39:43] <peper> so you match any number of nines as scm?
[21:39:54] <peper> or just between 4 and 8?
[21:40:14] windzor [n=windzor@!h84.238.69.216] has joined !c#gentoo-council
[21:40:20] <@FlameBook> vapier, I meant declaring inside the ebuild that the package has to be added to the scm dynamic set
[21:40:42] <@FlameBook> peper, I don't see any reason _why_ there should be a way to identify the scm packages from an automatic perspective at the moment
[21:41:01] <@FlameBook> ordering, I find 9999 still working decently, automatic package sets, there are other solutions
[21:41:25] <@FlameBook> as for different scm software, it would be _quite_ a mess to support every and all scm systems from a package manager..
[21:41:28] <@lu_zero> I still don't see why live ebuilds should be expanded since it has such limited usage
[21:41:36] <@lu_zero> and the usage should remain as is
[21:41:36] Zephyrus [n=emanuele@!h81-174-11-81.static.ngi.it] has joined !c#gentoo-council
[21:42:48] jakub notes that -scm is much more likely to match something existant than -9999 and moves on...
[21:43:26] <peper> FlameBook: support every scm system? what?
[21:43:33] DrEeevil [i=dreeevil@!hgentoo/user/bonsaikitten] has joined !c#gentoo-council
[21:43:42] <jakub> IOW, foo-scm is $PN-$PV or $PN?
[21:43:49] <peper> there are eclasses for that
[21:43:52] <@FlameBook> maybe give a complete list of all the things you can have implemented by transitioning to -scm, indicating which ones can't be achieved in any other way.. then I might find something that makes me think that changing the versioning spec is worth the play
[21:44:00] <@FlameBook> peper, so okay not even eclasses cease to exists, as jokey hoped
[21:44:23] <@FlameBook> which comes back to my previous point: what can -scm do that we can't do already or in a different way that does not require changing the version spec?
[21:44:43] <peper> why are you so concerned about changing the version spec?
[21:44:50] <ferdy> false positives and not looking like a hack
[21:44:57] <TFKyle> jakub: think $PN-$PV is the intent
[21:44:58] <peper> we can clean up the mess
[21:44:59] <@FlameBook> ferdy, false positive doing what?
[21:45:04] <@FlameBook> which mess?
[21:45:04] <ferdy> 999999999
[21:45:16] <@FlameBook> ferdy, that's a false positive of what?
[21:45:42] <@vapier> peper: because it breaks everything, takes a while to adjust, and is not reversible
[21:45:49] <jakub> TFKyle: and, how are you going to ensure that? (well sorry for the noise here)
[21:45:54] <ferdy> fine, avoid POTENTIAL false positives
[21:46:05] <@vapier> changing the version spec is not trivial and should never be taken lightly
[21:46:07] <@FlameBook> ferdy, potential false positive doing _what_, that's what I'm asking for a while now
[21:46:30] <@lu_zero> avoid non existent, unlikely false positive, that could lead to unmentioned results
[21:46:31] <ferdy> making the package manager know it is dealing with a 'live' package
[21:46:39] <@lu_zero> ferdy undefined
[21:46:41] <@FlameBook> as vapier said, it's not something to take lightly, so if it's just for the sake to look "nicer", I wouldn't like that
[21:46:49] <ferdy> lu_zero: what's undefined?
[21:46:55] beandog [n=steve@!hgentoo/developer/beandog] has quit IRC: Excess Flood
[21:46:55] <@FlameBook> ferdy, and why should the package know that?
[21:47:00] <@lu_zero> what is the suggested behaviour
[21:47:05] <@FlameBook> the best thing that came up till now is genone's dynamic package set
[21:47:19] <peper> actually, it's pretty easy together with GLEP 55
[21:47:21] <ferdy> FlameBook: to allow other stuff like 'only build if there are changes in the underlying repo'
[21:47:22] <@FlameBook> which as I said can be implemented in a different way, and become an even more interesting idea per-se
[21:47:42] <@lu_zero> ferdy how you plan to implement that?
[21:47:44] <@FlameBook> ferdy, how can the package manager know about changes in underlying repository if the fetching is done by an eclass?
[21:47:51] <jakub> ferdy: you can detect repo changes via SCM tools... not via p.manager
[21:47:53] lukass [n=lukas@!h153.29.227.87.static.kba.siw.siwnet.net] has joined !c#gentoo-council
[21:47:57] beandog [n=steve@!hgentoo/developer/beandog] has joined !c#gentoo-council
[21:48:00] <@FlameBook> should it tar everything up and run an md5?
[21:48:15] <ferdy> no, you can ask eclasses to comply to some 'protocol' like "return blah from function bleh if there are no changes"
[21:48:26] <ferdy> that'd be the first hack that comes to mind
[21:48:26] <@lu_zero> ferdy the glep fails to deliver those details
[21:48:27] <eroyf> haha.
[21:48:34] <@FlameBook> what lu_zero just said
[21:48:41] <@FlameBook> ferdy, oh so we exchange an hack for an hack?
[21:48:45] <@lu_zero> and you stressed already that the main point is avoid hacks
[21:48:57] <ferdy> who said we should implement that hack ?
[21:49:12] <@lu_zero> ferdy what's written in the glep-54?
[21:49:14] <ferdy> and no, the GLEP shouldn't address this kind of stuff
[21:49:27] <@FlameBook> okay so the idea of just rebuilding stuff if repository has changed can't be implemented
[21:49:34] jakub finds using $scm native tool a _lot_ more reliable for detecting when something should be re-compiled than some -scm or whatnot suffix
[21:49:46] <@FlameBook> we're back to the only interesting thing being genone's dynamic package sets
[21:50:13] <@lu_zero> that can be implemented in quite a range of different ways
[21:50:38] <@FlameBook> lu_zero, I would like having that with a variable inside the ebuild
[21:50:49] <@FlameBook> so that we could have dynamic sets for plugin packages
[21:50:53] jensp [n=jens@!hunaffiliated/jensp] has joined !c#gentoo-council
[21:51:05] <@jokey> but even with dynamic sets, portage needs to have a safe skip package option then
[21:51:08] <@FlameBook> if we still had xmms in the tree, it would be nice to have a dynamic "xmms-plugins" package set )
[21:51:09] <@FlameBook> :)
[21:51:14] <@jokey> if there are no changes, go on
[21:51:36] <@FlameBook> jokey, which can't be implemented with the scm fetching implemented in eclass
[21:51:45] genone [n=genone@!hgentoo/developer/genone] has quit IRC: Read error: 104 (Connection reset by peer)
[21:51:46] <@lu_zero> still all those discussions are missing my original question
[21:51:48] <@FlameBook> and again brings us up to something different from what peper proposed till now
[21:52:04] rangerpb [n=baude@!hgentoo/developer/rangerpb] has joined !c#gentoo-council
[21:52:07] <@lu_zero> is it really worth the required effort?
[21:52:08] <ferdy> FlameBook: it certainly can, see functions can 'return' values to the PM
[21:52:12] genone [n=genone@!hgentoo/developer/genone] has joined !c#gentoo-council
[21:52:19] <@FlameBook> ferdy, you said it was an hack though
[21:52:36] <ferdy> no, I didn't
[21:53:01] <@FlameBook> and it would mean accepting a change to versioning specs on the basis that it could be possible implementing a feature in the package manager which hasn't been specified at all up to now..
[21:53:12] <@FlameBook> I'd like to see that (maybe make it a different glep) before going on with accepting this glep as it is
[21:53:47] <ferdy> it would mean accepting a change that would make the package manager know that a certain ebuild is a live ebuild
[21:54:09] <@FlameBook> so it would be fine if we accepted a change that makes the package manager know that a certain ebuild is an xmms plugin, too?
[21:54:16] <@FlameBook> at the moment I find the same usefulness between the two
[21:54:22] <@jokey> let's abstract it a bit, it would mean there are special options the package manager can provide
[21:54:24] <@lu_zero> next to 0?
[21:54:25] <@FlameBook> as nothing specifies what the package manager has to do differently for an scm ebuild
[21:54:44] <ferdy> heh, trying to make those things look similar is like pretending the people here are idiots
[21:54:58] ulm [n=ulm@!hgentoo/developer/ulm] has joined !c#gentoo-council
[21:54:59] <@jokey> brings us back to the original question anme asked.. "do we want this"? or maybe even do we need it?
[21:54:59] <@lu_zero> they aren't?
[21:55:20] <@FlameBook> and without knowing what the package manager can do differently for a scm ebuild, I find that the current proposal would mean accepting a change that has no practical value
[21:55:48] <jakub> ferdy: on that note... mythtv-* ebuilds... are those 'live' or not?
[21:55:48] <@FlameBook> jokey, as it stands, no I don't, I'd be happy to think again about this if we can get more information on why should we need this
[21:55:50] <genone> maybe the discussions is a bit too limited by the "scm" part, could be extended to allow tags in general
[21:56:13] <@FlameBook> genone, couldn't the tag be expressed by variables inside the ebuild?
[21:56:19] <ferdy> jakub: don't know a tad about those... do I have to look at them or is it a rethoric question?
[21:56:29] gentoofan23 [n=gentoofa@!hgentoo/contributor/gentoofan23] has joined !c#gentoo-council
[21:56:33] <@FlameBook> [without breaking versioning spec]
[21:56:34] <genone> FlameBook: yes, but those are quite a bit harder to access
[21:56:35] <jakub> ferdy: fetches a fixed rev from a repo
[21:56:41] <ferdy> jakub: no
[21:57:10] <@FlameBook> genone, but quite a bit simpler to implement, I guess?
[21:57:11] <@jokey> FlameBook: genone +1 here, having to acces the data is not helpful if you want to provide special functions like weekly or whatever rebuild
[21:57:25] <peper> breakage of verioning spec is not a problem if we do GLEP 55
[21:57:38] <@lu_zero> jokey that can be done with cron and custom sets
[21:57:54] <@FlameBook> jokey, if you create dynamic sets based on tags, you don't need to access the ebuilds by hand, no?
[21:57:58] <@lu_zero> peper that hasn't been discussed yet
[21:58:03] <peper> just saying
[21:58:08] <genone> FlameBook: depends
[21:58:14] <@FlameBook> just need to keep the dynamic sets' definitions consistent with the installed packages
[21:58:36] <ferdy> those dynamics sets being something that hasn't been specified, or has it?
[21:58:39] genone [n=genone@!hgentoo/developer/genone] has quit IRC: Read error: 104 (Connection reset by peer)
[21:59:00] ferringb [n=ferringb@!hc-24-4-204-103.hsd1.ca.comcast.net] has joined !c#gentoo-council
[21:59:14] genone [n=genone@!hgentoo/developer/genone] has joined !c#gentoo-council
[21:59:18] <@lu_zero> wb genone
[21:59:33] <@FlameBook> it hasn't, which brings us again to the point that whatever we're going to accept, it should at least provide some useful use cases
[21:59:48] genone [n=genone@!hgentoo/developer/genone] has quit IRC: Remote closed the connection
[22:00:20] <peper> emerge --reinstall-scm
[22:00:30] <ferdy> heh... so "it can be done with dynamic sets" is pure science fiction
[22:00:48] <jakub> peper: well, _if_ we agree on some convention, the same can be done with -9999
[22:00:49] <@FlameBook> ferdy, it's no more and no less than what you were saying up to now
[22:00:59] <@FlameBook> with the difference that I don't have to convince you to accept dynamic sets
[22:01:11] genone [n=genone@!hgentoo/developer/genone] has joined !c#gentoo-council
[22:01:21] <@FlameBook> while, considering I'm not convinced by -scm at the moment, you're the ones that should be convincing me to accept those
[22:01:23] <ferdy> with the difference that the -scm stuff IS working in a different package manager, so it is not science fiction
[22:01:43] <@FlameBook> [or just decide that you don't want to convince me, and then stop the discussion right here, with my vote being "no"]
[22:02:13] <@lu_zero> ferdy -9999 is working fine with about 2 or 3
[22:02:15] <@FlameBook> ferdy, is working to do what? I asked that already, if you don't intend to answer that, then I suppose I can simply state my vote here to be "no" and move over
[22:02:17] <jakub> ferdy: well, passing qlist -CIv 9999 output works exactly the same w/ portage
[22:02:18] <@lu_zero> so it's pointless
[22:02:50] <peper> jakub: why not 99999?
[22:03:06] <ferdy> FlameBook: periodic reinstalling done right, I thought it had been said already
[22:03:31] <@jokey> peper: as stated in the glep, 9999 has become common sense
[22:03:31] <@lu_zero> ferdy cron and fixed sets works as should already
[22:03:35] <ferdy> also... you feel yourself very important... I'm not trying to convince *YOU*, I'm trying to get my facts straight, no need to convince anyone...
[22:03:44] <ferdy> lu_zero: no it doesnt, read up why
[22:04:11] <peper> jokey: there are packages with versions like YYYYMMDD, so rather a common hack
[22:04:12] <ferdy> that doesn't handle a package that has several different scm 'versions' as git does
[22:04:20] <jakub> peper: as said... just agree on some convention (plus, 9999 doesn't require extensive changes everywhere as already noted)
[22:04:32] <@vapier> would i venture to say this needs to move back to the mailing list
[22:04:52] <@vapier> well, i did venture
[22:04:56] <@vapier> would i be correct in ...
[22:05:03] <ferdy> jakub: doesn't work, read what I said
[22:05:21] <jakub> vapier++
[22:05:26] <peper> jakub: like 15 nines to be sure?
[22:05:44] <@jokey> vapier: indeed, as there seems to be too many unresolved ideas atm and undiscussed other options
[22:05:53] <jakub> peper: 9999 doesn't conflict w/ anything I have installed; -scm is much more likely to conflict
[22:06:05] <@vapier> so, peper, repost the glep, and anyone with issues, post them to the list for responses
[22:06:14] <@vapier> if you dont post them, then you cant bring them to the table next time :p
[22:06:15] <ferdy> jakub: again, the 9999 doesn't work, read up why... it is a legit case
[22:06:25] <peper> vapier: alright
[22:06:26] <+musikc> vapier: agreed. lots of discussion on this one still.
[22:06:28] <igli> with existing sol'n, the pm *has* to know it's cvs to order it correctly. iow this is already available as data
[22:06:33] gentoofan23 [n=gentoofa@!hgentoo/contributor/gentoofan23] has quit IRC: Client Quit
[22:06:43] <@lu_zero> ferdy quote yourself I couldn't find the line in /lastlog
[22:06:45] <jakub> ferdy: it worked for me for ages :) well, doesn't belong here really
[22:06:52] <ferringb> peper: expanding the glep to contain the arg against the existing -cvs version would be useful also, please.
[22:07:06] jensp [n=jens@!hunaffiliated/jensp] has left !c#gentoo-council
[22:07:13] <ferdy> jakub: doesn't in the case of git where you need at least two different 'scm' versions
[22:07:17] <peper> ferringb: does it really need more args than nobody using it?
[22:07:27] <@lu_zero> ferdy 2?
[22:07:33] <ferdy> yes, two
[22:07:33] <@lu_zero> as in?
[22:07:41] <genone> peper: well, how many people actually know about it?
[22:07:55] <genone> (but I agree it sucks)
[22:07:56] <ferringb> peper: yes, imo, since the support ought to still be there (can't say for paludis, but pkgcore and portage still have it last I looked)
[22:08:05] <ferdy> lu_zero: also, your dynamic set thing doesn't work because those haven't been defined, so, as I said, it is pure science fiction
[22:08:22] <@lu_zero> ferdy never said dynamic
[22:08:26] <@lu_zero> CURRENT sets
[22:08:31] <ferringb> peper: either way, look at it from the angle of documenting the failing of it if you like- expanding the arg for why it must be finally killed off, and -scm replace it would help ;)
[22:08:39] <@lu_zero> as available in portage and pkgcore
[22:09:06] <ferdy> lu_zero: 2 as in 'master' and 'next' and every master and next from every release cycle
[22:09:21] <ferdy> also, vapier said to repost, so this should move to another topic
[22:09:41] <@jokey> indeed, pushing this back to -dev for discussion
[22:09:49] <@lu_zero> ferdy I still don't understand what you mean
[22:09:56] <@lu_zero> anyway next item
[22:10:04] <@FlameBook> lu_zero, he probably refers to multiple branching
[22:10:15] <@lu_zero> that isn't 2
[22:10:20] <jakub> ferdy: once again... -scm or -9999 is _not_ a reliable indication whether you need to recompile something or not..
[22:10:21] <@FlameBook> [which is what I said before about amarok's 1.4.9999 vs 2.9999]
[22:10:21] <@lu_zero> is $any
[22:10:34] <peper> vapier: do you except me to do any changes or just repost as is?
[22:10:35] <ferdy> jokey: did I say otherwise ?
[22:10:42] <peper> *expect
[22:11:07] <ferdy> lu_zero: I said GIT needs at least 2... really, it is much better if you read my sentences instead of skimming over them
[22:11:19] <@jokey> next topic on agenda would be GLEP 55, can we move on to that?
[22:11:34] NeddySeagoon [n=NeddySea@!hgentoo/developer/NeddySeagoon] has joined !c#gentoo-council
[22:11:36] <ferdy> sorry not jokey, jakub.
[22:11:47] <+musikc> jokey, seems like we should
[22:12:04] <@jokey> or does anyone want to not push GLEP54 back to dev ML?
[22:12:13] <peper> do you expect me to do any changes or just repost as is?
[22:12:26] <@lu_zero> peper add a section about pm behaviour
[22:12:41] <@lu_zero> and anything else that states its usefulness
[22:13:14] <peper> ok, move on to 55, I want to see what you think about it first
[22:13:31] <TFKyle> jakub: that along with update checking would be, though interface-wise you'd probably have to specify something extra to the pm to check scm repos due to hitting the network
[22:14:25] <@jokey> okay, next topic then... GLEP 55 "This GLEP proposes usage of EAPI-suffixed file extensions for ebuilds (for example, foo-1.2.3.ebuild-1)."
[22:14:50] <armin76> poor jokey :)
[22:15:09] <genone> as said on the ML, I'm definitely against it silently expanding the scope of EAPI, also a note aboute compability would be nice IMHO. Other than that I don't really like it, but it's probably the best option if we want to avoid sourcing the ebuild to access EAPI
[22:15:31] <@lu_zero> why sourcing is a problem exactly?
[22:16:03] <peper> genone: hmm, where is scope of EAPI defined that you are talking about expanding?
[22:16:05] <ferringb> genone: unless I'm on crack, it still explicitly requires it due to the post source EAPI angle
[22:16:14] <ferringb> peper: can you confirm that?
[22:16:33] musikc thinks there should be some visible agreement among package manager developers (portage, pkgcore, and paludis) before we go further or even support it
[22:16:58] <peper> for backwards compatibility, yes. but pm doesn't source ebuilds with usupported pre-source eapi
[22:16:59] <@lu_zero> "Let's call the EAPI included in the ebuild filename the pre-source EAPI, and the EAPI set inside the ebuild the post-source EAPI. Given these two, the final EAPI used by the ebuild can be established by following these steps:"
[22:17:08] <@amne> musikc: good point
[22:17:16] <genone> peper: you very well know that it's not defined formally
[22:17:33] <ferringb> peper: one failing there is that it can miss ebuilds that (post-source) it's able to handle, thus inadvertantly masking stuff
[22:18:01] <ferdy> ferringb: hrm.. how so ?
[22:18:03] <ferringb> peper: that scenario, imo, is enough to raise the question of "why do post source then?"- pardon it wasn't on the ml, but I've been looking for an answer to that
[22:18:21] <peper> ferringb: for backwards compatibilty
[22:18:27] <peper> read the Application part of the glep
[22:18:48] <peper> specification is how pm is supposed to do it to get it right
[22:19:01] <ferringb> ferdy: portage-2.3.ebuild-3 w/ a pm that supports EAPI=(1,2), the portage ebuild has a post-source EAPI=2 w/in it, thus it *is* supported by the pm, but the pre-source serves as a mask
[22:19:26] <@lu_zero> genone, ferringb and peper : why sourcing is a problem?
[22:19:30] <peper> ferringb: and who would make such an ebuild?
[22:19:34] <ferringb> peper: pkg-4.ebuild-2, EAPI=1 is a given example in the glep of this, just assume the manager supports EAPI=1 only; thus it *would* be able to use .ebuild-2, just would miss it
[22:19:38] <@lu_zero> I'd like to have an answer about that first...
[22:19:44] <ferdy> ferringb: I seem to recall the GLEP explicitly prohibiting that
[22:19:52] <ferdy> lu_zero: have you read the discussion ?
[22:20:07] <peper> lu_zero: read Problem section
[22:20:12] <@lu_zero> done
[22:20:12] <ferdy> in the mailing list, I mean. I think it has been covered...
[22:20:14] <ferringb> ferdy: will recheck the glep to see if I was wrong, but the potential (even if it's stupid) was bugging me a fair bit.
[22:20:16] <@lu_zero> nothing said about it
[22:20:29] <@lu_zero> ferdy done, nobody explained that
[22:20:31] <genone> lu_zero: the (potential) problem is that the EAPI might affect how things are sourced, and we can't trap the setting of a variable
[22:20:48] <peper> ferringb: again, post-sourcing is just for backwards compat. devs are not supposed to use both
[22:20:51] <@vapier> considering EAPI is stilled allowed and required to be respected properly in the ebuild, i dont see how this solves anything
[22:21:04] <@vapier> you're still required to handle EAPI in the ebuild if no suffix, so why bother with suffix
[22:21:09] <@jokey> genone: well if per definition the first line sets EAPI, then it shouldn't be an issue in any case, right?
[22:21:26] <ferringb> genone: can trap the setting via adding an eapi function, which can be deployed via a bashrc hack as compatibility w/ managers growing the appropriate func however
[22:21:42] <@vapier> and if the EAPI placement is simply "must come first", then the sourcing problem isnt a big deal
[22:22:16] <genone> ferringb: yes, and I've mentioned that the motivation section is something that needs to be worked on as it currently has no real use cases short of glep54
[22:22:46] <ferringb> genone: 'k; that (admittedly) is something I should've done initially instead of the var approach, although at least the transition to the func wouldn't be that painful
[22:24:12] <ferringb> peper: aside from the addition of -scm to version component, can you add doc out any other complaints beyond what's there for the var approach?
[22:24:34] <@lu_zero> genone putting the eapi tag in a comment like vim/emacs modelines won't give the same effect w/out such change?
[22:24:41] <peper> ferringb: isn't it handled in the other ideas secion?
[22:25:00] <ferringb> (I exempt the -scm one, since that is a general repo versioning issue, same scenario can play out with manifest/digest changes, thus should be solved that way imo)
[22:25:08] <peper> it's neither backwards nor forwards compatible
[22:25:13] lukass [n=lukas@!h153.29.227.87.static.kba.siw.siwnet.net] has quit IRC: "Leaving"
[22:25:21] kingtaco|laptop [n=kingtaco@!hgentoo/developer/kingtaco] has joined !c#gentoo-council
[22:25:48] <ferringb> peper: not really imo, I'm looking for specific complaints leveled towards EAPI beyond "functions have to check it in the global scope to see if they support it"- that one is addressable w/ a few tweaks to existing eapi mechanism
[22:26:53] beandog [n=steve@!hgentoo/developer/beandog] has quit IRC: Excess Flood
[22:27:20] beandog [n=steve@!hgentoo/developer/beandog] has joined !c#gentoo-council
[22:27:42] <peper> ferringb: and I am looking for technical objections to that GLEP, it solves all the problems nicely, in a backwards and forwards compatible way
[22:27:52] Cardoe [n=cardoe@!hgentoo/developer/Cardoe] has joined !c#gentoo-council
[22:27:54] <genone> lu_zero: well, lots of things are possible, I think the ML thread contains some drawbacks for the other solutions but I'd have to check (can't do that now)
[22:28:31] <jmbsvicetto> genone: One question I didn't see a clear answer about was the one about using xml files. Is it a no-no to have eapi set on metadata.xml?
[22:28:39] <ferringb> peper: the scenario of post-source being supported, but pre-source serving as a mask can play out via an eclass setting eapi however btw, so that one still is a valid scenario (it's considered a QA bug under the glep, 'cept I'm willing to bet it'll pop up in overlays)
[22:28:42] <Caster> I liked the idea of eapi string not going at the very end, keeping the suffix constant
[22:29:07] <@Betelgeuse> The sub directories approach would work for that.
[22:29:23] <@Betelgeuse> The performance issue shouldn't really matter as users are using the metadata cache any wya.
[22:29:35] <genone> jmbsvicetto: well, metadata.xml is ... complicated if you only want to target specific versions (and currently portage doesn't use metadata.xml in any way)
[22:29:37] <peper> ferringb: the idea of the GLEP is to get rid of post-source eapi. the specification is for the package managers to get the backwards compatibility right
[22:29:47] <@Betelgeuse> Also would need factual data if there is anything significant any way.
[22:29:52] <ferringb> peper: technical objection to the glep basically comes down to "why punt whats there, when whats there works and can be tweaked to keep working"- I don't claim EAPI will work if the ebuild format shifts away from bash, but EAPI was intended for bash ebuilds only, expected newer formats to do versioning their own way
[22:29:53] <peper> devs are supposed to use pre-source only
[22:30:17] <@FlameBook> Betelgeuse, I would like to hear from infra about that as iirc CVS isn't nice with loads of directories
[22:30:31] <@Betelgeuse> FlameBook: true
[22:30:37] <peper> Betelgeuse: you first look for ebuild, then look at the cache
[22:31:18] <@Betelgeuse> peper: to see if the cache is valid?
[22:31:50] <ferringb> peper: additional thing the glep should doc, exactly what the manager does when it encounters a post-source EAPI it doesn't support cache wise (including regeneration of that entry if the manager sees that entry, and now supports that EAPI)
[22:31:53] <peper> generally, you query cache for stuff, not traverse it
[22:32:02] <genone> the subdir approach is nasty besides the performance issues
[22:32:15] <ferringb> genone: agreed by all, I suspect
[22:32:35] hncaldwell [n=hncaldwe@!hgrey.iitsystems.csupomona.edu] has joined !c#gentoo-council
[22:33:04] <Cardoe> this is all starting to sound like over-design
[22:33:11] <Cardoe> designing for a situation that will never happen
[22:33:15] <Cardoe> KISS
[22:33:52] <jakub> Cardoe++
[22:34:00] <@Betelgeuse> well this hsould be useful for changing how inherit behaves etc
[22:34:03] <peper> you are just not thinking enough
[22:34:05] Ken69267 [n=Ken69267@!hgentoo/contributor/ken69267] has joined !c#gentoo-council
[22:34:15] <peper> yep
[22:34:30] <genone> as I said: the specification section is ok, but the motivation section needs a huge workover
[22:34:38] <@lu_zero> Betelgeuse must it be changed?
[22:34:55] <@Betelgeuse> lu_zero:  it was just an example of what this enables
[22:35:07] <ferringb> peper: question for you; did you look at converting EAPI=N to eapi N, ie, forcing a func so the manager sourcing can bail at that point if unsupported; either way, I'd suggest expanding the glep to counter-arg that one since it's a solution to the inherit problem
[22:35:59] <peper> for one, it's not backwards compatible
[22:36:18] <@Betelgeuse> peper: well we would just have agree on profile.bashrc
[22:36:18] <ferringb> peper: via bashrc stuck into the repo, it is
[22:36:26] <ferringb> interim compatibility func basically
[22:36:47] <genone> ferringb: paludis doesn't use profile.bashrc according to ciaranm
[22:36:58] <@Betelgeuse> genone: yeah I think so too
[22:37:14] <@Betelgeuse> There is lots of Portage specific hacks in profile.bashrc atm
[22:37:14] <genone> not that I care ...
[22:37:23] <ferringb> without the func, the ebuild gets sourced fully, and the manager sees the unsupported EAPI at the end of sourcing, does the usual thing (probably with a few errors spat during it); with the func, the manager bails at the first imperative sign of an unsupported eapi, thus bypassing any visibile errors.
[22:37:25] <@Betelgeuse> but they could be put under some conditional
[22:37:33] <Caster> we don't need back compatibility for paludis at this point
[22:38:13] <ferringb> peper: so... imo, it's backwards compatible- sorry to spring it on you during this meeting rather then ML prior also ;)
[22:39:15] <peper> it doesn't allow to change the versioning spec and I see it useful
[22:39:26] <Caster> can newer portage easily ignore the eapi in bashrc then?
[22:39:52] <@lu_zero> peper versioning spec changes aren't being approved
[22:39:57] <@lu_zero> don't be circular
[22:40:03] <ferringb> peper: versioning spec is a repo level compatibility issue imo, although you could argue other wise; again, I'd try to get that one doc'd out also, cause I know genone (and myself in this case) both via it as not the ebuild formats versioning responsibility
[22:40:16] <ferringb> s:via it:view it:, pardon
[22:40:34] <genone> peper: question: is glep54 the main (only?) motivation for glep55 for you?
[22:40:50] <peper> no, it's a coincidence
[22:41:55] <@jokey> can you give some real world examples, where this pre-source information is needed then?
[22:43:10] <@jokey> as inherit-behavior-change is possible without it
[22:43:33] <@vapier> so is there a reason we cant just force EAPI as the first line in an ebuild ?
[22:43:38] <@vapier> is there some limitation i'm not aware of ?
[22:43:52] <peper> vapier: backwards compatibility for one
[22:43:53] <Philantrop> jokey: The PM will never have to read *any* content that might potentially cause it to die horribly because of EAPI issues. It sees a pre-source EAPI spec that it isn't compatible with and thus simply won't touch it and consequently avoid any potential problems easily.
[22:44:06] <@vapier> peper: not really
[22:44:17] <@vapier> and certainly *a ton less so* than changing the naming spec
[22:44:25] <@jokey> Philantrop: still I want a real world example that breaks the sourcing that horrible
[22:45:00] <@lu_zero> Philantrop having all non ebuilds in a package dir would break in a more spectacular way
[22:45:44] <Philantrop> jokey: We don't have it yet so that's a bit hard. :-) It's something that opens the door for easier development in the future and improved transitions from one EAPI version to the next.
[22:45:48] <@lu_zero> and I'm not sure about how manifests should be generated
[22:45:58] <ferringb> Philantrop: that is achievable via the tweak adding an eapi func also; what we're talking about here re: "die horribly" is moreso "fail the sourcing, noting the EAPI and spitting noise at the user" also :)
[22:46:50] <@vapier> Philantrop: claiming it'll happen in the future, just not now, isnt really an example
[22:46:54] <Philantrop> ferringb: I'm not sure I understand you. You refer to users being confused by the output?
[22:46:59] windzor [n=windzor@!h84.238.69.216] has quit IRC: Remote closed the connection
[22:47:03] <@vapier> it's also a good argument for delaying the change until needed for real
[22:47:17] <@vapier> instead of engineering for something that may not occur
[22:47:52] <@jokey> vapier: exactly my point :)
[22:48:03] <ferringb> Philantrop: no, what I'm saying is that a sane manager checks EAPI on the way out, as part of the metadata generation process.  if the EAPI is unsupported, and the new eapi added some global functions, *worst* you see is some screwed up metadata and errors spat to the users term on sourcing
[22:48:18] <ferringb> Philantrop: it doesn't kill the manager (or shouldn't, if the manager is implemented sanely imo), it just is slightly ugly
[22:48:38] <Philantrop> vapier, jokey: Why should we always operate *reactively*?
[22:48:45] <ferringb> Philantrop: introducing an eapi func (which can be transitioned to via profile.bashrc) eliminates the inherit arg, and eliminates the potential for bash complaints to be spat during sourcing
[22:49:13] <Cardoe> vapier: exactly what I meant by my previous comments
[22:49:13] <@jokey> Philantrop: because acting proactive without a real value (you can't even come up with a potential example) doesn't make sense
[22:49:17] beandog [n=steve@!hgentoo/developer/beandog] has quit IRC: "Leaving"
[22:49:35] <Cardoe> if we over-design and work on engineering something that MIGHT happen, but never happens
[22:50:04] <Cardoe> rather then engineering a logically extensible method (what EAPI itself provides), that can be in the future changed as things necessitate.
[22:50:09] <Philantrop> ferringb: I see what you mean now but I can't say much more than that what was said on the -dev ml already. And so I go back to lurking here.
[22:50:27] <@vapier> plus, this doesnt really address what started it all ... allowing eclasses to use a different EAPI from an ebuild
[22:50:31] p-y [n=p-y@!hgentoo/developer/p-y] has quit IRC: Read error: 110 (Connection timed out)
[22:50:45] <Cardoe> vapier: right. that was the whole point that spawned this whole thing.
[22:50:58] <genone> vapier: well, that's simply not possibly, no matter how you define EAPI
[22:51:00] <Cardoe> vapier: instead we've added about 12 steps of complexity and didn't even solve the original thing.
[22:51:07] <peper> eclasses can't define EAPI
[22:51:14] <@vapier> why not ?
[22:51:23] <@vapier> why cant we segment things logically
[22:51:39] <genone> vapier: which EAPI is effective: the calling env or the definition env?
[22:51:53] <@vapier> genone: segment things logically
[22:51:53] <ferringb> genone: could you rephrase the question please (didn't get the meaning there)
[22:52:02] <peper> vapier: what do you mean?
[22:52:08] <@vapier> eclasses are not affected by the ebuild at all
[22:52:18] <@FlameBook> considering we have two other points on today's list, do we want to take a decision on this, postpone it, or what?
[22:52:22] <@vapier> eclasses can use different EAPIs independently from the ebuild
[22:52:37] <ferringb> vapier: not true, imo
[22:52:49] <@vapier> might as well push it back to the list
[22:52:59] <ferringb> vapier: eapi is a definition of the env (vars, funcs), switching the env dependant on ebuild/eclass context isn't viable imo
[22:53:03] <genone> ferringb: see http://article.gmane.org/gmane.linux.gentoo.devel/53354
[22:53:21] <peper> I think you meant vapier
[22:53:23] <@vapier> ferringb: having one env force/imply restrictions on the other is bad
[22:53:51] <Cardoe> vapier: it also brings up the point that eclasses are abused and enibbles or elibs need to be available.
[22:53:55] <@vapier> it means all consumers of an eclass need to worry about the eclass which sort of defeats the purpose of the eclass -- not having to worry about its contents
[22:54:11] fmccor [n=fmccor@!hgentoo/developer/fmccor] has quit IRC: "Leaving"
[22:54:15] <genone> vapier: http://article.gmane.org/gmane.linux.gentoo.devel/53354 <- answer those questions please if you want different EAPIs
[22:54:37] <ferringb> vapier: agree with you in principle, disagree on implementing it however ;)
[22:54:51] <@vapier> i'm not trying to imply the implementation is trivial
[22:55:05] <genone> i's a conceptual problem
[22:55:08] <@vapier> regardless, back to the list and us on to the next item
[22:55:11] fmccor [n=fmccor@!hgentoo/developer/fmccor] has joined !c#gentoo-council
[22:55:50] <@jokey> with vapier here, should be postponed to next meeting
[22:56:00] <@vapier> no
[22:56:12] <@vapier> pushed to the list until resolved, and then back to the council
[22:56:24] <@FlameBook> so it's a "rejected in this state"?
[22:56:52] p-y [n=p-y@!hmas91-3-88-163-239-36.fbx.proxad.net] has joined !c#gentoo-council
[22:56:53] rangerpb [n=baude@!hgentoo/developer/rangerpb] has quit IRC: "Leaving"
[22:57:11] aballier [n=alexis@!hgentoo/developer/aballier] has joined !c#gentoo-council
[22:57:30] <@vapier> FlameBook: there was no voting involved, thus no rejection
[22:57:43] <+musikc> needs further discussion
[22:57:44] <@vapier> we were merely discussing the GLEPs, no request for voting
[22:58:22] <@dberkholz> fwiw, i'm back but catching up on backlog
[22:58:24] <@FlameBook> okay, let's go to "need further discussion" as musikc said then
[22:58:48] <@FlameBook> dberkholz, that is perfect as we're moving to CoC :)
[22:58:54] <+musikc> hehe
[22:58:55] <@jokey> timing++ ;)
[22:58:56] <peper> I am going to repost the GLEPs as is and hope you guys ask your questions there
[22:59:33] <Caster> peper: as is? so no argument for why eapi() function can't help?
[22:59:36] <@SpanKY> ive lost the agenda URI from my scrollback
[22:59:44] <@jokey> SpanKY: see topic
[22:59:44] <@FlameBook> SpanKY, http://dev.gentoo.org/~dberkholz/20080110_summary.txt
[22:59:55] <@vapier> well that'd be too obvious
[23:00:01] <@dberkholz> vapier: /topic
[23:00:03] <@jokey> FlameBook: I grabbed it from dberkholz and completed it
[23:00:15] <@FlameBook> jokey, ah I didn't even see it in the topic
[23:00:48] Zephyrus [n=emanuele@!h81-174-11-81.static.ngi.it] has quit IRC: Client Quit
[23:01:22] <peper> Caster: oh ok. I will add this one
[23:01:32] <@dberkholz> i'm caught up to the first hour, another hour of backlog to go
[23:01:43] <@lu_zero> ^^;
[23:02:22] <@jokey> so pushing back to -dev is agreed on ? then we can move over to CoC discussion
[23:03:04] <peper> jokey: the subjective part of the summary in GLEP 54 is wrong
[23:03:36] <ferringb> peper: if you want me to give the eapi() a read over (since I'll be commenting on it either way), email me and I'll try to get back to you w/in the day
[23:03:38] <@jokey> right, missing inherit breakage, adding that
[23:03:50] <@jokey> done
[23:03:58] <peper> as there is no way to distinguish between pkg_name and pkg_name-version on its own/, but it's not necessary anyway
[23:04:10] <peper> jokey: I meant GLEP 54
[23:04:33] <peper> the subjective part is just wrong, I thought it was established
[23:05:43] <@jokey> well as it will have a log attached either way, I'm removing that line altogether
[23:05:52] <@jokey> you're right, it's a bit subjective
[23:06:19] <peper> no, it's not true
[23:06:25] <peper> as there is no way to do it currently
[23:06:38] fmccor thought he knew how to run long meetings. :)
[23:07:00] <@jokey> anyway, pushed back to -dev ML
[23:07:07] <peper> right
[23:07:47] <@lu_zero> peper do what?
[23:07:58] <@jokey> so ladies and gentlemen, let's move over to CoC now
[23:08:03] <@lu_zero> ok
[23:08:24] <peper> lu_zero: tell whether a string is a pkg or pkg-ver
[23:08:42] FlameBook is probably going with "whatever donnie says" :P
[23:09:47] <@lu_zero> dberkholz are you ready?
[23:09:58] <@dberkholz> i'm at 20 minutes ago, so almost
[23:10:02] <genone> peper: it is possible, your example didn't work out, also see bug !c#174536
[23:10:05] <jeeves> genone: https://bugs.gentoo.org/174536 min, P2, All, degrenier@easyconnect.fr->pms-bugs@gentoo.org, NEW, pending, "Package names" spec not restrictive enough
[23:10:26] <@vapier> done people, moving on
[23:10:38] <@vapier> dont make us go +m on j00
[23:10:52] <@dberkholz> feel free to skip to slacker arches and come back to CoC in a bit
[23:11:07] genone just dislikes misinformation
[23:11:15] <@dberkholz> not really sure there's anything to discuss on the slacker point, though.
[23:11:24] <@vapier> how so ?
[23:11:35] <@vapier> or rather, we jumping to slacker first ?
[23:12:26] <@dberkholz> that's my suggestion, yeah.
[23:12:45] <@dberkholz> hopefully it will go faster, and then people uninterested in the CoC can leave
[23:12:52] <@FlameBook> kumba's mail was quite reasonable, so I don't think there's much to discuss, I suppose it could work out by just leaving the options of devs asking de-keywording on ebuild basis
[23:13:20] <@Betelgeuse> as long as there is someone to ask
[23:13:20] <@vapier> except that didnt really work out
[23:13:29] <@vapier> there was no response
[23:13:34] <jakub> FlameBook: is there someone going to respond to those mails? wasn't my experience so far....
[23:13:51] <jakub> even when remove keyword was explicitely and repeatedly requested
[23:14:08] <@vapier> i think what Richard posted is a pretty reasonable
[23:14:12] <@vapier> http://article.gmane.org/gmane.linux.gentoo.devel/54103
[23:14:13] <@FlameBook> jakub, well, kumba answered to gentoo-dev... I don't think we should _force_ it now
[23:14:41] <@vapier> perhaps extend the dates to give more leeway to arches, but there has to be a cut off point
[23:14:44] <jakub> FlameBook: I'm totally fine w/ that if you are going to create a working way to do it :)
[23:14:52] <@vapier> otherwise maintainers who get tired of waiting will eventually do it
[23:14:55] <@vapier> and then the arches get pissed
[23:15:00] <@vapier> yell and point at policy
[23:15:05] <@vapier> and it's the maintainer getting screwed
[23:15:09] <jakub> nod
[23:15:09] <@vapier> when in reality that isnt right
[23:15:36] <ferdy> I'd like you to consider what I posted to that same thread: http://mid.gmane.org/20080109121309.GA14454@ferdyx.org
[23:15:57] <jakub> vapier: maybe more flexible, but still needs some hard deadlines so that it doesn't become useless
[23:16:00] <@vapier> the only responses i saw from you were "no"
[23:16:57] <jakub> ferdy: wrt the maintainer question you've posted there... it is different, you can retire a maitainer, noone ever retired an arch yet
[23:17:05] <@jokey> what about we do some "% packages stabled, % packages behind requests for time X -> transition to ~arch"
[23:17:19] <ferdy> jakub: retiring a maintainer doesn't solve the issue...
[23:17:34] <jakub> ferdy: sure it doesn't, but it
[23:17:43] <jakub> 's still lot better than ignoring inactive people
[23:17:43] <@FlameBook> vapier, well, I actually like Richard's proposal
[23:18:08] <@vapier> ferdy: with arches, you're forcing maintainers to sit on things indefinitely with no reaction, which quickly chains to large !c# of affected packages
[23:18:09] <jakub> ferdy: someone can take over the package once the slacking maintainer has retired...
[23:18:16] <@vapier> with a maintainer slacking, the issue is isolated to one package
[23:18:31] <jakub> and what vapier said, yeah
[23:18:31] <@vapier> you can trivially cull a package, you cant trivially cull an arch
[23:18:34] kingtaco|laptop [n=kingtaco@!hgentoo/developer/kingtaco] has quit IRC: Read error: 110 (Connection timed out)
[23:18:39] <jakub> ain't the same situation
[23:18:50] <@vapier> and you can transition arches to a state that keeps maintainers happy
[23:19:14] <ferdy> vapier: in that particular bug I posted. I would suffer from the same 'maintenance burden'.... should I, for instance, add blockers
[23:19:18] <@amne> just a quick thought before this gets more into detail, do we want to address just this one situation or come up with a general policy for all possible times an issue like this comes up?
[23:19:26] <jakub> seriously, why's mips so much objecting to becoming ~arch/indev? would shut up the maintainers mostly
[23:19:43] <@vapier> no one who matters is objecting
[23:19:43] <ferdy> please note that I personally deny that maintenance burden existing, but I think it is the very same situation
[23:19:57] <@dberkholz> jakub: no active mips developer (kumba or redhatter) has objected to that
[23:20:00] <@vapier> take that thread, cull the irrelevant, and you have a few e-mails to read
[23:20:07] <@vapier> ferdy: how would you suffer ?
[23:20:12] <@vapier> i honestly dont see it
[23:20:18] <@vapier> please 2 elaborate
[23:20:21] <jakub> dberkholz: well sorry then, that's what I've always heard from the folks until now :)
[23:20:36] p-y [n=p-y@!hmas91-3-88-163-239-36.fbx.proxad.net] has quit IRC: Read error: 110 (Connection timed out)
[23:20:39] <ferdy> I don't see it either.... but leaving versions in the tree forever is said to cause maintenance burden
[23:20:54] kingtaco|laptop [n=kingtaco@!hgentoo/developer/kingtaco] has joined !c#gentoo-council
[23:20:55] <ferdy> which is one of the arguments in favour of "killing the mips team altogether!!!!one"
[23:20:56] <@vapier> ferdy: i'm talking about why you think 181275 is relevant
[23:20:59] <Cardoe> jakub: just ignore non-Gentoo developers e-mails and read official Gentoo dev e-mails and you'll see that the Gentoo devs agree with it
[23:21:16] <jakub> ferdy: sure it is... repoman commit breaks when you want to punt obsolete broken junk... etc. etc.
[23:21:16] <@vapier> ferdy: there will be no killing of mips
[23:21:42] <@vapier> there will most likely be ~arching of mips which is very different from killing
[23:21:43] <ferdy> vapier: I have to leave older versions around until that issue is solved
[23:22:09] <@vapier> ferdy: you need to leave old versions of git in the tree until uClibc is fixed ?
[23:22:14] <@vapier> i dont think so, remove the old versions
[23:22:28] <jakub> ferdy: you are wasting time on investigating which broken cruft can't be removed just b/c noone responded on a bug for years... now imagine major package redesigns, becomes a huge PIT
[23:22:28] beandog [n=steve@!hgentoo/developer/beandog] has joined !c#gentoo-council
[23:22:38] <@vapier> jakub: please shush
[23:22:48] <jakub> sure ;)
[23:23:33] <ferdy> vapier: imagine it'd hold stabilization of newer versions.... it is not ONLY arch teams that can cause that 'problem', which is why I wanted the discussion to be more general
[23:24:03] <@vapier> ferdy: ive been telling people not to cater specifically to uClibc when it is a burden on them and the problem lies in uClibc
[23:24:17] <ferdy> yeah, forget uClibc for now
[23:24:21] <@vapier> sure
[23:24:33] <@vapier> can you propose other examples ?
[23:24:50] <@vapier> the only ones i can come up with are keeping old things around to support broken things
[23:24:56] <@vapier> and the answer is to fix or cull the broken things
[23:25:35] <@vapier> the only thing that has come up on the mailing list is arches holding it back
[23:25:49] <@vapier> so if you can show other general issues, i'd be happy to extend the proposal
[23:26:15] <@vapier> as it is, i'd be looking for probably 2x the time frames Richard put forth
[23:26:20] <@vapier> [ http://article.gmane.org/gmane.linux.gentoo.devel/54103 ]
[23:26:48] <@vapier> as you say, this is a volunteer basis, and people can easily get tied up
[23:27:15] <@dberkholz> 2 and 4 months, instead?
[23:27:26] <@dberkholz> 4 months is an awfully long time to wait
[23:27:57] <ferdy> vapier: I can't really give you more *examples* now (I think the reasoning is still valid), feel free to ignore it.
[23:28:09] <@vapier> ferdy: i dont intend for us to decide today on the issue
[23:28:32] <@vapier> i want us to put forth the recommendation to the list and the understanding is we'd decide next meeting
[23:28:36] <@vapier> i think that's reasonable ?
[23:28:47] <@Betelgeuse> sure
[23:29:13] <@dberkholz> i don't think i'd quite go 2x, but i could see a sort of 1.5-ish
[23:29:24] <@vapier> dberkholz: it is and it isnt ... maybe it's me, but i see a month shoot by in Gentoo world and not even realize it
[23:29:26] <@dberkholz> 3 months doesn't feel quite as forever
[23:29:27] <@Betelgeuse> The proposal should probably say something about reserve deps
[23:29:47] <@dberkholz> vapier: guess that depends on whether it's a month waiting for someone else to do something you care about. =)
[23:29:59] <ferdy> vapier: sure, it is reasonable
[23:30:08] <@vapier> i would make it dependent on the profile
[23:30:22] <@vapier> if the profile is set to "stable", then the reserve deps would need to be fixed
[23:30:35] <@vapier> but if it's set to "dev"+, then let it break
[23:31:00] <@dberkholz> it shouldn't be difficult to come up with some sort of scripts/tools to deal with that
[23:31:02] <@vapier> the burden is on the arch guys to resolve it, and it wouldnt break systems anymore than if you went through the revdeps
[23:31:12] <@dberkholz> if they don't already exist
[23:31:26] <jakub> vapier: does this 2+4 months suggestion include security issues, or should that be a separate policy?
[23:31:30] <@vapier> and it would actually be better for the arch guys -- fix the failing package and dont have to re-keyword the revdeps
[23:32:06] <@vapier> people groan when the word security pops up, but i dont think it's relevant
[23:32:30] <jakub> just asking ;)
[23:32:36] <@vapier> removing a security affected package wont force any additional upgrades on any systems
[23:32:47] <@vapier> world -Dup would give same result
[23:33:12] <@vapier> i'm doing a lot of talking here
[23:33:22] <@dberkholz> it's great.
[23:33:37] <@dberkholz> i'm used to doing all the talking. maybe i should start coming an hour late every time.
[23:34:11] FlameBook proposes that next meeting starts only once dberkholz is settled down :P
[23:34:25] <@FlameBook> dberkholz, I'm also used to _you_ doing all the talking ;)
[23:34:33] <Philantrop> vapier: KDE would prefer the 1.5x suggestion of dberkholz'.
[23:34:50] <@jokey> with dberkolz, writing up tools if needed shouldn't be much of an issue if really needed
[23:35:02] <jakub> vapier: mkay.... more precisely... should security be allowed to punt stuff if some arch is totally non-responsive for lets say over a year?
[23:35:13] <@vapier> ferdy: if you had a choice of timelines, does the 2x vs 1.5x really make a difference for you ?
[23:35:40] <@vapier> jakub: what we're talking about already allows culling at half that time
[23:35:57] <@vapier> ferdy: i know you're one of our over burdened arch guys ;)
[23:35:57] <jakub> vapier: thanks, answers my question :)
[23:36:17] <@vapier> but we need to balance things here, and i'm afraid it's fallen too far towards the arch currently
[23:37:33] xjrn [n=chatzill@!hc-24-4-108-16.hsd1.ca.comcast.net] has joined !c#gentoo-council
[23:38:11] <@vapier> perhaps an additional bugzilla keyword would help as well for arch teams to really eck out the way past due
[23:38:15] <@jokey> well there has been a lot of noise on -dev also which seems to have made it kind of hard to discuss just the topic and not the arch as such
[23:38:17] <jmbsvicetto> vapier: This discussion is beyond the current mips issue, right? Having mips move to only ~mips is on the table, right?
[23:38:17] <@vapier> CULLREQ
[23:38:43] <@vapier> jmbsvicetto: i'm not picking on mips here, this applies to everyone
[23:38:55] <@vapier> i imagine ive slacked more than other devs would like with some arch keywording
[23:39:11] <@vapier> i know ive lost arch on somethings, but i dont blame the maintainers for doing it
[23:39:15] <jakub> vapier: damn remove yourself from CC when done </rant> :P
[23:39:24] <@Betelgeuse> vapier: and use echangelog
[23:39:38] <ferdy> "Ebuild Stabilization Time" what happens when that period finishes ?
[23:39:41] <@Betelgeuse> vapier: But arm/sh/whatever don't have the coverage of mips I think
[23:39:50] <@vapier> jmbsvicetto: i imagine as a consequence of this agreement, maintainers will start the mips=>~mips
[23:39:59] <@FlameBook> Betelgeuse, better than mips for what I maintain at least
[23:40:01] <@dberkholz> should be easy enough to add all that to your keywording script with pybugz
[23:40:21] <@Betelgeuse> dberkholz: Is that working nowadays?
[23:40:22] <@vapier> but this would have applied to other arches in the past
[23:40:28] <@Betelgeuse> dberkholz: Last time I tried it didn't work.
[23:40:30] <beandog> Betelgeuse, http://spaceparanoids.org/gentoo/gpnl/stats.php?q=arch
[23:40:34] <@vapier> we just dont have vocal peeps for other teams like mips
[23:40:35] <@dberkholz> Betelgeuse: yep. wanna talk more about it, let's do that in !c#-dev
[23:40:37] <ferdy> the first paragraph of "Removing Stable Ebuilds." is what really really makes me nervous
[23:41:14] <@dberkholz> does that really mean removing so there's no stable version, or does it mean forcibly stabling a newer version?
[23:41:16] <@vapier> oh, i also forgot ... there needs to be a fallback for arches to explicitly pin a version indefinitely ... with the understanding that they'd be responsible for its up keep
[23:41:44] <@vapier> i do not think force stabilization by a non-arch maintainer makes any sense
[23:42:02] <@FlameBook> vapier, metadata.xml allows restricted maintainership, that would work, I suppose
[23:42:20] <@vapier> i know there's a few packages where s390 explicitly requires old versions of packages
[23:42:24] <@dberkholz> ok, so instead of giving something marked stable that might be broken, we give them no ebuild at all.
[23:42:26] <@vapier> dictated by ibm
[23:42:34] <@vapier> dberkholz: they get ~arch
[23:42:42] <jakub> vapier: well... similar fallback is feasible with single packages... not stuff like KDE I'd say... yeah, toolchain and similar for sure
[23:43:01] <@dberkholz> they get no ebuild at all without changing their configuration, which is exactly the same situation they'd be in if we force-stabled
[23:43:02] <jmbsvicetto> ferdy: In the case of kde, 3.5.5 is the only version with any mips keywords. So if that gets removed, mips will lose kde
[23:43:32] <@vapier> dberkholz: i think it sort of violates the guarantee that stable brings
[23:43:53] <@vapier> a package marked stable is an implicit guarantee from the arch maintainer that the version is known/supposed to work
[23:44:00] <@dberkholz> that was my possible "con" too, wasn't sure whether others would share it
[23:44:13] <@FlameBook> I agree with mike on this
[23:44:34] <@dberkholz> as not an arch person or a stable user, it's not exactly my best area
[23:45:14] <jakub> well... /me notes that, while talking about mips, tons of their 'stable' packages cannot compile on stable system at all
[23:45:15] <@vapier> presumably arches that get enough noise that their stable is going away should be able to muster some workflow to get newer versions stabilized
[23:45:27] <@vapier> we're not talking about mips
[23:45:31] <@vapier> stop mentioning mips
[23:45:52] <jakub> vapier: mkay... abstractly then :p should the maintainer be allowed to stabilize newer version in this case, or drop to ~arch
[23:46:07] <@vapier> in the case where a package would lose all stable keywords, if there are users affected, they'd convey to a maintainer that version FOO works, so the maintainer would have something to go on
[23:46:20] <@vapier> (arch maintainer there)
[23:46:29] <@vapier> which is a hell of a lot better than a package maintainer picking random versions and moving it
[23:46:51] <ferdy> in an ideal world, non-arch maintainers won't touch arch keywords (aside of ~all for bumps and that kind of stuff, of course)
[23:47:06] <jakub> vapier: not talking about arch testers/maintainers... simply stuff that fails to compile w/ current toolchain/base system stuff or similar
[23:47:16] <@Betelgeuse> ferdy: would be doable on the server side.
[23:47:20] <jakub> what's the value of 'stable' keyword there, it's useless
[23:47:41] <@vapier> ferdy: in an ideal world, the arch maintainers would be able to keep up
[23:47:45] <ferdy> jakub: 'worked with a stable system when it was tested'
[23:47:47] <@vapier> but that isnt always the case
[23:47:54] <ferdy> vapier: that was the second part of my sentence, sorry....
[23:48:00] <@vapier> np
[23:48:09] <jmbsvicetto> vapier: There's another issue in here, whether a maintainer should be forced to have a keyword added for an arch that has failed to keep up.
[23:48:17] <@FlameBook> well, I'm sorry to bail out before time, but fever is getting its way through my mind at the moment
[23:48:21] <jakub> ferdy: well... yeah it worked once upon a time, does not any more... no mre stable
[23:48:25] <ferdy> so we have to find a way for maintainers won't be affected when arch teams aren't able to keep up without messing anyones work
[23:48:38] <@FlameBook> I'm fine with whatever vapier thinks is fine, he knows the problem and I trust he'll do the right thing.
[23:49:00] <@vapier> jmbsvicetto: i dont follow ... pkg maintainers are not allowed to move ~arch to arch
[23:49:10] <@FlameBook> as for CoC I already said I'm okay with whatever dberkholz decides, as he's way more experienced than me in that regard, and I also trust him on that issue
[23:49:11] <@vapier> the proposal is to allow pkg maintainers to drop arch after a timeout
[23:49:33] <jakub> good, finally an answer... :)
[23:49:38] <@FlameBook> night 'rybody
[23:49:41] FlameBook [n=intrepid@!hamarok/helper/flameeyes] has quit IRC: "Leaving"
[23:50:01] <ferdy> jmbsvicetto: well... I think there shouldn't be a discussion about that. Arch teams' opinion is final, IMHO
[23:50:11] <@vapier> i'll take Richard's proposal, tweak it according to input here, and send it out, and we can decide on it next meeting
[23:50:18] <@vapier> aye ?
[23:50:21] <@lu_zero> fine
[23:50:25] <@dberkholz> sounds reasonable
[23:50:49] <@jokey> +1
[23:50:49] beandog [n=steve@!hgentoo/developer/beandog] has quit IRC: "Leaving"
[23:50:55] <jakub> well, one more thing... should a maintainer be allowed to ban $arch from keywording his package?
[23:50:57] <jmbsvicetto> vapier: No. Let me give an example. Maintainer of package xyz has had problems with 1 or more arches being able to mark stable or even keyword said package. Things get to a point where the package has one last, old version marked stable / keyworded on said arches. Should arch teams have the power to keep the keyword for that package when the maintainer doesn't want to depend on said arches any more?
[23:51:10] <jmbsvicetto> vapier: Assuming those timelines have been broken by the arch teams
[23:51:37] <@vapier> jmbsvicetto: it's a case by case basis which the maintainers/arches should agree on
[23:52:07] <jmbsvicetto> vapier: Well, what about cases where maintainers don't want to have that overhead anymore and the arch team won't cooperate?
[23:52:08] <@vapier> if the arch truly needs the older version, then they can keep it and they're responsible for maintaining it
[23:52:24] <@vapier> if they simply dont have the time to test a newer version, then the arch team loses
[23:53:05] <@vapier> we cant account for maintainers and arches being asshats
[23:53:19] <@vapier> if the two truly cannot come to a decision, they can ask a higher power (probably us) to decide
[23:53:23] <@jokey> vapier: as you'll post a revisited version, can we move to CoC?
[23:53:29] <@vapier> yeah
[23:53:30] <@Betelgeuse> yeah two council members can make a decision
[23:53:30] jokey looks at the clock
[23:53:41] <jmbsvicetto> vapier: We have a rule that prevents maintainers from dropping arches. Shouldn't we give them the option to not support an arch (on extreme cases)?
[23:53:48] <jakub> jokey: pffft, go open a beer ;P
[23:54:00] <Philantrop> vapier: Agreed. But let's assume a maintainer would consider actively dropping even ~arch should a team keyword the package *he/she* has to maintain.
[23:54:17] <@vapier> assume on the list
[23:54:20] <@vapier> moving on
[23:54:22] <@jokey> indeed
[23:54:27] <Philantrop> vapier: ok
[23:54:42] <@jokey> so CoC then and dberkholz' part :)
[23:55:09] Pesa [n=Pesa@!halpha.tat.physik.uni-tuebingen.de] has left !c#gentoo-council
[23:55:47] <@dberkholz> jokey: are those one and the same, or do i have another mystery part?
[23:55:52] <@vapier> personally, i'd think more about simply abolishing devrel resolution/etc... as well as CoC and take a more simple approach: if you're an asshat, you get tossed
[23:56:01] <@vapier> no drama
[23:56:10] <@jokey> dberkholz: it's the same ;)
[23:56:18] <@Betelgeuse> vapier: and who decides that?
[23:56:22] <@vapier> if you cant play nice, we have a size 15 boot here for you
[23:56:46] <@vapier> it should be pretty self evident
[23:56:52] <@vapier> every issue that's come up so far has been
[23:56:53] <fmccor> Betelgeuse, That's the quiestion, isn't it?
[23:57:00] <@vapier> but i digress
[23:57:08] <@vapier> go on with the CoC discussion
[23:57:31] <@dberkholz> the concept's in the agenda, but i'll briefly summarize
[23:58:06] <@dberkholz> where there are existing moderators, they will enforce the CoC themselves. other than that, the proposal would add mods to the -dev list and !c#-dev.
[23:58:44] <@lu_zero> who exactly?
[23:58:59] <@dberkholz> To Be Determined
[23:59:16] <@dberkholz> personally, i think that we could use some mod action on the list far more than !c#-dev
[23:59:31] <fmccor> Yes.
[23:59:36] <@jokey> maybe I'm mistaken but if someone goes insane on !c#-dev, it's a default devrel case, isn't it? and for immediate action, you can always give people a nice and warm kick
[0:00:23] <@dberkholz> jokey: that depends. do you want to wait 2 months for a trial?
[0:00:53] <TFKyle> vapier: would that be permanent or? (I assume by "tossed" you mean banned by atleast the medium that you acted up on in some way - or is that just for devs and getting your devship revoked?)
[0:01:10] <@jokey> we're all ops on !c#-dev so (theoretically) any dev can kick
[0:01:10] Cardoe [n=cardoe@!hgentoo/developer/Cardoe] has quit IRC: "Leaving"
[0:01:28] <@dberkholz> kicking an op doesn't get you very far.
[0:02:38] <@jokey> ubuntu people solve it by sharing a management account for the chan among 4-5 people who can immediately modify the lists if really needed
[0:02:42] <@dberkholz> the idea on irc would be to drop someone's level below autovoice for a day or whatever, then restore it.
[0:03:02] <@amne> imho just because everyone has ops doesn't mean there cannot be that there are some people that go after people who are abusive
[0:03:16] <@dberkholz> if said person is still nuts, kick 'em out as vapier said
[0:03:20] <@amne> e.g. what jokey and dberkholz just said
[0:03:24] <@amne> yeah
[0:04:21] <@dberkholz> the kicking part, at this point, would be handed off to devrel
[0:04:47] <@vapier> take some personal responsibility
[0:04:48] <@dberkholz> we could argue over whether it should instead be decided by the council
[0:04:51] <@vapier> if you cant, you will be warned
[0:04:52] bheekling [n=bheeklin@!h202.3.77.38] has joined !c#gentoo-council
[0:04:56] <@vapier> if you still cant, you get tossed
[0:05:02] <@vapier> get your act together, come back later
[0:05:10] <@vapier> dont get your act together, stop wasting our time
[0:05:15] <@jokey> indeed, vapier, fully with you :)
[0:05:39] <@vapier> but my dissertation on the subject is off-topic for this CoC stuff
[0:06:07] <@jokey> main reason is the -dev ML anyway so we should really focus on that
[0:06:19] <@dberkholz> vapier: nah, it's on topic
[0:06:24] <@vapier> there should be no body here ... developers should be able to call out on any other developer instead of idling accepting it
[0:06:40] <@vapier> err, "there should be no body here making the decision"
[0:06:47] <@dberkholz> what, have a duel?
[0:07:14] <@vapier> there is plenty of bad karma that goes down everywhere that onlookers just accept
[0:07:30] <@jokey> welcome to the real world ;=)
[0:07:33] <@vapier> i'm saying any moderation solution doesnt address the root of the problem
[0:08:10] <@dberkholz> how do you propose to change the root of the problem?
[0:08:36] <NeddySeagoon> vapier, Well, thats too many immature alpha males ... how do you fix that ?
[0:08:53] <@vapier> we steal g2boojum's seed, combine it with the good traits from developers, and kill off the originals
[0:09:48] <@dberkholz> i agree that we need to create a positive atmosphere. i think that moderators can be the first step in building a culture of intolerance toward assholes
[0:10:08] <@dberkholz> once that culture exists, we won't need mods anymore
[0:10:24] <@vapier> i'm looking long term
[0:10:34] <@vapier> what needs to be decided today needs to be decided today
[0:10:40] <@vapier> my thoughts dont really have bearing on it
[0:10:46] fmccor suspects that no matter where you start with vapier's approach, you will end up with something like devrel.
[0:11:09] <@vapier> no centralized body ... if you dont like the culture, fork your own
[0:11:11] <@vapier> go write a blog
[0:11:16] <@vapier> we dont care
[0:12:44] <@vapier> but seriously, dberkholz wants a resolution here, so focus on that
[0:13:20] <@amne> i think dberkholz' approach is good
[0:14:19] <@jokey> if it doesn't work out, we can/have to try something else anyway but I'm all for trying it
[0:14:25] <@amne> heh
[0:15:13] <@dberkholz> how many people are for the idea, as it stands now?
[0:15:51] <@amne> me
[0:15:58] <@jokey> as in do we want to vote?;)
[0:16:23] <@dberkholz> well, we don't really have enough details to finalize on, unless you'd just like to delegate further details to someone
[0:16:47] <NeddySeagoon> I don't see the difference between the current proposal and the Proctors
[0:17:37] <jmbsvicetto> NeddySeagoon: From previous discussions, it seems it will be an even smaller group and very close to the council
[0:17:47] <@dberkholz> there are no pointless warnings, only actions.
[0:18:15] <@dberkholz> there isn't going to be discussion about moderation on -dev, so people will have to actually make a little effort to whine about it.
[0:18:15] <NeddySeagoon> dberkholz, Hmm ok
[0:18:26] <@dberkholz> since -dev is now purely technical
[0:20:07] <@dberkholz> i think getting bogged down into -dev threads with attempted warnings, responses, and so on was an approach the mods should never take
[0:21:13] <@dberkholz> we're starting to rehash discussions we've already had
[0:22:04] <@dberkholz> so, what i would like from council members is: do you like the idea, do you think it needs significant changes, or do you dislik eit
[0:22:18] hkBst [n=hkBst@!hgentoo/developer/hkbst] has quit IRC: "Konversation terminated!"
[0:22:46] <@dberkholz> if we can agree that the idea is the way to go, we can start focusing on the details instead of returning to the original idea all the time
[0:23:06] <@lu_zero> I like the idea
[0:24:40] jokey too
[0:24:50] <@vapier> i'm with dberkholz
[0:25:40] <@dberkholz> Betelgeuse, around?
[0:25:50] <@Betelgeuse> dberkholz: yeah
[0:26:04] <@Betelgeuse> dberkholz: you rule
[0:26:22] <@dberkholz> good to hear. =)
[0:26:47] <@dberkholz> alright. we're going to proceed with this idea. i'll try to get some concrete ideas out to the -council list this week
[0:27:39] pchrist_ [n=tester@!h84.38.8.37] has joined !c#gentoo-council
[0:28:03] <@dberkholz> anyone else got additional CoC points now?
[0:29:10] <@dberkholz> ok, let's open the floor for any new topics
[0:31:03] <@jokey> well we have one missing
[0:31:12] <@jokey> Document of being an active developer
[0:31:16] Sweetshark [n=bjoern@!hd018195.adsl.hansenet.de] has joined !c#gentoo-council
[0:31:21] <@jokey> s/missing/left/
[0:31:43] <@vapier> i think that's something we could do with infra
[0:31:53] <@vapier> have it be something you need to log into dev.g.o
[0:31:57] <@vapier> run a command
[0:32:08] <@vapier> it generates a digitally signed document
[0:32:18] <@vapier> the digital key is maintained by infra
[0:32:41] <@vapier> therefore random devs cant generate documents and just change the names
[0:33:06] <@vapier> have it auto-include information like date of joining
[0:33:07] <@jokey> we could add that our userlist.xml can be used for reference if it is still accurate
[0:33:12] <xjrn> is gentoo in a  position to broker liveId's?
[0:33:42] <@vapier> jokey: right, now that the ldap and crap is integrated
[0:33:45] <@vapier> use that as the backend
[0:34:04] <@Betelgeuse> jokey: userinfo.xml is generated from LDAP
[0:34:06] <@dberkholz> xjrn: is that different from openid?
[0:34:55] <@jokey> Betelgeuse: that's my point, once you set it to retired, it's killed at max 60 minutes later on the website
[0:35:02] <@dberkholz> araujo: could you just print off an "official" gentoo business card with your name on it, that perhaps only gentoo devs have access to
[0:35:06] ferdy [n=ferdy@!hgentoo/developer/ferdy] has quit IRC: "[IRSSI] Tiger Woods uses Irssi. FORE!"
[0:36:18] <@vapier> eh, no one accepts business cards as proof of anything
[0:36:25] <@vapier> ive tried
[0:36:43] araujo looks around
[0:36:52] <xjrn> dberkholz: sorry openId
[0:37:00] <araujo> dberkholz, you mean, to send it to every developer?
[0:37:10] <@amne> sorry guys, i'm already falling asleep here, so i'll idle out
[0:37:12] <@dberkholz> araujo: just have a template of some sort sitting on woodpecker
[0:37:25] <@dberkholz> devs can grab it and do whatever they need
[0:37:35] <@dberkholz> if not a business card, some other document
[0:38:05] <araujo> dberkholz, ok , so we won't need a script for this?
[0:38:29] <@dberkholz> araujo: that depends how provable your proof has to be. i haven't seen digitally signed things from any job i've ever had
[0:39:02] <@dberkholz> what are the requirements?
[0:39:42] <araujo> dberkholz, it doesn't need to be something that complex, only a document specifying for how long you have been a Gentoo devel, and if you are still active
[0:40:11] <araujo> something that can 'officially' prove you are a developer
[0:40:11] NeddySeagoon [n=NeddySea@!hgentoo/developer/NeddySeagoon] has quit IRC: "what, what, what, what, what, what, what, what, what, what.  Only 10 Watts Neddy ?  Thats not very bright!"
[0:40:39] rbrown [n=rbrown@!hgentoo/developer/paludis.rbrown] has left !c#gentoo-council
[0:40:39] <araujo> it'd be nice if it is digital signed too
[0:40:46] <araujo> digitally*
[0:40:48] <@dberkholz> if we just had a pretty little scribus document that looked pretty and called itself a certificate of some sort, that might be enough?
[0:40:59] <araujo> dberkholz, yeah, pretty much
[0:41:32] <@jokey> maybe stuff like you can get from SETI
[0:41:40] <@jokey> "You have solved X workunits" ;)
[0:42:33] <araujo> this is just a way so you can prove 'on paper' you are cooperating with the project
[0:43:37] musikc [n=musikc@!hgentoo/developer/musikc] has quit IRC: Read error: 110 (Connection timed out)
[0:43:48] <tsunam> I had created 2 forms of letterhead when seemant needed to do a thing for another developer
[0:43:51] pchrist [n=tester@!hunaffiliated/pchrist] has quit IRC: Read error: 110 (Connection timed out)
[0:43:55] <tsunam> recommendation
[0:44:09] musikc [n=musikc@!hgentoo/developer/musikc] has joined !c#gentoo-council
[0:44:14] <tsunam> not exactly what you're talking about but
[0:44:50] <tsunam> A standard form letter would work
[0:44:56] <tsunam> (well should)
[0:45:15] <araujo> or the dberkholz's certificate idea too , both would make it
[0:45:15] <@jokey> indeed
[0:45:25] <@dberkholz> except someone would have to actually sign a standard form letter, requiring effort from other people
[0:46:07] <tsunam> I hereby certify that under perjury of $court of law that Mr berkholz is a developer for the Gentoo Linux Foundation. Undersigned by Joshua Jackson Gentoo developer etc
[0:46:17] <araujo> dberkholz, sign once and scan then? :-P
[0:46:23] <tsunam> dberkholz: would it be hard to get someone to do that?
[0:46:33] <@dberkholz> tsunam: depends whether 1 person or 300 request them
[0:46:34] <tsunam> araujo: no one would want their signature scanned like that
[0:46:56] <araujo> tsunam, well, if it is hand-written per letter, *much better*
[0:46:57] <@dberkholz> you'd have to deal with other annoying stuff like postage etc
[0:47:32] <@jokey> well we could make all council members capable of signing such letters
[0:47:49] <@jokey> and you pick the closest on then
[0:47:52] <araujo> indeed
[0:47:55] <@dberkholz> we could email out signed emails
[0:47:57] <@dberkholz> would that work?
[0:48:08] <araujo> dberkholz, it would work from my point of view
[0:48:14] <@jokey> not really, corporate stuff hardly works with gpg
[0:48:31] <araujo> what if we have both options available?
[0:48:39] <tsunam> I'm not sure how willing an email would be as proof even if its from an @gentoo account for proof...
[0:48:40] <@dberkholz> it does in the US, there's the e-sign act that's legally replacing an ink signature. not sure about other places
[0:49:03] <@jokey> dberkholz: in germany you have to acquire some X509 at least
[0:49:12] <@jokey> plus it's not equal in all cases
[0:49:53] <@dberkholz> i don't think we need something that will hold up to a court of law
[0:50:25] <Philantrop> dberkholz: No, but an email doesn't look very professional which would be a problem over here, at least. :) Much more than the legal stuff.
[0:51:15] <@dberkholz> Philantrop: <html><img src="fancygentoologo" /></html>
[0:51:31] <araujo> if you can agree on sending this letter to the actual developer (costs paid by devel of course) would be way much better, it'd be valid in a wider range of situations
[0:52:14] <@dberkholz> araujo: the costs would basically be a pint, if you ever happened to meet. nobody's going to ask you to send them that kind of money.
[0:52:25] <araujo> dberkholz, ok
[0:52:48] <@dberkholz> it just gets to be a problem if certain people end up sending out huge numbers to foreign countries
[0:52:54] <@Betelgeuse> The post expenses are probably smaller thatn the international money transfer expenses
[0:53:21] <@dberkholz> i would much rather have something where the person who wants it can do all the work
[0:53:40] <@dberkholz> either manually filling stuff into scribus, or some autogenerated doc like vapier said
[0:53:45] <araujo> dberkholz, that'd be ideal ...
[0:53:56] <@vapier> i wonder if you can combine the two
[0:54:03] <@dberkholz> probably, it's just xml
[0:54:17] <@vapier> ah, was not aware
[0:54:36] <@vapier> do we have any scribus to start with ?  or does someone need to start from scratch ?
[0:54:57] <@dberkholz> find . -name '*.sla*'
[0:56:09] <@vapier> araujo: you any good at scribus ? ;)
[0:56:11] <Philantrop> dberkholz: I totally agree with that. The Scribus variant would be my personal favourite but an automated doc is fine, too. Just email is not ideal. :)
[0:56:18] <@dberkholz> think there's some stuff floating around
[0:56:23] <@dberkholz> i can do scribus
[0:56:40] <@jokey> ack, scribus would look even nicer :)
[0:56:46] <araujo> vapier, haha, not really, but i can help
[0:57:00] <@vapier> so we'll follow up to the dev list
[0:57:08] <@vapier> see if there are any quick takers
[0:57:13] dberkholz notes his above comment
[0:57:16] <@vapier> ive toyed with scribus and it doesnt seem terribly difficult
[0:57:22] <@jokey> still at least I'm willing to offer hand-signed if developer who requests it pays shipping
[0:57:24] araujo can help dberkholz 
[0:57:37] <@vapier> dberkholz: well i was just trying to get the guy who wanted it to do it :)
[0:57:38] <@dberkholz> aha, gentoo-projects/pr/ has some scribus stuff
[0:57:49] <@vapier> scribus base + automated fill in + digital signing
[0:57:52] <araujo> jokey, yes, I think it's good idea to offer 'both' ways
[0:57:54] <@vapier> see if we cant get infra to do somethin
[0:58:00] <@dberkholz> i can come up with a scribus template, araujo can deal with the rest
[0:58:04] <tsunam> I'd probably say that quite a few developers wouldn't mind having something official that says "I worked on the project" to be honest
[0:58:20] <@dberkholz> tsunam: perhaps we should start handing out little pins for years of service too =)
[0:58:25] <xjrn> wow, seems like nukes and htmldoc could do the whole thing to validate an account has a status into a pdf mime/download ...
[0:58:25] <tsunam> dberkholz: lol
[0:58:38] <tsunam> dberkholz: now you're getting the idea ;)
[0:58:45] <tsunam> dberkholz: gold watch after 25 years? :-P
[0:58:51] <araujo> dberkholz, ok
[0:58:56] <@dberkholz> something along those lines wouldn't be a bad idea, actually. i'll look into it.
[0:59:06] <@dberkholz> not with actual expensive stuff, but at least personal emails
[0:59:11] <araujo> so, any council member will be able to sign it?
[0:59:27] jokey is for that
[0:59:30] <@dberkholz> araujo: we'd probably just come up with a signing key that would autorun somewhere
[0:59:31] <tsunam> I would say that the council would be the body that would be the best choice
[0:59:59] <araujo> dberkholz, ok
[1:00:00] <@dberkholz> perhaps get it signed by the releng key, unless there's a more master key around
[1:00:24] <@jokey> could even generate a council key if needed
[1:00:41] <@vapier> tsunam: you think we're made out of money ?
[1:00:45] <@vapier> how about a pen
[1:00:51] <@vapier> that's all i get at a real job
[1:00:52] <tsunam> vapier: heh
[1:00:55] <@vapier> a goddamn pen
[1:01:03] <@vapier> oh and a pin
[1:01:03] <tsunam> vapier: at least you get a pen...
[1:01:17] <@jokey> "I've been with gentoo for 3 years and all I got is this damn T-Shirt" ;)
[1:01:23] <araujo> hah
[1:01:23] <@vapier> tsunam: you can have mine
[1:01:26] <@dberkholz> how about fake glass jewels on your nametag. (nametag purchased separately)
[1:01:38] lu_zero heads to bed
[1:01:44] <@lu_zero> nite
[1:01:48] <araujo> later lu_zero
[1:01:55] <@dberkholz> jokey: yeah, it might not be a bad idea to come up with a master gentoo key if we end up having more than 1 purpose for it
[1:02:11] <@dberkholz> one we could hide in a fireproof vault somewhere and only remove once a year
[1:03:14] <@jokey> don't even need that... make it "Gentoo Council Signing Key 2007-2008" and invalidate when new council is approved
[1:03:36] <@vapier> it sounds like a key for recruiters to maintain
[1:03:43] <@vapier> they are the in/out gateway after all, not the council
[1:04:10] <@Betelgeuse> vapier: in only
[1:04:16] <@Betelgeuse> vapier: different team doing retirement
[1:04:22] <@dberkholz> there's "undertakers" now
[1:04:37] <@dberkholz> doesn't that cool name make you want to join?
[1:04:58] <@jokey> want just one point agreed on explicitely: will council members be allowed to sign such documents on behalf of gentoo?
[1:05:22] <@dberkholz> perhaps so, but they should somehow log their actions like that
[1:05:25] <@vapier> infra then i guess since they are the real care takers of this information
[1:05:36] <@vapier> recruiters/undertakers update the same db
[1:05:51] <@vapier> it's a key signing fest
[1:06:01] <tsunam> ultimately it needs to reside with someone...and as it appears there's not one group its perfect for...
[1:06:06] <tsunam> who would actually accept the duty?
[1:06:07] <@jokey> dberkholz: as in send a notification to council@?
[1:06:13] <araujo> I guess you (the council) will have to track the signing of these documents?
[1:06:35] <@dberkholz> jokey: or something else that people don't see unless they go looking for it, like a file in cvs
[1:06:48] igli [n=igli@!hunaffiliated/igli] has left !c#gentoo-council: "Have a good one ;-)"
[1:07:05] <@dberkholz> tsunam: it sounds like devrel in some way to me, wherever it falls in there
[1:07:22] <@vapier> yeah
[1:07:49] <tsunam> well that's 4 groups now, recruiters,hatchetmen (aka undertakers),council,devrel
[1:08:12] <@dberkholz> recruiters+undertakers all fall into devrel. we could just hand it off to devrel lead to take from there
[1:08:47] <@dberkholz> imagining devrel as a sort of HR dept, and council as executives, this seems like something that's clearly HR
[1:08:48] <@vapier> yes
[1:08:59] <tsunam> very valid point dberkholz
[1:10:27] <@dberkholz> so, where to proceed from here
[1:11:02] <@jokey> dberkholz: you and araujo looking into a scribus'ed template, devrel generating a signing key for these purposes?
[1:11:44] <@dberkholz> musikc: around again?
[1:13:28] <@jokey> could we agree on that plan and then close the meeting if there's nothing else? 1 a.m. here already ;)
[1:13:54] <araujo> fine with me :-)
[1:13:59] welp [n=welp@!hgentoo/developer/colchester-lug.member.welp] has quit IRC: Read error: 110 (Connection timed out)
[1:14:22] <@dberkholz> jokey: sounds good
[1:14:50] <@jokey> k' then
[1:15:05] <@dberkholz> let's close up shop for this month
[1:15:12] <@jokey> indeed
[1:15:20] <@dberkholz> jokey: you're on summary/log committing and mailing duties
[1:15:42] <@jokey> dberkholz: yup, written it already, can you quickly glance over it to spot potential typos? ;)
[1:16:19] <araujo> dberkholz, brb in a few minutes, then I can look into this
[1:16:43] <@dberkholz> jokey: could you try to add a one-line summary for each topic, right whether the topic name is. like GLEP 54: Postponed to -dev. etc..
[1:17:10] <@dberkholz> s/compability/compatibility/
[1:17:21] <@dberkholz> s/techincally/technically/
[1:17:28] <@dberkholz> s/optionl/option/
[1:17:46] <@dberkholz> s/compatibiliy/compatibility/
[1:17:58] <@jokey> wondering if there are dicts installed on dev.g.o
[1:18:17] <@dberkholz> could you note in CoC that i'll provide them on the -council mailing list
[1:19:00] ulm [n=ulm@!hgentoo/developer/ulm] has left !c#gentoo-council: "ERC Version 5.2 (IRC client for Emacs)"
[1:25:40] <@jokey> we're closed then. thanks for the discussion to everyone involved :)