diff options
Diffstat (limited to 'xml/htdocs/proj/en/council/meeting-logs/20080110.txt')
| -rw-r--r-- | xml/htdocs/proj/en/council/meeting-logs/20080110.txt | 1038 |
1 files changed, 1038 insertions, 0 deletions
diff --git a/xml/htdocs/proj/en/council/meeting-logs/20080110.txt b/xml/htdocs/proj/en/council/meeting-logs/20080110.txt new file mode 100644 index 00000000..e154ba98 --- /dev/null +++ b/xml/htdocs/proj/en/council/meeting-logs/20080110.txt @@ -0,0 +1,1038 @@ +# 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 :) |