# Log started, 10.01.2008 21:00 CET [21:01:22] jokey gives betelgeuse another 3 minutes [21:02:08] 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] Flameeyes [21:09:07] <@FlameBook> vapier, I'm here, I'd just be lesser profile than usual (because of a cold0 [21:09:12] 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] 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] 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] 1) is somewhat related to glep55, but also an issue if that would be accepted [21:14:09] 3) is mostly my dislike for special cases required by the glep [21:14:41] <@lu_zero> hmm [21:14:51] (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] genone: pkg-1a PN-PV or PN? [21:17:21] 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] 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] 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] it's also a valid PF [21:20:02] vapier: http://bugs.gentoo.org/show_bug.cgi?id=9202 [21:20:16] 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] 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] b/c scm is different than other suffixes we have [21:22:22] 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] 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] igli: I think you are confused... [21:24:53] *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] 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] 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] 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] well, portage accepts '*' as a pkgname, is it valid then? [21:26:33] 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] 9999 is a dirty hack, for one [21:27:34] 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] 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] vapier: if it's used for more than ordering (likely), -scm seems better to me [21:30:56] 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] 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] which these benefits are not available with existing -cvs[0-9]* ? [21:34:17] of^ [21:34:34] <@Betelgeuse> periodic reinstall but that could probably be done with 9999 too [21:35:06] 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] 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] 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] 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] well, package sets as implemented in portage are extremely flexible, just need the data [21:38:47] <@lu_zero> 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] I mean that 9999 is a hack [21:39:14] 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] so you match any number of nines as scm? [21:39:54] 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] FlameBook: support every scm system? what? [21:43:33] DrEeevil [i=dreeevil@!hgentoo/user/bonsaikitten] has joined !c#gentoo-council [21:43:42] IOW, foo-scm is $PN-$PV or $PN? [21:43:49] 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] why are you so concerned about changing the version spec? [21:44:50] false positives and not looking like a hack [21:44:57] jakub: think $PN-$PV is the intent [21:44:58] we can clean up the mess [21:44:59] <@FlameBook> ferdy, false positive doing what? [21:45:04] <@FlameBook> which mess? [21:45:04] 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] TFKyle: and, how are you going to ensure that? (well sorry for the noise here) [21:45:54] 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] 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] 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] actually, it's pretty easy together with GLEP 55 [21:47:21] 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] 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] no, you can ask eclasses to comply to some 'protocol' like "return blah from function bleh if there are no changes" [21:48:26] 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] 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] who said we should implement that hack ? [21:49:12] <@lu_zero> ferdy what's written in the glep-54? [21:49:14] 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] 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] 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] 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] 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] 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] 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] 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] FlameBook: yes, but those are quite a bit harder to access [21:56:35] ferdy: fetches a fixed rev from a repo [21:56:41] 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] 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] just saying [21:58:08] FlameBook: depends [21:58:14] <@FlameBook> just need to keep the dynamic sets' definitions consistent with the installed packages [21:58:36] 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] emerge --reinstall-scm [22:00:30] heh... so "it can be done with dynamic sets" is pure science fiction [22:00:48] 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] 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] 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] jakub: why not 99999? [22:03:06] 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] 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] lu_zero: no it doesnt, read up why [22:04:11] jokey: there are packages with versions like YYYYMMDD, so rather a common hack [22:04:12] that doesn't handle a package that has several different scm 'versions' as git does [22:04:20] 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] jakub: doesn't work, read what I said [22:05:21] vapier++ [22:05:26] 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] 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] jakub: again, the 9999 doesn't work, read up why... it is a legit case [22:06:25] vapier: alright [22:06:26] <+musikc> vapier: agreed. lots of discussion on this one still. [22:06:28] 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] ferdy: it worked for me for ages :) well, doesn't belong here really [22:06:52] 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] jakub: doesn't in the case of git where you need at least two different 'scm' versions [22:07:17] ferringb: does it really need more args than nobody using it? [22:07:27] <@lu_zero> ferdy 2? [22:07:33] yes, two [22:07:33] <@lu_zero> as in? [22:07:41] peper: well, how many people actually know about it? [22:07:55] (but I agree it sucks) [22:07:56] 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] 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] 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] lu_zero: 2 as in 'master' and 'next' and every master and next from every release cycle [22:09:21] 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] 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] vapier: do you except me to do any changes or just repost as is? [22:10:35] jokey: did I say otherwise ? [22:10:42] *expect [22:11:07] 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] 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] 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] ok, move on to 55, I want to see what you think about it first [22:13:31] 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] poor jokey :) [22:15:09] 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] genone: hmm, where is scope of EAPI defined that you are talking about expanding? [22:16:05] genone: unless I'm on crack, it still explicitly requires it due to the post source EAPI angle [22:16:14] 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] 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] peper: you very well know that it's not defined formally [22:17:33] 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] ferringb: hrm.. how so ? [22:18:03] 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] ferringb: for backwards compatibilty [22:18:27] read the Application part of the glep [22:18:48] specification is how pm is supposed to do it to get it right [22:19:01] 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] ferringb: and who would make such an ebuild? [22:19:34] 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] ferringb: I seem to recall the GLEP explicitly prohibiting that [22:19:52] lu_zero: have you read the discussion ? [22:20:07] lu_zero: read Problem section [22:20:12] <@lu_zero> done [22:20:12] in the mailing list, I mean. I think it has been covered... [22:20:14] 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] 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] 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] 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] 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] 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] 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] ferringb: isn't it handled in the other ideas secion? [22:25:00] (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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] generally, you query cache for stuff, not traverse it [22:32:02] the subdir approach is nasty besides the performance issues [22:32:15] genone: agreed by all, I suspect [22:32:35] hncaldwell [n=hncaldwe@!hgrey.iitsystems.csupomona.edu] has joined !c#gentoo-council [22:33:04] this is all starting to sound like over-design [22:33:11] designing for a situation that will never happen [22:33:15] KISS [22:33:52] Cardoe++ [22:34:00] <@Betelgeuse> well this hsould be useful for changing how inherit behaves etc [22:34:03] you are just not thinking enough [22:34:05] Ken69267 [n=Ken69267@!hgentoo/contributor/ken69267] has joined !c#gentoo-council [22:34:15] yep [22:34:30] 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] 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] for one, it's not backwards compatible [22:36:18] <@Betelgeuse> peper: well we would just have agree on profile.bashrc [22:36:18] peper: via bashrc stuck into the repo, it is [22:36:26] interim compatibility func basically [22:36:47] 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] not that I care ... [22:37:23] 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] we don't need back compatibility for paludis at this point [22:38:13] peper: so... imo, it's backwards compatible- sorry to spring it on you during this meeting rather then ML prior also ;) [22:39:15] it doesn't allow to change the versioning spec and I see it useful [22:39:26] 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] 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] s:via it:view it:, pardon [22:40:34] peper: question: is glep54 the main (only?) motivation for glep55 for you? [22:40:50] 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] vapier: backwards compatibility for one [22:43:53] 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] 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] 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] 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] 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] 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] vapier, jokey: Why should we always operate *reactively*? [22:48:45] 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] 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] if we over-design and work on engineering something that MIGHT happen, but never happens [22:50:04] rather then engineering a logically extensible method (what EAPI itself provides), that can be in the future changed as things necessitate. [22:50:09] 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] vapier: right. that was the whole point that spawned this whole thing. [22:50:58] vapier: well, that's simply not possibly, no matter how you define EAPI [22:51:00] vapier: instead we've added about 12 steps of complexity and didn't even solve the original thing. [22:51:07] eclasses can't define EAPI [22:51:14] <@vapier> why not ? [22:51:23] <@vapier> why cant we segment things logically [22:51:39] vapier: which EAPI is effective: the calling env or the definition env? [22:51:53] <@vapier> genone: segment things logically [22:51:53] genone: could you rephrase the question please (didn't get the meaning there) [22:52:02] 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] vapier: not true, imo [22:52:49] <@vapier> might as well push it back to the list [22:52:59] 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] ferringb: see http://article.gmane.org/gmane.linux.gentoo.devel/53354 [22:53:21] I think you meant vapier [22:53:23] <@vapier> ferringb: having one env force/imply restrictions on the other is bad [22:53:51] 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] vapier: http://article.gmane.org/gmane.linux.gentoo.devel/53354 <- answer those questions please if you want different EAPIs [22:54:37] 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] 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] I am going to repost the GLEPs as is and hope you guys ask your questions there [22:59:33] 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] 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] jokey: the subjective part of the summary in GLEP 54 is wrong [23:03:36] 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] 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] jokey: I meant GLEP 54 [23:04:33] 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] no, it's not true [23:06:25] 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] 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] 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] peper: it is possible, your example didn't work out, also see bug !c#174536 [23:10:05] 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] FlameBook: is there someone going to respond to those mails? wasn't my experience so far.... [23:13:51] 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] 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] nod [23:15:09] <@vapier> when in reality that isnt right [23:15:36] I'd like you to consider what I posted to that same thread: http://mid.gmane.org/20080109121309.GA14454@ferdyx.org [23:15:57] 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] 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] jakub: retiring a maintainer doesn't solve the issue... [23:17:34] ferdy: sure it doesn't, but it [23:17:43] '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] 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] 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] ain't the same situation [23:18:50] <@vapier> and you can transition arches to a state that keeps maintainers happy [23:19:14] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] sure ;) [23:23:33] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] vapier: damn remove yourself from CC when done :P [23:39:24] <@Betelgeuse> vapier: and use echangelog [23:39:38] "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] 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] 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] 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] 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] 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] 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] 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] 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] 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] jakub: 'worked with a stable system when it was tested' [23:47:47] <@vapier> but that isnt always the case [23:47:54] vapier: that was the second part of my sentence, sorry.... [23:48:00] <@vapier> np [23:48:09] 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] ferdy: well... yeah it worked once upon a time, does not any more... no mre stable [23:48:25] 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] 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] 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] well, one more thing... should a maintainer be allowed to ban $arch from keywording his package? [23:50:57] 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] 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] 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] 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] jokey: pffft, go open a beer ;P [23:54:00] 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] 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] 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] 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] 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] 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] I don't see the difference between the current proposal and the Proctors [0:17:37] 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] 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] 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] dberkholz: sorry openId [0:37:00] 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] 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] 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] 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] it'd be nice if it is digital signed too [0:40:46] 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] 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] 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] 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] recommendation [0:44:09] musikc [n=musikc@!hgentoo/developer/musikc] has joined !c#gentoo-council [0:44:14] not exactly what you're talking about but [0:44:50] A standard form letter would work [0:44:56] (well should) [0:45:15] 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] 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] dberkholz, sign once and scan then? :-P [0:46:23] 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] araujo: no one would want their signature scanned like that [0:46:56] 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] indeed [0:47:55] <@dberkholz> we could email out signed emails [0:47:57] <@dberkholz> would that work? [0:48:08] dberkholz, it would work from my point of view [0:48:14] <@jokey> not really, corporate stuff hardly works with gpg [0:48:31] what if we have both options available? [0:48:39] 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] 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: [0:51:31] 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] 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] 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] 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] 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] 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] 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] 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] dberkholz: lol [0:58:38] dberkholz: now you're getting the idea ;) [0:58:45] dberkholz: gold watch after 25 years? :-P [0:58:51] 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] 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] I would say that the council would be the body that would be the best choice [0:59:59] 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] vapier: heh [1:00:55] <@vapier> a goddamn pen [1:01:03] <@vapier> oh and a pin [1:01:03] 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] 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] 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] ultimately it needs to reside with someone...and as it appears there's not one group its perfect for... [1:06:06] who would actually accept the duty? [1:06:07] <@jokey> dberkholz: as in send a notification to council@? [1:06:13] 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] 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] 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] 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] 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 :)