From 89b40f7f73bd94c204b9a511490d63a6050a7917 Mon Sep 17 00:00:00 2001 From: Alex Alexander Date: Thu, 25 Feb 2010 21:41:06 +0000 Subject: added kde meeting log for 20100225. fixed older log's extension. --- meeting-logs/kde-project-meeting-log-20100225.txt | 612 +++++++++++++ .../kde-qt-projects-meeting-log-20091119.log | 959 --------------------- .../kde-qt-projects-meeting-log-20091119.txt | 959 +++++++++++++++++++++ 3 files changed, 1571 insertions(+), 959 deletions(-) create mode 100644 meeting-logs/kde-project-meeting-log-20100225.txt delete mode 100644 meeting-logs/kde-qt-projects-meeting-log-20091119.log create mode 100644 meeting-logs/kde-qt-projects-meeting-log-20091119.txt diff --git a/meeting-logs/kde-project-meeting-log-20100225.txt b/meeting-logs/kde-project-meeting-log-20100225.txt new file mode 100644 index 0000000..04fa9dd --- /dev/null +++ b/meeting-logs/kde-project-meeting-log-20100225.txt @@ -0,0 +1,612 @@ +[21:27:14] ok let's start +[21:27:23] roll call plz +[21:27:26] !herd kde +[21:27:28] (kde) abcd, alexxy, carlo, cryos, dagger, deathwing00, jmbsvicetto, keytoaster, lxnay, mrpouet, patrick, scarabeus, spatz, sping, ssuominen, tampakrap, tgurr, wired +[21:27:48] here +[21:28:17] . +[21:28:43] here +[21:28:56] * alexxy here or there +[21:29:00] alexxy: indeed :P +[21:30:19] . +[21:30:25] Sput: we need you for this one, present? +[21:31:03] lets start with kdepim +[21:31:14] jorge is going to be around in ~10 minutes +[21:31:22] hmm +[21:31:26] so the relevant tasks even for him should be that way preserved :] +[21:31:31] TOPICS: http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=blob;f=Documentation/meeting-2010-02-25;h=dafe5aa85c43ba9737c783576af83c972ea82afa;hb=594ec14216daa0f2f331295d4baff3e0f6d78a5c +[21:32:14] ok about kdepim and enterprise useflag +[21:32:32] also can we discuss snapshots for 4.5 pre alphas? +[21:32:33] =) +[21:32:50] ohnoes +[21:32:51] sure, along with this +[21:33:11] *** Quits: j0hu (~quassel@quassel/contributor/j0hu) (Read error: Connection reset by peer) +[21:33:19] also using lxc as testbead for testing kde builds +[21:33:25] the kdepim issue is about the trunk kde i don't know if anyone of you is interested in it +[21:33:30] * alexxy prepared some containers +[21:33:55] tampakrap: what issue? +[21:34:01] kmail is broken in current trunk, i tried to package the enterprise branch which is supposed to work +[21:34:26] why we should care about trunk? +[21:34:31] afaik the enterprise branch should be available for releases as well +[21:34:39] reavertm: because that's what's going to be in 4.5 +[21:34:44] enterprise branch should be availible for everything +[21:35:01] scarabeus: jmbsvicetto and i talked with a kde dev [cant recall his name right now] who told us enterprise branch is what they really care about +[21:35:24] we should just monthly generate our own kdepim tarball from that branch +[21:35:27] and be done with it +[21:35:34] maybe even forgot about non-enterprise :] +[21:35:36] considering the [crappy] state of kdepin right now, thats a good idea +[21:35:39] two packages failed to compile from enterprise stuff, plus a flag isn't possible for trunk as ebuilds are different +[21:35:40] kdepim* +[21:36:28] 1) there is enterprise related cmake switch in cmakelists.txt - maybe it should be used when bulding enterprise branch +[21:36:47] am i right that kmail is broken because of mail storage migrartion to akonadi? +[21:36:49] 2) still don't see why we should care :P +[21:37:02] reavertm: enterprise should actually work OK +[21:37:08] and kde devs care about it not breaking +[21:37:17] at least thats what we've been told +[21:37:18] :p +[21:37:22] i agree with reavertm, too much work, maybe we should just wait +[21:37:28] too much work for nothing +[21:37:29] problem is it does not follow kde release schedule +[21:37:44] it is released with each even release +[21:37:51] especially if apparently they're going to merge it eventually? +[21:38:40] no its not going to be merged +[21:38:49] now, I've not tried to build it yet - is it possible to use our ebuilds? +[21:38:59] or it differs too much so that it's impossible? +[21:39:04] okay, i am having hardware issues with my trunk machine and don't know when it will be back, so i can't work on it any more +[21:39:10] it differs too much +[21:39:21] it's not impossible, it is way too much work +[21:39:21] Hello +[21:39:26] tampakrap: you are talking about trunk, we are talking about releases +[21:39:28] hey jmbsvicetto +[21:39:34] sorry for being late +[21:39:37] i'm talking about enterprise itself +[21:39:40] I confused the hour again :\ +[21:39:52] * spatz is back +[21:40:16] and my opinion is the same for the snapshots, way too broken to be provided to users +[21:40:45] i can announce it and blog it, whatever, that we can't provide them if you agree +[21:40:49] other issue, how are we going to provide it? split like kdepim? +[21:41:15] yes, it needs different branch of ebuilds +[21:41:44] anyone willing to work on it? +[21:41:54] and probably blocking kdepim... +[21:42:01] or just postpone it for next meeting? +[21:42:03] exactly +[21:42:17] ok i personaly cant promise i will devote time to it :/ +[21:42:30] so it would need some maintainer, even non dev +[21:42:39] just in overlay so we see the potential +[21:42:44] and then we can put it into tree +[21:42:48] agreed +[21:42:50] i could announce it +[21:43:28] ok we should anounce global call if we find someone interested, i think we can help with basics but are busy enough to do it ourselves +[21:43:38] tampakrap: so could you sent it to dev-anounce and desktop mls? +[21:43:45] although i doubt there will be someone willing to do so much work for nothing +[21:43:47] I'm not interested in kdepim, so I won't be working on it +[21:44:05] yes, even blog the whole kdepim problem in trunk +[21:44:34] and thus i'm against providing the snapshots ( alexxy ) yet +[21:45:02] yeah no snapshot until .70 as with 4.4 should be done +[21:45:16] *** Joins: Civil (~Civilian@95-27-138-158.broadband.corbina.ru) +[21:45:16] .85 I would say even :P +[21:45:21] haha +[21:45:25] no =) +[21:45:27] .70 +[21:45:28] .70 is enough for ricers :D +[21:45:28] beta 1 :P +[21:45:30] 4.5.1? :P +[21:45:33] aka alpha0 +[21:45:34] =) +[21:45:36] btw, word of warning +[21:45:45] when kmail is ready i'd say +[21:45:52] dev.ge.o will migrate to new hardware soon, so expect a day or two of confusion +[21:46:02] thats good to know :] +[21:46:07] thanks patrick +[21:46:33] ok i think we should get back on track with topic one :] +[21:46:38] i think we are ready on this (btw i'm writing summary as soon as we speak) +[21:46:55] so we dont jump over those carefully written numbered topics in chaotic order :] +[21:47:08] ok back to topic one: new leader elections +[21:47:26] candidates: jmbsvicetto, scarabeus, plz vote (devs only) +[21:47:28] bring it on! +[21:47:48] I vote yes ;) +[21:47:52] DrEeevil: you cant +[21:47:53] pick +[21:47:55] i vote scarabeus (sorry jorge :) ) +[21:48:11] DrEeevil: :P +[21:48:12] I'd like to hear manifesto from both! ;) +[21:48:17] * reavertm runs +[21:48:22] lol +[21:48:23] tampakrap: no hurt feelings ;) +[21:48:45] not to break kde and keep it working for everyone of us :] and provide my qa tools for kde +[21:48:49] i vote for scarabeus =) +[21:48:53] scarabeus: nothing prevents us from having more than one lead, but let people choose +[21:48:58] note that this manifesto wont change for me if not voted for :] +[21:49:03] hmm +[21:49:09] what qa tools? +[21:49:11] or lets have two leads +[21:49:12] =) +[21:49:20] if its possible +[21:49:22] i have quite few scripts that checks x11 state +[21:49:25] i like that idea too +[21:49:26] no, just one to rule them all :) +[21:49:32] and i can adjust it for kde +[21:49:38] no, one leader is enough +[21:49:39] which i plan for month or so already :D +[21:49:42] we are a large herd +[21:50:00] actualy multiple leads are weird, just pick guys +[21:50:08] it does not matter to jorge or me who wins :] +[21:50:16] we just comply to the 1 year election rule :] +[21:50:21] how many members with voting power are here? +[21:50:33] lets vote and find out +[21:50:34] ;p +[21:50:39] 9 +[21:50:56] sorry 10 +[21:51:12] what about 5:5 ? +[21:51:22] reavertm: that would not amuse me +[21:51:36] ok, let's hear it +[21:51:47] in case 5:5 i'll change my vote :P +[21:51:47] * ABCD votes scarabeus +[21:51:55] * reavertm votes scarabeus +[21:51:56] * alexxy votes scarabeus +[21:52:03] scarabeus: I'll break the tie ;) +[21:52:03] * tampakrap votes scarabeus +[21:52:11] * wired votes scarabeus +[21:52:14] * spatz votes scarabeus +[21:52:15] * jmbsvicetto votes in scarabeus +[21:52:20] lol +[21:52:23] ok ok ok +[21:52:23] nice +[21:52:25] i get it +[21:52:38] like it or not you're lead +[21:52:38] :p +[21:52:39] * scarabeus votes for jmbsvicetto :] +[21:52:39] congrats now abuse your powah :P +[21:52:40] I said before I would prefer to have someone else being lead ;) +[21:52:47] scarabeus: No!!!! :P +[21:52:48] * wired remembered +[21:53:04] Congratulations Tomas +[21:53:13] scarabeus: \o/ congrats :) +[21:53:22] Now everyone i guess we should drink something good in favor of our good benevolent now-ex lead. So on Jorge :] +[21:53:38] and thanks, lets i will try to not doom us all :] +[21:53:59] * wired has a beer open =] +[21:54:05] * scarabeus too +[21:55:02] ok little girls you played enough for today, now let's move on +[21:55:15] Review work flow for KDE minor bumps and improve collaboration with arch teams +[21:55:48] 1) BUG +[21:55:48] 2) keywordlist +[21:55:48] 3) portage addition +[21:55:48] 4) profiles touching +[21:56:00] this should be workflow from now-on so we dont touch anyones toes +[21:56:13] scarabeus: The Founder Power has been bestowed on you for #gentoo-kde ;) +[21:56:22] * ssuominen votes scarabeus +[21:56:28] abcd * gentoo/xml/htdocs/proj/en/desktop/kde/index.xml: We have a new lead! +[21:56:36] :P +[21:56:57] ssuominen: ha ha ha :D +[21:57:10] all cards have been played already ;) +[21:57:15] scarabeus: I propose something different +[21:57:31] jmbsvicetto: i just wrote this one after start with jer, and then i got distracted +[21:57:38] jmbsvicetto: how does your approach look? +[21:57:43] if its better just make it policy +[21:57:44] :] +[21:58:01] its once per 6 months, and it wont hurt to have written down somewhere in Documentation/ +[21:58:14] good idea, whatever we decide on this should be forwarded as a global policy +[21:58:23] scarabeus: 1) Ask arch teams to test new deps in the overlay. 2) If they don't want to use the overlay, try to add a snapshot or a early release masked in the tree and ask them to keyword it +[21:58:35] scarabeus: then your policy +[21:59:06] i don't like this approach +[21:59:18] well, your 3) would be done before, so it could be 3) unmask in the tree +[21:59:18] what if they do something stupid while using the overlay? +[21:59:56] tampakrap: I might not have been clear, I meant to let them try the ebuilds from there and for us to add their keyword +[22:00:07] tampakrap: I'm not giving commit access +[22:00:07] jmbsvicetto: sounds sane +[22:00:18] altho i dont think about that snapshot into main tree +[22:00:20] i was not clear +[22:00:26] deps can go if released +[22:00:28] but not the kde +[22:00:33] I don't like snapshots in tree either +[22:00:33] it is annoying 280 packages +[22:00:38] i meant what if they use other testing ebuilds while using the overlay? +[22:00:42] its 4 hours commit +[22:00:47] (even if those are kde deps just) +[22:00:58] scarabeus: The snapshot as a last resort if upstream doesn't have a release 2 weeks / 1 month before getting the new version in the tree +[22:01:27] but only for deps +[22:01:32] no touching of kde-base/ itself +[22:01:35] I'm only talking about new deps +[22:01:35] there is problem - we have no arch team members in kde team +[22:01:40] we have +[22:01:42] for amd +[22:01:43] :D +[22:01:48] only ssuominen, but we would need some for other archs +[22:01:58] me stable for amd64 from time to time +[22:02:00] i can keyword arm and mips +[22:02:01] =) +[22:02:09] scarabeus: It's 30 minutes if you commit at category level. +[22:02:38] Philantrop: i know, but i managed to clash 3x already with someone else :] +[22:02:42] if you commit in 10 threads then it takes about 5 minutes +[22:02:45] even when i announced it :D +[22:02:46] to commit whole kde +[22:02:54] and since keywording kde is quite a bottleneck .. kde dev (which clearly uses kde) could do it faster +[22:02:56] hmm i could thread bump tool indeed +[22:03:13] scarabeus: force commit and kick anyone interfering from the herd. That's what I did. :-> +[22:03:30] scarabeus: i added kde 4.4.0 in about 5-7 minutes to tree +[22:03:35] * ABCD is x86-linux and amd64-linux +[22:03:38] working with 10 threds +[22:03:48] *threads +[22:04:05] ok lets write out the rules on the Documentation +[22:04:09] and i will thread the bumptool +[22:04:11] its quite simple +[22:04:44] <- not a part of amd64, just have stable chroot for xfce/kde/xorg/base-system/media +[22:05:05] i also stable only when i have long night :D +[22:05:19] but people mostly dont complain if qa guys stable on archs they can test :] +[22:05:53] i would say this topic should be reviewed on next meeting with respective prepared documentation for approach in the overlay, anyone some additions? +[22:06:33] no problem in this, i just hope there will be something prepared until next meeting +[22:06:59] ok kde-4.3.5 then :] +[22:07:01] i think we can use lxc containers instead of chroots +[22:08:03] so we are waiting on archies only, are there any issues with it? +[22:08:35] what's advantage of lxc over chroot? +[22:08:49] (which I can boot to natively as well) +[22:08:58] it run separate system in separate namespace +[22:09:10] so its more closer to vms +[22:10:28] VM's +[22:10:29] =) +[22:10:38] ok back to topic +[22:10:46] so we are waiting on archies only, are there any issues with it? +[22:11:25] anyone? +[22:11:35] not that I've seen, as an archie :D +[22:11:55] ok next one +[22:12:03] *** Joins: aboow (house5@gateway/shell/bshellz.net/x-vhnffmhwlxzbhinj) +[22:12:05] tampakrap: won't be really online until in about 1 hour +[22:12:06] sitting in the train currently with shaky net +[22:12:24] just one addition, dont remove 4.3.4, just wipe out 4.3.3 and 4.3.4 in one step when 4.3.5 is ready :] +[22:12:34] if anyone gets remove ideas :P +[22:12:35] Sput: ok we can talk then +[22:12:51] kde 4.4 status +[22:12:51] s/anyone/alexxy/ +[22:12:59] * alexxy has remove idea of old kde's +[22:13:00] :) +[22:13:01] :D +[22:13:15] referring to kdepim: if we found a way to package the current 4.4 kdepim in a way that it works with -9999 (no idea, copying the ebuilds from 4.4 into some overlay and renaming them to -9999) that should be more or less easy +[22:13:21] as 4.4 kdepim is supposed to work with trunk kde +[22:14:22] Sput: we can talk about it later, the other members have already expressed their opinions and you are messing with the topics now :) +[22:14:34] back again to kde 4.4 +[22:14:46] any known problems? blockers? +[22:14:55] yeah it is slightly flaky +[22:14:57] archies =) +[22:15:02] i got few crashes in kwin and plasma +[22:15:24] also, congrats scarabeus :) +[22:15:25] few crashes in krunner and plasma +[22:15:27] me too, so i guess 4.4.1 will be the stable candidate +[22:15:30] also the virtuoso migration is not exactly funky working out of the box for some +[22:15:36] 4.4.1 or 4.4.2 +[22:15:41] 4.4.2 most likely +[22:15:42] we shall see after 4.4.1 release +[22:15:51] ok +[22:15:51] i would rather wait too +[22:15:58] judging from the past... +[22:15:59] anything else on 4.4? +[22:16:20] i guess not +[22:16:32] jmbsvicetto: amarok and mysql 5.1 status +[22:16:32] *** Joins: hwoarang (~mystical@gentoo/developer/hwoarang) +[22:16:49] poor Jorge +[22:17:03] oh wait, akonadi is indifferent... +[22:17:26] virtuoso migration failed for me +[22:17:31] amarok works with mysql 5.1 +[22:17:33] ok +[22:17:38] if it compiled with -FPIC +[22:17:42] so, amarok and mysql-5.1 +[22:18:01] Fortunately it's way better than I feared when I added it to the agenda +[22:18:32] The ebuilds have been updated and no one complained for the past 3 days(?) so it seems users are getting used to it ;) +[22:18:43] AIUI, amarok[-embedded] should work just fine - amarok[embedded] has the same problems with 5.1 that it did with 5.0 - namely, that we need a libmysqld.so again +[22:18:50] A few people are still following the bug, but we can live with it as is +[22:19:03] ABCD: exactly +[22:19:52] there's another quirk, preserved-libs will keep the libmysqld.so for those upgrading, which does allow amarok to work (it happened here), until we have an abi / api incompatible change +[22:20:32] that is for amarok to work with mysql-5.1 - but that might cause serious issues "sooner than later" +[22:20:56] in any case, I've resumed my work to get a working patch, so let's see if I can do this before we have to elect a new lead ;) +[22:21:31] :D +[22:21:40] thank you x-boss +[22:21:47] how about we stop supporting the embedded part :] +[22:21:51] and just force full amarok +[22:21:58] patch-- +[22:21:58] ? +[22:22:00] like akonadi does +[22:22:01] ^^!! +[22:22:08] let them have it! +[22:22:20] that should teach those bastards :P +[22:22:30] :D +[22:22:38] ok anything else? serious? +[22:22:42] ok lets go for koffice +[22:22:47] i guess i should answer that one +[22:22:59] problem with koffice is that expect graphic tools it is totaly unusable +[22:23:00] * reavertm fixed kword recently +[22:23:02] go on +[22:23:11] and it needs all deps reviewed and updated based on cmakelists +[22:23:36] i personaly use only krita and dont care about rest of the bunch so it needs some dedicated guy whom will actualy use the stuff +[22:23:49] i will take this one but i may need your help +[22:24:01] query still works :] +[22:24:19] *** Quits: aboow (house5@gateway/shell/bshellz.net/x-vhnffmhwlxzbhinj) (Disconnected by services) +[22:24:49] anything else? +[22:24:57] nop, nothing from me to add +[22:25:13] ok knetworkmanager +[22:25:19] scarabeus: no harm in keeping embedded for now +[22:25:25] jmbsvicetto: oky +[22:25:33] ok we need snapshot +[22:25:40] and monthly refreshed snapshot probably +[22:25:43] scarabeus: if I can get a patch for mysql, we can make it simple again +[22:25:45] knetworkmanager crashes plasma here, i didn't prepare a snapshot i just tested with live ebuild +[22:25:46] who is willing to take that one out :] +[22:25:59] tampakrap: well plasmoid can be disabled +[22:26:07] tampakrap: most people are interested in kcm module +[22:26:22] we need monthly refreshed snapshot from svn +[22:26:23] i didn't use the plasmoid +[22:26:31] only the system tray item +[22:26:35] the same thing +[22:26:39] sure +[22:26:40] kcm is in systemsettings +[22:26:45] tampakrap: is it working? +[22:26:53] kcm wasn't working though :) +[22:26:58] ok +[22:27:03] so anyone uses NM these days +[22:27:07] or are we all on wicd? +[22:27:16] i guess i didn't have time to test it since it was crashing +[22:27:43] i can prepare a snapshot but it will need a lot of testing and i'd prefer if someone with non-crashing results would do it +[22:27:58] i'm on openrc init scripts and wpa_gui +[22:28:18] *** Joins: jmrk_ (~jmrk@dslb-088-064-075-227.pools.arcor-ip.net) +[22:28:19] tampakrap: ok just add it masked to main tree +[22:28:25] and lets ask users for testing and feedback :] +[22:28:29] anyone else? no? +[22:28:50] good question, there is quite few more team members :P +[22:28:55] who is willing to do this one? :] +[22:29:36] ABCD / reavertm? +[22:29:51] there is also DrEeevil whom enjoy the user feedback anyway :D +[22:30:04] I don't use NM +[22:30:19] tampakrap: i got it +[22:30:22] tampakrap: coordinate with dagger +[22:30:28] tampakrap: afterall he is maintainer of NM +[22:30:34] ah yes +[22:30:39] ok next topic +[22:30:45] * reavertm does have static network +[22:31:14] the documentation is fine, i updated it about a month ago, if you all want can take a look and propose fixes +[22:31:19] two issues though: +[22:31:32] 1) jmbsvicetto promised to clean up the member list +[22:31:48] which will be probably my task now :/ +[22:32:01] 2) i have an open bug about xdm configuration which i don't like, i'd like your feedback +[22:32:09] i will sent mail to everyone who does not have 5 commits month into kde cat +[22:32:13] scarabeus: I sorted it asciibetically for you (except your name is at the top) :D +[22:32:34] ABCD: lovely, you earn the big plus point :P +[22:32:50] http://bugs.gentoo.org/attachment.cgi?id=220755&action=view +[22:33:08] scarabeus: also plz remove qt members they are still there +[22:33:34] tampakrap: yeah +[22:33:44] tampakrap: I'll talk to scarabeus about that +[22:33:46] a small note: i didn't add the usefull links in the guide as jmbsvicetto pointed as they are not that useful :P +[22:34:00] tampakrap: recommend dejavu and droid fonts for christ sake +[22:34:26] tampakrap: other than that you should point to x11 guide which should describe xdm config iirc +[22:34:39] cool +[22:34:43] i like that +[22:35:26] last point: i'm going to blog about kde3 removal and the kde-sunset existence, so that ppl will hopefully stop filling stupid kde3 bugs anymore +[22:35:38] its only gnu_andrew +[22:35:45] and he will fill them anyway just to annoy us +[22:36:05] heh +[22:36:07] i don't have to say anything else about the docs, just i am waiting for you to take a look plz +[22:36:24] remove kdeprefix from docs +[22:36:31] kde guide is way too red +[22:36:45] funny, i agree on that +[22:36:51] friendly 'notes' everywhere +[22:37:10] it's impossible to follow +[22:37:11] :D +[22:37:22] yeah just wipe out kdeprefix from docs is good idea +[22:37:34] about kde3 and kde-sunset, my opinion is that we did one thing wrong +[22:37:49] also maybe sets... +[22:37:56] my initial goal was never to make kde-sunset a "dumping ground" to be mastered by users alone +[22:38:01] info about sets - remove as well? +[22:38:14] reavertm: i think we can have a note about sets, but keep metas as the default option +[22:38:27] nah sets are weird +[22:38:31] they are bbd now +[22:38:32] jmbsvicetto: i'm sure everyone knows that, but you can't force devs to work on it :) +[22:38:39] jmbsvicetto: i'm still following the kde-sunset commits +[22:38:43] I'd rather have an overlay with commits just by devs and trusted committers (akin to sunrise) and another overlay with free access by users +[22:38:55] jmbsvicetto: well your idea assumes devs are interested +[22:38:59] but now it's too late, so we'll have to live with it as is +[22:38:59] jmbsvicetto: we have none of those +[22:39:00] :p +[22:39:15] * jmbsvicetto cries for sets +[22:39:34] jmbsvicetto: not in this implementation, sorry +[22:39:34] I know (devs and KDE3) +[22:39:55] ok, i guess we are done +[22:39:56] pretty much all gentoo devs have commit access to that overlay.. +[22:40:48] the following two topics are long time ideas i had +[22:40:54] drop prefixes from kde ebuilds (like kdeartwork etc) +[22:40:59] I use NM with the plasmoid and both work great +[22:41:01] trunk though. +[22:41:22] if anyone dares to remove the plasmoid from -9999 I will keel him +[22:41:23] :) +[22:41:23] tampakrap: things like kdebase-data... you think it should just be "emerge data"?! +[22:41:45] well no +[22:41:48] drop prefixes? no +[22:41:51] but for kdebase-startkde yes +[22:41:56] add prefixes? more likely :P +[22:41:58] or for the artwork ones +[22:42:01] please no another dev-haskell/ +[22:42:09] try emerge opengl or emerge x11 +[22:42:20] startkde makes sense +[22:42:20] or zlib for that matter +[22:42:23] or chromium :) +[22:42:29] same with emacs +[22:42:35] yeah i think it is not worth the gain +[22:43:11] whatever I try to install, it tells me that I need to choose between sam app-emacs/XXX and /XXX +[22:43:15] we dropped -plugin- from xfce-extra/'s for a long time, and I can tell you... it was, nothing but a pain +[22:43:29] tampakrap: oh, and kdeartwork-kscreensaver can't be "kscreensaver", because kde-base/kscreensaver is kdebase-workspace +[22:43:34] scarabeus: you wanted to add prefixes some time ago +[22:43:41] ok i got your point +[22:44:04] to have module precede package name - like kdegames-sth +[22:44:22] reavertm: i thought of it bit more, and it would just take too much time :] +[22:44:22] reavertm: it's the same i guess, too much pain, doesn't worth it +[22:44:29] so that one can easily know what module is this withour reading ebuild +[22:44:41] grep KMMODULE is simple :D +[22:44:47] or KMNAME +[22:44:48] :] +[22:44:53] yest, misleading +[22:44:55] well, i don't want to emerge kdepim-kmail +[22:45:04] module = kdepim, not subdir in kdepim +[22:45:20] KMMODULE is a bit unfortunate name... +[22:45:39] never mind +[22:45:43] indeed, sadly i dont want to redesing the eclass again :D +[22:45:52] reavertm: i bet you dont want either +[22:45:52] we have one convention already +[22:46:01] we all agreed i guess not to touch anything +[22:46:06] next? +[22:46:21] for those that are in multiple module, we have plasma-apps, plasma-workspace, plasma-runtime +[22:46:25] same with solid- +[22:46:35] let's just keep it when needed +[22:46:40] change kde-meta (and @kde-*) to include all modules (plus the developer specific ones) +[22:46:44] reavertm: sure +[22:46:52] i dont get what are you proposing with this topic :P +[22:47:08] it should include even kdesdk? +[22:47:11] thats baad idea +[22:47:24] 99% of users dont want it +[22:47:31] they just emerge kde-meta cause they are lazy +[22:47:45] that's what i'm proposing yes +[22:47:54] -1 +[22:48:07] and how is kdewebdev more useful? +[22:48:23] on the other hand, we don't get bugreports for them because nobody is using this +[22:48:25] how about a developer something flag? +[22:48:33] exactly! +[22:48:43] (less bugs -> more fun) +[22:48:53] hm tampakrap useflag would be bad, not supported on sets right? +[22:49:00] sorry -1 from me +[22:49:00] tampakrap: developer useflag could work on meta +[22:49:03] but what for sets +[22:49:06] its baad idea +[22:49:15] if user wants it he can merge kdesdk-meta +[22:49:19] or kdewebdev-meta +[22:49:29] kdewebdev is already in kde-meta +[22:49:41] introduce a new set? kde-lazy? :p +[22:49:47] kde-meta shouldn't be used by users +[22:49:53] why? +[22:49:59] at least i think sets should include them all +[22:50:01] +1 for tampakrap's proposal, we should have everything in there. +[22:50:11] i except kde-meta to install everything +[22:50:32] expect* +[22:50:33] wired: I hope you "expect", not "except" :D +[22:50:39] expect gr +[22:50:43] for me kde-meta is http://websvn.kde.org/trunk/KDE/ +[22:50:54] a "recommended" USE flag could be introduced to skip stuff not needed by users +[22:50:55] ABCD: he uses qt with the "exceptions" use flag ;) +[22:51:10] kdeexamples O_o? +[22:51:23] if you add the kdebindings stuff to kde-meta, I'm sure we'll get a few interesting bug reports ;) +[22:51:44] (wom 96 +[22:52:01] ok then, i'll rephrase: how about a developer something use flag in metas and include everything in sets? +[22:52:10] we can have kdefull-meta +[22:52:13] or somethingl ike +[22:52:14] at least for sets it makes sence, users can create their own +[22:52:17] kde-burnmycomputer +[22:52:27] but not kde-meta +[22:52:35] it is full blown working kde desktop +[22:52:37] not full kde +[22:52:44] i still prefer the use flag idea +[22:52:57] lets discuss this on alias +[22:53:06] well, we can have kde-meta installa all, but advice to use kdebase-meta instead +[22:53:08] in gentoo-desktop +[22:53:14] or that +[22:53:23] but there will be duncan +[22:53:24] ok let's discuss it in the mailing list, i'll start the thread +[22:53:28] and who is going to read that :D +[22:53:32] i won't +[22:53:36] i have work to do +[22:53:43] you know +[22:53:52] gmail used to automatically clasify duncan as spam +[22:54:12] cool next topic +[22:54:14] 13 - stabilization of misc kde apps +[22:54:17] :P +[22:54:25] qa scripts can help with that +[22:54:27] wired promised a script :) +[22:54:32] for qt also +[22:54:34] but we have quite too much packages +[22:54:39] in kde +[22:54:43] it takes some time to compute +[22:54:43] L:D +[22:54:48] oioi i had to do that for kde as well ^_^ +[22:54:57] wired: okey your job :P +[22:55:01] ok i'll repromise to the new lead as well +[22:55:03] show us cookies on next meeting :D +[22:55:06] i have a todo file now! +[22:55:08] :P +[22:55:11] next week plz +[22:55:13] max +[22:55:20] scarabeus: kick him please :D +[22:55:26] last topic shut up +[22:55:28] 14 - patches of kde-packager +[22:55:57] i was kinda busy with exams last month i was not following the ml +[22:56:08] reavertm maybe knows anything? +[22:56:19] ABCD is suposed to apply kde-packager patches +[22:56:22] or jmbsvicetto i think he brought up the subject +[22:56:28] as was decided on one of the former meetings +[22:56:42] well, there are some and they need to be applied as they appear.... +[22:57:00] yeah, there have been a few patches sent to the packagers ml that didn't go applied +[22:57:00] ABCD: will you handle it? +[22:57:12] I lag here a bit (also due to limited time recently) +[22:57:14] anyone else willing to help on this? +[22:57:15] I think there are 3 for 4.4 by now +[22:57:26] I hadn't be able to get on the list until very recently, so I haven't seen those patches yet +[22:57:50] i am qute busy in x11 tracking so i cant do such pernament task for kde sadly :/ +[22:57:53] ABCD: I thought I had asked for everyone to be put in the ml +[22:58:18] I'll try to follow the ml +[22:58:29] ok, jmbsvicetto / ABCD will you handle this? +[22:58:34] in the least I can open a bug with the patch / patch link +[22:58:42] sure that too +[22:59:15] scarabeus should be able to add new people to the ml, but in any case I can always poke rdeiter and the kde infra team to get it done +[22:59:22] I'll look into it too +[22:59:28] great +[22:59:39] alexxy: what did you want to talk about? +[22:59:46] jmbsvicetto: thx for the hint, be sure i will ask anything i would not know how to do :] +[22:59:58] scarabeus: any time you need +[23:00:26] alexxy: ping +[23:00:47] i have 1 thing: we need another kde HT lead, i cant do herd testers lately due to limited time, and it would be sad if we loose that nice recruit count, dont you think? +[23:00:52] anyone wants to pick that one up? +[23:01:38] which are the requirements? +[23:02:00] tampakrap: be on irc, actively follow the new recruits and help them +[23:02:03] and motivate them +[23:02:09] like devrel said, a few children and 'mature' attitude ;) +[23:02:11] come on you saw me in action as one of the closest +[23:02:18] you know what i did :] +[23:02:23] ok i'm not good at it +[23:02:39] *** Quits: willikins (~rbot@gentoo/bot/Willikins) (Read error: Operation timed out) +[23:02:51] i tend to insult ppl like wired three times per day before food +[23:03:14] good training is actualy teaching :] +[23:03:29] ok we keep it as-is and i will anounce on alias :] +[23:03:40] reavertm: I'm on devrel ;) +[23:03:47] tampakrap: pong +[23:03:48] =) +[23:03:57] alexxy: topics you wanted to discuss? +[23:04:00] ok /me has to disappear +[23:04:02] so have fun +[23:04:03] make it quick plz +[23:04:06] and dont break a shit +[23:04:07] :D +[23:04:11] reavertm: I guess I'm "old enough" at least ;) +[23:04:16] hehe +[23:04:18] seems we already discussed them all +[23:04:19] =) +[23:04:24] cool +[23:04:27] meeting closed +[23:04:32] i'll prepare the summary +[23:04:32] yep +[23:04:52] it was cool to moderate you all, next time don't bring your dolls plz +[23:05:55] * tampakrap joke fail +[23:05:59] dolls? I didn't knew I had to bring mine!! +[23:06:51] o_O +[23:12:24] *** Quits: reavertm (~quassel@gentoo/developer/reavertm) (Remote host closed the connection) +[23:15:20] *** Joins: reavertm (~quassel@bsb151.neoplus.adsl.tpnet.pl) +[23:15:21] *** Quits: reavertm (~quassel@bsb151.neoplus.adsl.tpnet.pl) (Changing host) +[23:15:21] *** Joins: reavertm (~quassel@gentoo/developer/reavertm) +[23:22:53] *** Parts: spatz (~spatz@gentoo/developer/spatz) +[23:23:37] reavertm: ping +[23:23:59] hmm? +[23:24:23] sorry for doing this, yngwin requested to add to topics the desktop profile split but i failed to push :P +[23:24:45] is there anything we should discuss (in ml i guess) or can we proceed on this? +[23:24:53] no, please do +[23:25:14] we voted on this already, no? +[23:25:19] yes +[23:28:02] *** Quits: jmrk_ (~jmrk@dslb-088-064-075-227.pools.arcor-ip.net) (Quit: Konversation terminated!) +[23:35:05] tampakrap: does this mean it is going to be implemented now, or? +[23:35:13] yes +[23:35:19] i will do it +[23:35:22] ok, tnx +[23:35:27] i 'll write it in summary too +[23:35:34] so you can have proof :) +[23:35:36] good :) +[23:36:02] otherwise i will just remove the ridiculous mysql requirement from desktop profile myself ;) +[23:36:04] sorry for not bringing this up, i thought i pushed it diff --git a/meeting-logs/kde-qt-projects-meeting-log-20091119.log b/meeting-logs/kde-qt-projects-meeting-log-20091119.log deleted file mode 100644 index 7f1c17b..0000000 --- a/meeting-logs/kde-qt-projects-meeting-log-20091119.log +++ /dev/null @@ -1,959 +0,0 @@ -[20:45:05] toum toum -[20:46:51] sssh -[20:48:34] *** scarabeus changes topic to 'KDE Team meeting 19.11. 19:00 UTC: Topic 1: Upstream split packages (per kde-scm-interest mail i told you to read)' -[20:52:39] *** Joins: zizo (n=Zizo@host214-182-dynamic.4-87-r.retail.telecomitalia.it) -[20:52:59] *** Parts: zizo (n=Zizo@host214-182-dynamic.4-87-r.retail.telecomitalia.it) -[20:56:35] *** Joins: PSYCHO___ (n=scarabeu@gentoo/developer/scarabeus) -[20:56:35] *** ChanServ sets mode: +o PSYCHO___ -[20:57:05] darn 3g con -[20:59:38] so... meeting time? :) -[21:01:16] yup -[21:01:19] indeed -[21:01:27] anyone can record the histroy? -[21:01:38] i cant log, because quassel is not entirely cooperating right now -[21:01:39] * wired logging -[21:01:48] for the log <- scarabeus -[21:02:04] ok so lets start with rollcall -[21:02:05] even if I seem down my znc/bouncer will keep logging, im on a 3g connection right now (dsl is down) -[21:02:33] *** Joins: spatz (n=spatz@gentoo/developer/spatz) -[21:03:18] *** Joins: ayoy (n=ayoy@gentoo/developer/ayoy) -[21:03:39] *** Joins: mrpouet (n=quassel@gentoo/developer/mrpouet) -[21:03:45] ok so anyone else here? -[21:04:02] *** Joins: wohnout (n=wohnout@88.86.113.238) -[21:04:02] me -[21:04:09] you are so lame -[21:04:11] me -[21:04:12] !herd kde -[21:04:13] (kde) abcd, alexxy, carlo, cryos, dagger, deathwing00, jmbsvicetto, keytoaster, lxnay, mrpouet, patrick, scarabeus, spatz, sping, ssuominen, tampakrap, tgurr, wired -[21:04:13] * wired here -[21:04:13] and me -[21:04:17] !herd qt -[21:04:18] (qt) abcd, ayoy, carlo, hwoarang, spatz, tampakrap, wired, yngwin -[21:04:18] PSYCHO___: stop talking and start working -[21:04:19] roll call -[21:04:22] present -[21:04:22] :D -[21:04:24] I'm here -[21:04:27] HERE -[21:04:46] only qt people -[21:04:52] spatz: it is required only to say it once -[21:04:53] mostly present -[21:04:58] while(1) printf("HERE\n"); :D -[21:05:03] PSYCHO___: here :D -[21:05:04] okay ==> [ ] -[21:05:34] some get kde 3.5 killer... errr.... ssuominen here as well! :P -[21:05:43] ok thats not exactly attendance i expected -[21:06:10] scarabeus: lets wait at least 5 more minutes -[21:06:42] im also worried that some people might show up in an hour or so... -[21:06:46] ok -[21:06:59] because of DST? -[21:07:04] *** Joins: Sput (n=sputnick@quassel/developer/sput) -[21:07:04] yeah -[21:07:15] happened last time -[21:07:23] they can use date -u -[21:07:29] so thats not exactly excuse -[21:07:45] no'ones trying to excuse them -[21:07:47] dst stinks -[21:07:47] :P -[21:07:56] * spatz uses date -u -[21:09:17] so? -[21:09:28] so -[21:09:28] agenda? -[21:09:30] time's up, lets go! -[21:09:42] yngwin: agenda is on -desktop-ml in that mails -[21:09:43] scarb has first item @ /topic -[21:10:00] i will put them onto the topic as we will be going -[21:10:03] thats scattered -[21:10:22] * wired fixes agenda -[21:12:07] ok -[21:12:09] agenda: http://dpaste.com/122485/ -[21:12:30] thanks -[21:12:32] read it while i clean it up a bit -[21:13:00] what about starting from Qt since KDE has a lot to talk about? -[21:13:52] Ingmar: btw are you around? -[21:14:14] updated agenda: http://dpaste.com/122486/ -[21:14:36] ok lets roll -[21:14:51] 21.15 already -[21:14:58] true -[21:15:03] PSYCHO___: are you presiding? -[21:16:02] ok so lets start -[21:16:06] i was smashing my net a bit -[21:16:48] internet has swine flu -[21:17:26] yeah looks so -[21:17:29] * wired whistles -[21:17:36] !herd kde -[21:17:37] PSYCHO___: (kde) abcd, alexxy, carlo, cryos, dagger, deathwing00, jmbsvicetto, keytoaster, lxnay, mrpouet, patrick, scarabeus, spatz, sping, ssuominen, tampakrap, tgurr, wired -[21:17:38] aarfff dinner time :( -[21:17:42] so listen up -[21:18:08] anyone of you did read that mail from Ingmar? or you just idled like usual? -[21:18:21] yes we did -[21:18:22] * spatz read it -[21:18:25] * wired did read it -[21:18:27] i did -[21:18:36] http://article.gmane.org/gmane.comp.kde.scm-interest/724 -[21:18:46] there is my response to that mail thread -[21:19:06] give us a min to read -[21:19:08] it is how i imagine layout that would suit us packagesr best -[21:20:29] *** Joins: j0 (n=quassel@g227216073.adsl.alicedsl.de) -[21:20:29] anyway the question that waits here: "Is anyone willing to work on this?" -[21:21:15] yes -[21:21:26] did you get any response from upstream? -[21:21:33] nope, this mail is last in that thread -[21:22:16] so we are waiting until upstream responds to that first, or not? -[21:22:39] actualy nope, i expect someone coordinate with ingmar and prepare full proposal to them -[21:22:55] because my 6 lines about layout are not exactly "full proposal" -[21:23:00] upstream surely knew we have split kde -[21:23:11] yes they do -[21:23:12] the real question is, do they really want to take this route? -[21:23:40] well some stated that they would like it, some otherwise -[21:23:48] i've also seen discussions about splitting in the past going nowhere (two at least) but never mind -[21:24:10] well this time they are migrating to another SCM so it might have better chance to win :] -[21:24:18] agreed -[21:24:42] does Ingmar (ping) have anything else to say in this topic? (apart from what you said in the mail?) -[21:25:19] well he is aparently not around, so the interested person will have to mail him or irc him at some better time -[21:25:30] do binary distros (pretty much everybody) have split packages or monolithic ones? -[21:25:46] debian has them split -[21:25:52] after compilation tho -[21:25:56] hello -[21:26:05] they compile them in monolithic way and ship them in split way -[21:26:08] hey Ingmar -[21:26:09] scarabeus, tampakrap hi -[21:26:18] hello -[21:26:54] doesn't matter how they do it, only whether they do it. if this change forces everybody to split their packages whereas now they have monolithic ones we might face some opposition -[21:26:56] scarabeus: as you said, i'd like to see upstream move to a buildsystem layout more similar to what xorg has -[21:27:19] scarabeus: i'm less interested in splitting out the libs, or base, but the debian packager i talked to found that more important than anything else -[21:27:34] spatz: other distros follow upstream's way, so they will be forced to change it -[21:27:36] presumably because they can easily split the rest after buil -[21:27:39] d -[21:27:45] s/can/can & already do/ -[21:28:21] well from what we can say the initiative to do the thing will have to cover 2 areas) explaining what to do and how ) showing some example repo done that way -[21:29:04] yeah -[21:30:04] so ANY volunteers for this? -[21:30:09] yes -[21:30:21] and you? -[21:30:29] Ingmar: also i would like to see at least one relevant upstream guy acking that we are not just wasting our time -[21:30:30] I am, obviously :) -[21:31:01] well, let's start with a proof of concept for one module -[21:31:04] i myself will try to help -[21:31:48] i'd put together a proof of cencept first & see what they say on the relevant mailinglists -[21:32:01] ok that sounds reasonable -[21:32:12] splitting kdenetwork or kdeedu might be quite easy -[21:32:24] Ingmar: did you get any affirmative responses from other packagers (and more importantly) by any upstream developer? -[21:32:51] scarabeus: i was thinking kdenetworok, so yeah :) -[21:33:09] tampakrap: packagers yes (debian & gentoo, didn't ask anyone else), didn't ask any specific upstream devs -[21:33:20] ok -[21:33:33] Ingmar: also we should steal some irc channel to have it covered, i guess we cant chit-chat on g-kde or e-kde since its bit offtopic :] -[21:33:36] on the kde-scm-interest ml, some were in favor, and some where against -[21:34:16] any name ideas? :] -[21:34:39] #kde-split -[21:34:41] /j #kde-build-split :) -[21:34:48] ok -[21:35:01] *** Parts: wohnout (n=wohnout@88.86.113.238) -[21:35:23] anything else on the subject? -[21:35:36] i would say that for meeting we covered it -[21:35:46] i personaly will try to motivate few more people -[21:35:52] but that is non-meeting subject :] -[21:36:03] Ingmar: apart from kde-scn-interest ml, any other mailing lists you'd like to see us subscribed? -[21:36:55] kde-buildsystem -[21:37:08] well, if you have more minions, you know where to send them :) -[21:37:20] okz -[21:37:41] ok i think we're done with this for now -[21:37:48] next topic plz? -[21:37:54] first topic plz :) -[21:37:55] tampakrap: now something qt i would say -[21:38:00] since there is more qters -[21:38:09] scarabeus: lets just do the agenda?! -[21:38:27] as you wish -[21:38:33] ok documentation -[21:38:41] *** scarabeus changes topic to 'KDE Team meeting 19.11. 19:00 UTC: Topic 1: Documentation' -[21:38:43] stabilization first -[21:38:44] *** scarabeus changes topic to 'KDE Team meeting 19.11. 19:00 UTC: Topic 2: Documentation' -[21:38:54] http://dpaste.com/122486/ -[21:38:56] *** scarabeus changes topic to 'KDE Team meeting 19.11. 19:00 UTC: Topic 1: stabilisation' -[21:39:35] ok so since only samuli is working on it with me has anyone looked on the bug -[21:39:43] or attempted to fix blocker bugs -[21:40:04] bug # plz? -[21:40:15] * wired hasn't looked at kde 4.3.3 bugs lately, but will -[21:40:25] bgu 292455 -[21:40:26] bug 292455 -[21:40:28] spatz: https://bugs.gentoo.org/292455 "KDE 4.3.3 stabilization request"; Gentoo Linux, Applications; NEW; ssuominen@g.o:kde@g.o -[21:40:41] bug 2: Documentation -[21:40:43] erm -[21:40:43] PSYCHO___: https://bugs.gentoo.org/2 "How do I attach an ebuild."; Gentoo Linux, Ebuilds; RESO, FIXE; tneidt@fidnet.com:hallski@g.o -[21:40:45] damn this -[21:40:49] as spatz said -[21:40:51] lolz -[21:41:02] lol -[21:41:28] so 13 bugs -[21:41:47] i can try to help this weekend -[21:41:50] i want each member of kde team to fix at least 1 -[21:42:28] 12 bugs, 3 stable req and 1 keyword req -[21:42:29] also i want someone to look on current open bugs -[21:42:40] and decide which should be blocking the stabling -[21:42:50] and on this i want volunteer that will actualy do it -[21:43:05] and also close the remaining kde3 bugz -[21:43:13] we can't really do much with keyword/stable requests -[21:43:43] are still there are normal bugs, and not all bugs are now blocking the stabilisation even if they should -[21:43:47] so who will do it -[21:45:13] ok i'll do it since noone is interested -[21:45:19] meaning the bug wrangling -[21:46:11] *** PSYCHO___ changes topic to 'KDE Team meeting 19.11. 19:00 UTC: Topic 2: documentation' -[21:46:12] ok -[21:46:19] next topic -[21:46:41] as i stated -[21:46:54] I want devoted person focusing on updating our documentation with nedy -[21:47:02] as wired I can try to help this week end (I've an exam tomorrow and I've to finish a project) -[21:47:04] yes but i disagree with that -[21:47:45] tampakrap: so how would you do the documetnation -[21:47:53] everyone of us should just realize that documentation is *VERY* important and write two words before a major update or whatever -[21:48:01] apart from that i have another idea that you may like -[21:48:31] *** Joins: ssuominen (n=ssuomine@gentoo/developer/ssuominen) -[21:48:38] speak up :] -[21:48:43] since guidexml requires gorg in order to have a fully rendered (human readable) doc -[21:49:15] i have created an svn repo in my home server that checks out through a hook to a gorg-accessible path -[21:49:22] so it can be read immediatelly -[21:49:48] i can give access to the team here to my home server so we can *ALL* (and i mean ALL, even HTs) develop the guide -[21:49:56] no excuses about permissions etc -[21:50:13] unless you can provide us such a hook, since you have access in overlays.g.o -[21:50:14] well that was done even on git server remember -[21:50:16] I agree, so +1 -[21:50:27] i wrote complete guide in overlay as non-dev -[21:50:59] yes but i'm talking about an immediate co to an xml gentoo.org-like site -[21:51:17] which makes things easier -[21:51:25] this once again shows the shortcomings of guidexml -[21:51:42] well ok -[21:51:48] tampakrap: you then write up something and enforce it -[21:52:01] well, i don't agree with that, it shows that noone cares about docs which is sad -[21:52:38] come on, i just stated something, we can proceed in voting i guess, or go in your way then -[21:53:20] well i am willing to use it, problem is that noone else will edit it, its the same problem as is now -[21:53:36] we can give it a shot -[21:53:37] we can keep those guides in our public_html folders to see it right-away -[21:53:39] until next meeting -[21:53:42] but noone edit it anyway -[21:53:50] that's not the same -[21:53:56] but we should *also* have someone in charge -[21:54:18] well i wanted someone in charge -[21:54:22] so he can say -[21:54:26] that someone would check other commits and will _in_time_ get closer to the docs team -[21:54:30] sorry I'm late; I forgot about the time change :( -[21:54:31] i could be in charge of docs since i am the main editor a while now, but i don't like this idea -[21:54:36] You XY wrote module for AB but did not document it, so do it now. -[21:55:12] so actualy devs introducing something new will be somehow forced to do the docs -[21:55:38] because "anyone does docs and we are happy" simply is NOT working -[21:55:43] the problem is that we don't update the docs BEFORE the change (minor or major) -[21:56:31] well that would be responsibility of doc master, to point when and what needs to be changed -[21:56:35] and that won't change by itself, even if we could write the docs in speech-to-text app -[21:57:22] i dont expect the lead to do the work, but delegate to other devs, and if those wont document, i am even willing to remove them from team -[21:57:31] okay i could do that but i'd expect from the members to respect more the documentation part -[21:58:31] okay if noone has a problem with that then i'll take charge of this position -[21:58:40] *** Quits: ayoy (n=ayoy@gentoo/developer/ayoy) (Remote closed the connection) -[21:58:52] tampakrap++ -[21:58:53] *** Joins: ayoy (n=ayoy@cs78245237.pp.htv.fi) -[21:58:53] ok -[21:59:06] i'll also introduce my system to gentoo-desktop mailing list (i hope devs+HT's are subscribed there) -[21:59:09] PSYCHO___: huh ? remove them from team ? for that ? (I agree document is an important thing does not matter) ... but blame them instead -[21:59:23] while we're on the docs subject, note that I'm taking care of Qt docs -[21:59:27] *** PSYCHO___ changes topic to 'KDE Team meeting 19.11. 19:00 UTC: Topic 3: upstream coordination' -[21:59:32] mrpouet: it is even more important that coding -[21:59:42] just recall what hapened when we masked kdeprefix -[21:59:46] I meant it's a bit....excessive -[21:59:51] mrpouet: its seriously important for users -[21:59:56] mrpouet: and we present our work to users -[22:00:00] tampakrap: I said that I was agree :] -[22:00:02] mrpouet: we need to be 100% covered there -[22:00:22] (document is important) but the consequence is.... excessive imho -[22:00:41] mrpouet: now noone cared, so i will be really evil until they start to care -[22:00:52] well -[22:00:55] i must say -[22:01:04] docs have always been one huge strength of gentoo -[22:01:08] *** Joins: Pesa (n=Pesa@bluemchen.kde.org) -[22:01:13] and lately they're degrading fast -[22:01:15] PSYCHO___: sadistic :P -[22:01:17] so I like this initiative -[22:01:29] lets bring them back :) -[22:01:42] hello :) -[22:01:49] ok so lets loko onto the next toppic -[22:01:51] second late to the party -[22:01:57] :D -[22:02:01] as i can see some people had really the problem with TZ -[22:02:02] :D -[22:02:05] Pesa: hi :) -[22:02:12] Pesa: or you know that you are 1h late? :P -[22:02:17] uhm... -[22:02:20] 1h :O -[22:02:25] he does not -[22:02:27] date -u -[22:02:29] Pesa: ^^ -[22:02:32] damn! timezone :s -[22:02:43] Pesa: I had the same issue :D -[22:02:43] sorry -[22:02:50] ok so lets get to the topic :] -[22:02:56] you'll read logs, lets go! -[22:03:09] who is willing to track upstream patches, and apply them where required -[22:03:10] yep -[22:03:30] wired: or do like me, have a linux clock setting up to UTC :D -[22:03:43] this requires also requesting backports from TRUNK to branch on upstream -[22:04:50] PSYCHO___: you meant a unique guy ? other devs can't import patches from upstream ? -[22:05:03] (it's ambigous) -[22:05:11] they can, but should coordinate with him -[22:05:14] (at least for me with my fuc*$*$$* english) -[22:05:16] it can be even more people -[22:05:29] the point is that we would have the patches applied where needed -[22:05:34] in both overlay/tree -[22:05:57] PSYCHO___: mhhh... personally I could be interested -[22:06:01] Hello -[22:06:05] boss! -[22:06:06] sorry for being late -[22:06:08] jmbsvicetto: hi -[22:06:09] :) -[22:06:09] currently we mostly wait on upstream to release new version -[22:06:11] welcome jmbsvicetto -[22:06:14] hello boss -[22:07:09] Hi everyone -[22:07:16] ok, come on guys, he is half gnome, at least one more volunteer ;] -[22:07:20] its not that hard job :] -[22:07:30] i could help but not that much -[22:07:36] because i am mostly trunk user -[22:08:00] PSYCHO___: what's up? -[22:08:08] :( -[22:08:10] PSYCHO___: it's not an argument :p -[22:08:16] jmbsvicetto: you want log so far? -[22:08:17] Am I 1 hour late?? :| -[22:08:18] i want someone to coordinate patches with upstream :] -[22:08:20] I'm half gnome... and ? :D -[22:08:21] someone dedicated :] -[22:08:22] jmbsvicetto: you are :P -[22:08:49] * jmbsvicetto failed to read UTC :\ -[22:09:05] wired: yes, please (logs) -[22:09:30] jmbsvicetto: ok i'll wgetpaste then hold on -[22:09:49] PSYCHO___: reavertm and ABCD would be perfect for this i guess -[22:09:49] ABCD: how about you? dont want to do this? :] -[22:10:02] tampakrap: exactly my thinking, but reaver is not around now -[22:10:47] the silence after i ask someone something :D hilarious -[22:11:12] PSYCHO___: that would mean I'd actually have to figure out if commits to trunk are relevant/apply on the 4.3 branch... -[22:11:22] (which means more work :( ) -[22:11:26] btw, after this topic, I've another one (tiny) -[22:12:00] trunk after .70 is 90% incompatible with current branch -[22:12:19] (I'm pretty sure you will agree, but I wanted to talk about that during meeting anyway) -[22:12:28] jmbsvicetto: http://dpaste.com/122503/ -[22:12:30] ABCD: i mean more watch what bugs they fix, and ask them to patch it for branch too -[22:13:02] something like "i know you fixed crash X for trunk, but the error is in branch too, so could you fix it too so others dont have to wait for 4 months?" -[22:13:05] wired: thanks -[22:13:28] and second responsibility would be just applying what users add to bugzilla as patches from upstream -[22:13:39] deciding if it is worth or not and so on -[22:13:45] PSYCHO___: so long as someone files a Gentoo bug, and mentions the upstream bug; otherwise I'd never find it :) -[22:13:48] i dont expect that person to review all commits -[22:13:59] ABCD: thats the idea :] -[22:14:09] i dont expect you to browse the upstream one ;] -[22:14:20] in that case, it shouldn't be too difficult -[22:14:58] i know, i just want someone to do it -[22:15:07] so i wont meet 20 days open bug with patch from upstream -[22:15:29] *** PSYCHO___ changes topic to 'KDE Team meeting 19.11. 19:00 UTC: Topic 4: kde3 removal' -[22:15:39] ssuominen: around? -[22:15:50] ok as you might noticed kde3 is going away -[22:15:56] next topic, ssuominen is in progress of it :P -[22:15:57] its quite flawless i can say -[22:16:04] * tampakrap points at #-commits -[22:16:09] http://dev.gentoo.org/~scarabeus/kde3almostgone.png -[22:16:09] wave your hands while you still can -[22:16:19] its going awayyyyyyyyyyyy -[22:16:19] this is what it did to our bugs -[22:16:27] so i want to hear one thing only here -[22:16:34] is something more required on that matter from us? -[22:17:17] nothing i can think of -[22:17:26] me neither -[22:17:30] ssuominen is really doing a great job with this -[22:17:31] thats why i wanted ask others -[22:17:40] bye-bye bugs :D -[22:17:57] wontfix closing is fast :P but dont get used to it :D -[22:18:10] :D -[22:18:20] lets go to RDEPENDs -[22:18:22] * tampakrap is waiting for kde5 - kde4-removal -[22:18:41] tampakrap: go ahead and write kde5 then! -[22:18:42] jmbsvicetto: boss its your area -[22:18:52] jmbsvicetto: so elaborate why rdepend use deps are bad -[22:19:30] *** Joins: pontecorvo (n=pontecor@93-183-229-187-dynamic.retail.datagroup.ua) -[22:19:36] okeey, anyone else? :] -[22:19:41] :P -[22:19:51] i personally like use flags for rdepends -[22:20:06] but i'd like to hear why they're bad from those who don't -[22:20:13] * PSYCHO___ dont care, einfo was always enough for me -[22:20:17] wired: well it is poluting the ebuild -[22:20:21] they are not entirely required -[22:20:27] its not pollution -[22:20:31] so einfo with install X for feature Y -[22:20:42] its only a few words and its helping you do things pre-emerge -[22:20:50] wired: if you stabilise package, it is polution, if you have to wait on optional rdepend to be stabilised -[22:21:07] in that case -[22:21:12] lets work on a per case basis -[22:21:41] for example, obvious or important rdepends could go in use flags, others in info -[22:21:46] that actualy might work -[22:22:33] if an rdepend disables/enables half the package's functionality, it should definately have a USE -[22:22:45] if its a hidden option in the 3rd menu from the right -[22:22:53] it could live without it :P -[22:22:56] *** Quits: pontecorvo (n=pontecor@93-183-229-187-dynamic.retail.datagroup.ua) (Remote closed the connection) -[22:23:35] but we *must* make sure we have einfo if we don't have USE -[22:23:36] make it policy -[22:23:41] thats sound sane -[22:24:05] agreed -[22:24:12] add to CODE maybe? -[22:24:15] yeah -[22:24:27] oh sorry -[22:24:30] *** Joins: pontecorvo (n=pontecor@93-183-229-187-dynamic.retail.datagroup.ua) -[22:24:30] yeah, *docs* man -[22:24:40] ok someone can grab it from summary later then -[22:24:41] :D -[22:24:41] :] -[22:24:41] sorry, reading backlog -[22:24:51] i would kick you now, but we are in meeting -[22:25:04] jmbsvicetto: not entirely smart thing to do during continuous meeting :D -[22:25:16] PSYCHO___: It isn't that rdepend use flags are bad, it's just that there are too many -[22:25:34] at least it used to be too many -> quanta was the best/worst(?) example -[22:25:53] yes, because we are following upstream -[22:26:24] jmbsvicetto: well thats why it is per decision basics -[22:26:33] svn plugin can be controled by svn useflag -[22:26:34] wired / PSYCHO___: I'm not sure they cause so many issues when marking it stable -[22:26:46] we can always have a use flag masked in a profile -[22:26:50] jmbsvicetto: I DO, i try to stable such package right now -[22:27:05] :P -[22:27:09] PSYCHO___: I was trying to catch something ;) -[22:27:16] i think what i said above is good as a rule of thumb -[22:27:43] devs should decide per case depending on the importance of the deps -[22:27:47] so we don't end up with 30 RDEPEND USE flags -[22:27:48] :p -[22:27:54] I don't have a problem with a case-by-case, but then we'll get a bug for each package that we don't provide a use flag :P -[22:28:18] wontfix, because that's how we want it -[22:28:34] or fix, because we did a second thought -[22:28:38] * jmbsvicetto puts user cloak: I want use flag X for installing package Z when I install package Y!!! -[22:28:46] http://www.pastebin.cz/26457 -[22:29:06] jmbsvicetto: we already have wontfix bugs like that -[22:29:08] Ingmar: I'll try to poke you later, but I'm also interested in upstream's work on splitting KDE -[22:29:11] its up to us, not user decision -[22:29:16] yes, I know -[22:30:28] ok, i guess we covered our last point -[22:30:34] so lets move to qt issues :] -[22:30:37] w8 -[22:30:39] wait plz -[22:30:49] mrpouet has sth to add -[22:31:04] hm? -[22:31:11] or had :P -[22:31:15] mrpouet: u here? -[22:31:21] i have to say something too -[22:31:36] tampakrap: then speak :] -[22:31:38] go ahead -[22:31:42] i'll start since mrpouet is somewhere else :P -[22:32:13] recently i fixed a bunch of live ebuilds, reported issues, patches etc -[22:33:07] since i recompile kde and qt live packages very frequently, i would like your permission to create a doc which will track live ebuilds' upstream and downstream bugs, etc -[22:33:15] which are broken and need love etc -[22:33:43] if you think that a doc is not appropriate i could do a page in gentoo-wiki for example -[22:34:11] tampakrap: go ahead, try to motivate some non-team people to help you -[22:34:18] tampakrap: so you can recruit your minions ;P -[22:34:30] on that note, we could create a script -[22:34:31] no way, you are the ht lead -[22:34:34] that picks up your daily rebuild -[22:34:44] and generates a webpage of what failed and what worked -[22:34:45] :p -[22:34:52] you mean something like dirk-dashboard? -[22:34:52] ;] -[22:34:57] contonuous integration -[22:34:57] or something like bump-tool? -[22:35:07] http://dev.gentoo.org/~scarabeus/vystup.html -[22:35:08] something like buildbot? -[22:35:27] a script that takes logs and uploads them somewhere -[22:35:29] something like that PSYCHO___ -[22:35:45] like the thing gnomies have -[22:35:49] tampakrap: well do it if you want it -[22:35:55] i can create a custom script if we don't have something ready -[22:36:03] we don't -[22:36:05] ok ok -[22:36:09] covered -[22:36:11] just give me the logs :P -[22:36:28] ok so lets moove to the qt since mrpouet is not around -[22:36:36] wait a minute -[22:36:47] it seems not covered -[22:37:06] wired: the script would be usuable if it could automatically take the build.logs from the failed packages -[22:37:11] and upload them somewhere -[22:37:33] tampakrap: its not entirely meeting material, and we have meeting already for 1h30minutes... just discuss this with wired on -kde afterwards :] -[22:37:33] yeah -[22:37:37] and we can add a comment next to each one of them, like upstream bug or whatever -[22:37:39] we'll talk about it off list -[22:37:43] off meeting* -[22:37:43] ok ok -[22:37:51] *** PSYCHO___ changes topic to 'KDE Team meeting 19.11. 19:00 UTC: Topic QT 1: qt mono package' -[22:37:58] !herd qt -[22:38:00] (qt) abcd, ayoy, carlo, hwoarang, spatz, tampakrap, wired, yngwin -[22:38:14] surprisingly i am here -[22:38:21] one of our biggest issues -[22:38:26] with the split ebuilds -[22:38:29] the USE flag madness -[22:38:31] is now solved -[22:38:38] because anything < 4.5.3 is off the tree -[22:38:41] \รถ/ -[22:38:41] lol, when? -[22:38:54] i still see people struggling with it -[22:39:03] because they are updating to 4.5.3, not? -[22:39:11] yes -[22:39:12] yay -[22:39:19] once they update, we're done with this shit -[22:39:29] so its solved from our side -[22:39:50] the only thing left is the Qt update blocker madness -[22:40:01] but i think people are beginning to understand that b blocks are autosolvable -[22:40:05] but we'll still have to support latecomers for a long time -[22:40:28] we'll have to support latecomers no matter what -[22:40:39] yngwin: agreed, but that doesn't really change anything if we merge splits into a monolithic -[22:40:45] s/anything// -[22:41:05] it would, but anyway -[22:41:28] i mean, they'd still have to do some migration work -[22:41:38] like update with no blockers -[22:41:40] :) -[22:42:06] yes, but that would be clearer than the current mess with blockers and useflags - portage is just not giving very clear feedback to users -[22:42:20] i agree with the feedback thing -[22:42:45] but with the useflags issue _mostly_ gone, do you feel the blockers are good enough a reason to change things? -[22:42:52] well, we could say that that's a portage bug ;) -[22:43:09] it is mostly a portage problem yes -[22:43:16] xorg packages, for example, don't have blockers for maximum versions, only minimal, so users see less blockers -[22:43:18] well portage should shut up about autosolved blocks -[22:43:20] but we'll have to work with portage -[22:43:29] i dont understand why it writes them out -[22:43:36] qt has both maximum and minimum version blockers and that's creating weird issues -[22:43:39] most users get only confused -[22:43:43] imo the right way to do this is fix portage -[22:43:58] i really want to get into portage development but i just can't these days -[22:44:01] *** Joins: tampakrap_ (n=tampakra@ppp-94-66-145-248.home.otenet.gr) -[22:44:01] why do we need maximum version blockers? -[22:44:04] i am considering doing so in the future -[22:44:16] downgrading Qt isn't really supported anyway -[22:44:31] Sput: you can't mix Qt versions -[22:44:35] Sput: to make sure user has exactly the same version of all packages -[22:44:35] Sput: mixing versions anyhow is neither -[22:44:36] period :P -[22:44:46] wired: i'd like to too ;) -[22:44:51] yes, but the common case is upgrade, yes? -[22:45:01] again, see xorg use case -[22:45:01] to my mind this shows why we need monolithic -[22:45:06] something like MDEPEND -[22:45:07] downgrading doesn't usually work either -[22:45:08] so minimum blockers would be enough to force all qt packages be updated if one is updated -[22:45:12] if package is around then require this version -[22:45:16] otherwise do not care -[22:45:18] so called -[22:45:22] MAGIC DEPENDENCY -[22:45:29] :) -[22:45:38] with only minimum blocks users won't get blockers -[22:45:49] come on its exactly what you want, that might be actualy easy to do with current code -[22:45:55] it will just need new eapi :/ -[22:46:24] PSYCHO___: current code can't do it, i've tried to express it with complex bash but it still shells out blockers -[22:46:27] we need new depend type -[22:46:30] anyway, we said we'd discuss it on ML, which as far as i can see has not happened -[22:46:43] it did not -[22:46:44] wired: i said so, new depend type MDEPEND -[22:46:49] PSYCHO___++ -[22:46:57] who wants to start the ML discussion? -[22:46:58] and it is easy to adjust -[22:47:00] the portage code -[22:47:04] about this -[22:47:13] yngwin: I can -[22:47:19] great -[22:47:22] next topic -[22:47:35] status of qt-tng -[22:47:42] *** PSYCHO___ changes topic to 'KDE Team meeting 19.11. 19:00 UTC: Topic QT 2: Status of new qt-tng.eclass' -[22:47:56] I've been reviewing it for last 1,5 hours -[22:47:59] hwoarang said he couldnt continue with this because of circumstances -[22:48:10] i think it's ready -[22:48:12] yes so are we happy with it enough to post it in -dev? -[22:48:26] provided that we remove prepare_translations? -[22:48:45] this one seems not so handy -[22:48:52] tries to address a common case -[22:48:58] let's prepare the eclass for qt@ before sending it off to -dev -[22:48:59] but the common case doesn't really exist -[22:49:06] except there isn't a common case :) -[22:49:14] so lets remove that -[22:49:21] I will -[22:49:23] yes, we already said that -[22:49:38] ok -[22:49:47] ok, ayoy, can you finalize the eclass and send it to qt@ ? -[22:49:47] hey, btw -[22:49:48] *** Quits: tampakrap (n=tuxicity@gentoo/developer/tampakrap) (Read error: 54 (Connection reset by peer)) -[22:49:56] yngwin: yes I can -[22:50:15] great -[22:50:18] then we can all have a look and comment if needed, then send it to -dev -[22:50:21] are we all happy with the eclass name? -[22:50:26] * ayoy is not -[22:50:29] not really -[22:50:36] ayoy: i talked with picard the other day, he said he liked it -[22:50:36] you already voted on it, but didnt decide anything -[22:50:39] i am not but i don't really care -[22:50:41] qt4-edge kicks testicals very hard, I like it -[22:50:51] not -edge -[22:50:54] we need that for overlay -[22:51:03] qt4v2 -[22:51:03] else we'll have to start overriding and crap -[22:51:11] wired: you mean that qt4-edge will stay in overlay? -[22:51:17] we need eclass versioning dammit -[22:51:26] yngwin++ -[22:51:31] ayoy: yes, we need to keep developing there, don't we? :P -[22:51:37] we do -[22:51:43] yngwin: indeed -[22:51:44] indeed, wired is right -[22:51:53] I propose qt4-next :/ -[22:51:58] qt42morow -[22:51:58] better :) -[22:52:03] qt4-v2 -[22:52:08] read it ^ -[22:52:10] qt4evar -[22:52:11] in english -[22:52:16] PSYCHO___: we did :P -[22:52:33] :] -[22:52:41] qt4-blesmrt -[22:52:42] :] -[22:52:43] qt4-r2 -[22:52:45] ok, let's not waste time on bikesheds -[22:52:50] ^^ in the gentoo spirit -[22:52:54] lol -[22:52:56] :) -[22:53:09] i like that, wired -[22:53:10] this meeting is already taking 2 hours :/ -[22:53:16] let's move on -[22:53:17] * spatz likes it too -[22:53:23] :D -[22:53:25] * ayoy too -[22:53:25] so name unchanged -[22:53:27] ? -[22:53:28] ok, qt4-r2.eclass -[22:53:30] no, changed -[22:53:41] next topic -[22:53:46] w00t, we got rid of startrek -[22:53:47] ok 3. -[22:53:50] #gentoo-qt -[22:53:52] do we want it? -[22:53:58] plz no -[22:54:01] no -[22:54:02] i dont see the need -[22:54:02] *** PSYCHO___ changes topic to 'KDE Team meeting 19.11. 19:00 UTC: Topic QT 3: #gentoo-qt' -[22:54:05] I'd say we rather need a separate meeting -[22:54:09] than a separate channel -[22:54:11] its already registered and when i was bored I added permissions -[22:54:18] so if you ever feel like it -[22:54:18] :) -[22:54:24] ok, but plz no -[22:54:26] :) -[22:54:47] i think -kde is fine as well, but its there if we need it -[22:54:50] ok, so we all agree on 'no' -[22:54:57] neeeext -[22:55:01] let's keep it -[22:55:01] ok, we have a backup for a nuclear war or sth -[22:55:06] *** PSYCHO___ changes topic to 'KDE Team meeting 19.11. 19:00 UTC: Topic QT 4: einfo mess' -[22:55:12] 4. -[22:55:13] but we'll continue to use -kde for the time being -[22:55:18] it was already cleared out yesterday -[22:55:23] by wired -[22:55:23] btw DONT RUSH -[22:55:32] :D -[22:55:37] the messages only show for qt-core now -[22:55:37] qt-core only -[22:55:37] ? -[22:55:38] so I think it's better -[22:55:41] awesome -[22:55:41] tommy[d] complaint many times about this warning overload -[22:55:48] tampakrap_: i already fixed it -[22:55:51] confined it to qt-core -[22:55:54] yes, change was committed yesterday -[22:55:56] ok, I love it -[22:56:02] cool -[22:56:05] we can (and should) shorten the text, but it's much less spam now -[22:56:10] yeah -[22:56:10] if any more cutting is needed, let us know -[22:56:15] like 11 times less -[22:56:18] lol -[22:56:19] :) -[22:56:21] great, so next -[22:56:24] 5. -[22:56:25] gitorious -[22:56:30] wait -[22:56:32] we could look at the text again -[22:56:38] see if it can be shortened -[22:56:40] only downside is no commit bot coolness -[22:57:02] yngwin: i can do it -[22:57:09] i also like the suggestion to put it in out docs and refer in einfo to our docs page -[22:57:34] wired: ok, do it and let us know what you come up with -[22:57:34] thats not bad either -[22:57:38] k -[22:57:41] will mail qt@ -[22:57:47] i'll do the docs btw -[22:57:48] oooh I like that -[22:57:53] alright -[22:57:53] ok then -[22:57:55] no one thought otherwise :) -[22:57:57] why not github? -[22:58:04] next topic -[22:58:11] tampakrap_: i'll do the Qt docs -[22:58:13] many ppl don't have github accounts but want overlay access -[22:58:17] keep it split so we actually do something -[22:58:24] they can create -[22:58:25] or die -[22:58:37] and gitorious is the new black, or something -[22:58:45] oh -[22:58:48] * ayoy checks -[22:58:53] i like gitorious because you an have more people administer the repo -[22:59:03] can* -[22:59:06] it's better in most ways, except cia.vc integration -[22:59:12] I like the bot we have in #-kde -[22:59:13] the only real disadvantage is cia -[22:59:17] do we care enough? -[22:59:17] i am now the bus factor for github -[22:59:18] yngwin: good point -[22:59:38] no -[22:59:40] i mean kde doesn't have cia either, big deal -[22:59:41] I do only a bit -[22:59:58] not really, cia bot is nice, but there are other ways -[23:00:04] i like the cia wow factor as well, but if gitorious is better/more reliable/more popular -[23:00:09] like capslock -[23:00:11] my commit number got too high because of qting-edge, i almost lost my gentoo/slacker cloak -[23:00:13] lets go there and switch the hooks to keep github in sync -[23:00:25] hey hey -[23:00:26] btw -[23:00:26] ! -[23:00:36] if we switch to gitorious -[23:00:41] we still have github as a backup, no? -[23:00:47] we still have the bot -[23:00:50] period. -[23:00:54] right -[23:00:56] touche -[23:00:58] ayoy++ -[23:00:58] heh right -[23:01:00] new ppl who only have gitorious access won't be able to push to github -[23:01:02] lol -[23:01:02] :) -[23:01:10] spatz: no issues, we'll push for them -[23:01:10] so not really -[23:01:13] so vote for it -[23:01:22] yes, vote -[23:01:27] as in topic it is named as voting for gitorious as main repo -[23:01:28] gitorious -[23:01:30] +1 gitorious -[23:01:40] ok then, +1 gitorious -[23:01:46] gitorious -[23:01:46] gitorious + github as backup -[23:01:54] * spatz switches url order in .git/config -[23:02:17] ABCD? -[23:02:29] abstain -[23:02:33] ok -[23:02:37] btw can we do the same trick with kde-testing to get cia bot there as well? -[23:02:53] lol -[23:03:00] only if people actually push to gitorious as well -[23:03:06] better poke PSYCHO___ to fix it -[23:03:07] :p -[23:03:08] you mean github -[23:03:12] yeah -[23:03:13] :D -[23:03:22] if git.o.g.o has cia integration you don't have to -[23:03:23] ok last topic -[23:03:25] s/gitorious/github/ -[23:03:26] so we need to make an announcement about that, to push to gitorious as main repo, and change layman url -[23:04:05] any volunteers? -[23:04:12] announcement in like -dev? qt2? -[23:04:13] qt@? -[23:04:21] qt@ -[23:04:27] i'll do it -[23:04:30] no big deal :) -[23:05:08] im Qt PR -[23:05:09] :p -[23:05:09] last topic: removal of changelogs from overlay -[23:05:15] that one was mine -[23:05:17] also proj page -[23:05:39] lets remove them, they keep breaking my nerves, git logs are enough! -[23:05:48] NO -[23:05:48] wired++ -[23:05:58] seriously -[23:06:02] why not? -[23:06:05] i can't stand them, overlays shouldnt have changelogs -[23:06:10] duplicate info -[23:06:15] qting-edge is also a training area for new recruits / devs-to-be -[23:06:35] yngwin: most overlays are -[23:06:37] it's good practice to get used to using echangelog -[23:06:43] yngwin++ -[23:06:44] yngwin: repoman will scream anyway -[23:06:53] repoman wont scream -[23:06:57] it doesn't -[23:06:58] I think that's the least of the recruit's problems -[23:07:01] yes, that is why my policy is to use echangelog in all overlays -[23:07:02] spatz++ -[23:07:07] it doesn't scream, it warns -[23:07:10] *** Quits: nirbheek (n=nirbheek@gentoo/developer/nirbheek) ("Gone.") -[23:07:10] repoman ignores changelogs for distributed scms -[23:07:14] spatz: ^ -[23:07:17] PSYCHO___: i meant in cvs -[23:07:20] recruits should be taught to read repoman's warnings :) -[23:07:22] spatz: i wrote the code to portage, so i know about its behaviour -[23:07:32] I mean when they commit to the tree -[23:07:36] as long as portage is using cvs and echangelog, i want us to use it in the overlay -[23:07:47] i really don't like it, i forget it because this is the only overlay we use changelogs -[23:07:47] from the ones i use -[23:07:51] echangelog that is, not cs :p -[23:07:55] cvs* -[23:07:59] lol -[23:08:15] can we vote or do you veto? -[23:08:19] for the record i agree with wired -[23:08:21] :D -[23:08:27] i'd like a vote for this -[23:08:28] :) -[23:08:40] also, for users who checkout the overlay, they may expect changelogs -[23:08:45] i would, anyway -[23:08:56] no overlay has changelogs, so why would they? -[23:08:57] *** Quits: krakonos (n=krakonos@kangaroo.kolej.mff.cuni.cz) (Client Quit) -[23:09:07] I'm for changelogs in the overlay -[23:09:09] yngwin: well users are educated to git log or visit gitweb these days, thanks to kde-testing :P -[23:09:14] because portage does -[23:09:47] besides, git log is blazingly fast, its not like you have to cvs log :p -[23:10:02] echangelog in git is also fast -[23:10:06] ;] -[23:10:07] most users dont know how to handle git -[23:10:20] plz vote and end, i want to go to shower -[23:10:23] ayoy: sure, but when you don't echangelog in most overlays -[23:10:24] they can use the gitorious web-ui -[23:10:27] you tend to forget -[23:10:37] wired: then add echangelogs to other overlays -[23:10:39] PSYCHO___: s/vote/veto/ -[23:10:42] :) -[23:10:56] meh -[23:11:02] yngwin: me dont care you are no longer subproject and you are lead, so it is up to you -[23:11:17] yngwin: 2 months ago i could veto your veto but now it is entirely up to you :D -[23:11:22] lol -[23:11:24] lol :D -[23:11:35] i want better arguments than "I'm too lazy" -[23:11:36] yngwin: we hate you -[23:11:44] yngwin: its not im lazy -[23:11:48] tampakrap_: i'm honoured -[23:11:53] it's that i am lazy -[23:11:54] yngwin: fucked up 3way merge strategy -[23:11:58] its dup info, no real advantages :) -[23:12:03] anyway -[23:12:12] we dropped it because it breaks merges a lot -[23:12:17] it was invented to overcome VCS shortcomings we no longer have -[23:12:27] who merges anything in qting-edge? -[23:12:29] we still have in portage -[23:12:34] I've seen it once maybe -[23:12:39] yngwin: portage is cvs, we need it there -[23:12:45] yes, better spend the echangelog time to help portage to move to git i'd say :P -[23:12:45] because it still has to deal with those shortcomings - we don't -[23:13:09] when the tree moves to git the changelogs would probably be thrown out the window -[23:13:11] wired: yes, and i want the overlay to be similar -[23:13:25] then we will remove them as well -[23:13:27] ofc.... -[23:13:29] * PSYCHO___ throws the orange duck from one hand to another and looks on the clock -[23:13:32] still, cvs commit progress is *very* different from git commit process -[23:13:38] PSYCHO___: it's yellow! -[23:13:46] not this one -[23:13:49] yngwin: if recruits can't handle that difference between qting-edge and cvs, then they shouldn't be devs, really :P -[23:13:51] it's Czech duck -[23:14:10] hmm, there is something to that -[23:14:13] so it has weird dots and lines all over and above it? -[23:14:58] ok i have to go, don't care that much about this subject :P -[23:15:01] ok, let's give yngwin time to think about this and wrap this party up -[23:15:09] yngwin: http://dev.gentoo.org/~scarabeus/0911-meeting_summary.txt fix the FIXME parts, me blobs to shower -[23:15:10] yes, ok -[23:15:10] alright -[23:15:15] yngwin: its up to you, next meeting -[23:15:17] let's continue this topic on ML! :D -[23:15:19] yay! -[23:15:31] wait! -[23:15:35] you all FREEZE! -[23:15:40] wut? -[23:15:45] i'll think about it, and we can discuss it again later, ok? -[23:15:48] lets discuss our project page a bit -[23:15:50] yngwin: OK -[23:15:50] don't forget do update your qting-edge/.git/config to new pushurls :D -[23:15:52] * PSYCHO___ does the squeek sound with his duck -[23:16:05] spatz: send a mail to qt@ about it -[23:16:07] can somebody shut up that PSYCHO? -[23:16:10] lol -[23:16:14] he said freeze -[23:16:29] if you need to go, you can go -[23:16:44] i wrote up a first version, but I'd like feedback from all of you -[23:16:49] stuff that should be there -[23:16:51] stuff that should go -[23:17:06] we can continue discussing this after the meeting, we don't need to hold everybody up -[23:17:11] i do want to ask qt devs if thet would prefer a separate meeting, as these combined meetings take long -[23:17:19] ++ -[23:17:19] no -[23:17:22] YES -[23:17:34] if -[23:17:38] we keep it to 2-3 hours combined -[23:17:40] im fine -[23:17:44] issues concern both teams usually -[23:17:45] a pity is that half of the team will have just 2 meetings -[23:17:47] kde and qt one -[23:18:06] tampakrap++ -[23:18:28] i'll write a mail to kde@ and qt@ and we can discuss it then -[23:18:38] or just desktop -[23:18:40] if we started at 18 UTC or started with Qt stuff I'd be fine -[23:18:42] btw, okay to import my patch in phonon ? :] -[23:18:43] desktop mailing list -[23:18:54] mrpouet: good morning! -[23:19:11] i'm not sure everyone is on desktop ml -[23:19:11] *** Quits: ayoy (n=ayoy@gentoo/developer/ayoy) (Remote closed the connection) -[23:19:19] should be -[23:19:19] wired: did you smoke something ? -[23:19:24] *** Joins: ayoy (n=ayoy@cs78245237.pp.htv.fi) -[23:19:30] mrpouet: lol no i don't smoke ;) -[23:19:45] :p -[23:19:48] have to go bye -[23:19:50] :/ -[23:19:52] bai -[23:19:57] bye tampakrap_ -[23:20:00] cya -[23:20:04] *** Quits: tampakrap_ (n=tampakra@gentoo/developer/tampakrap) (Remote closed the connection) -[23:20:07] wired: what your sentence has to do with my question ? :D -[23:20:07] we're wrapping up anyway -[23:20:31] wired: good job on the project page, I'm sure there will be improvements/additions over time -[23:20:33] mrpouet: i asked you to talk about your issue a while back but you didn't respond :P -[23:20:57] * mrpouet has a girl-friend :( -[23:21:01] yngwin: indeed. thanks -[23:21:11] a girl friend is boring you know.. :D -[23:21:17] mrpouet: so do I, but now its sacred... errr meeting time! -[23:21:28] lol -[23:21:43] wired: aaarfff I know !! :( -[23:22:28] i think we can wrap this up now -[23:22:28] :p -[23:22:38] ok, last call -[23:22:40] mrpouet: tell em about your patch -[23:22:45] before they all leave -[23:22:45] :p -[23:22:51] * mrpouet setups a sighandler for SIGGIRL-FRIEND -[23:23:02] ... -[23:23:09] ohhh better -[23:23:15] ignore signal :D -[23:23:23] ==> [ ] -[23:23:25] ^^ -[23:23:27] mrpouet: you have 2 minutes -[23:23:58] 30s gone -[23:24:07] okay so, I wrote a patch in order to add a support for external subtitles (files) -[23:24:07] lalala -[23:24:39] it works just fine, sandsmark approved it (on upstream) -[23:24:56] it would be nice then to patch kaffeine&dragon -[23:25:10] but before we need to import my patch in phonon -[23:25:24] see https://bugs.kde.org/show_bug.cgi?id=213710 -[23:25:31] m-s/phonon or qt-phonon or both? -[23:25:33] for technical details -[23:25:40] yngwin: m-s/phonon -[23:25:46] ok -[23:26:35] currently we can : auto-detect patch (recursively in the media directory), load a patch manually, setting up the subtitle encoding -[23:26:47] rrraaahhh !!!! fucking shit !!! -[23:26:57] auto-detect subs * -[23:27:03] lol -[23:27:06] s/patch/subs -[23:27:08] o_O -[23:27:15] * mrpouet stabs himself -[23:27:39] you're putting quite a show -[23:27:47] :D -[23:27:50] :D -[23:27:51] looks to me the patch has merit, but i'm not kde herd, and i think PSYCHO___ has left -[23:28:02] the patch work -[23:28:02] s -[23:28:08] pretty well -[23:28:12] :) -[23:28:12] * wired tested it -[23:28:30] so i suggest you open a bug and poke kde team -[23:29:34] there is already a bug :) -[23:29:36] ok, meeting closed -[23:29:38] ------------------------------------- diff --git a/meeting-logs/kde-qt-projects-meeting-log-20091119.txt b/meeting-logs/kde-qt-projects-meeting-log-20091119.txt new file mode 100644 index 0000000..7f1c17b --- /dev/null +++ b/meeting-logs/kde-qt-projects-meeting-log-20091119.txt @@ -0,0 +1,959 @@ +[20:45:05] toum toum +[20:46:51] sssh +[20:48:34] *** scarabeus changes topic to 'KDE Team meeting 19.11. 19:00 UTC: Topic 1: Upstream split packages (per kde-scm-interest mail i told you to read)' +[20:52:39] *** Joins: zizo (n=Zizo@host214-182-dynamic.4-87-r.retail.telecomitalia.it) +[20:52:59] *** Parts: zizo (n=Zizo@host214-182-dynamic.4-87-r.retail.telecomitalia.it) +[20:56:35] *** Joins: PSYCHO___ (n=scarabeu@gentoo/developer/scarabeus) +[20:56:35] *** ChanServ sets mode: +o PSYCHO___ +[20:57:05] darn 3g con +[20:59:38] so... meeting time? :) +[21:01:16] yup +[21:01:19] indeed +[21:01:27] anyone can record the histroy? +[21:01:38] i cant log, because quassel is not entirely cooperating right now +[21:01:39] * wired logging +[21:01:48] for the log <- scarabeus +[21:02:04] ok so lets start with rollcall +[21:02:05] even if I seem down my znc/bouncer will keep logging, im on a 3g connection right now (dsl is down) +[21:02:33] *** Joins: spatz (n=spatz@gentoo/developer/spatz) +[21:03:18] *** Joins: ayoy (n=ayoy@gentoo/developer/ayoy) +[21:03:39] *** Joins: mrpouet (n=quassel@gentoo/developer/mrpouet) +[21:03:45] ok so anyone else here? +[21:04:02] *** Joins: wohnout (n=wohnout@88.86.113.238) +[21:04:02] me +[21:04:09] you are so lame +[21:04:11] me +[21:04:12] !herd kde +[21:04:13] (kde) abcd, alexxy, carlo, cryos, dagger, deathwing00, jmbsvicetto, keytoaster, lxnay, mrpouet, patrick, scarabeus, spatz, sping, ssuominen, tampakrap, tgurr, wired +[21:04:13] * wired here +[21:04:13] and me +[21:04:17] !herd qt +[21:04:18] (qt) abcd, ayoy, carlo, hwoarang, spatz, tampakrap, wired, yngwin +[21:04:18] PSYCHO___: stop talking and start working +[21:04:19] roll call +[21:04:22] present +[21:04:22] :D +[21:04:24] I'm here +[21:04:27] HERE +[21:04:46] only qt people +[21:04:52] spatz: it is required only to say it once +[21:04:53] mostly present +[21:04:58] while(1) printf("HERE\n"); :D +[21:05:03] PSYCHO___: here :D +[21:05:04] okay ==> [ ] +[21:05:34] some get kde 3.5 killer... errr.... ssuominen here as well! :P +[21:05:43] ok thats not exactly attendance i expected +[21:06:10] scarabeus: lets wait at least 5 more minutes +[21:06:42] im also worried that some people might show up in an hour or so... +[21:06:46] ok +[21:06:59] because of DST? +[21:07:04] *** Joins: Sput (n=sputnick@quassel/developer/sput) +[21:07:04] yeah +[21:07:15] happened last time +[21:07:23] they can use date -u +[21:07:29] so thats not exactly excuse +[21:07:45] no'ones trying to excuse them +[21:07:47] dst stinks +[21:07:47] :P +[21:07:56] * spatz uses date -u +[21:09:17] so? +[21:09:28] so +[21:09:28] agenda? +[21:09:30] time's up, lets go! +[21:09:42] yngwin: agenda is on -desktop-ml in that mails +[21:09:43] scarb has first item @ /topic +[21:10:00] i will put them onto the topic as we will be going +[21:10:03] thats scattered +[21:10:22] * wired fixes agenda +[21:12:07] ok +[21:12:09] agenda: http://dpaste.com/122485/ +[21:12:30] thanks +[21:12:32] read it while i clean it up a bit +[21:13:00] what about starting from Qt since KDE has a lot to talk about? +[21:13:52] Ingmar: btw are you around? +[21:14:14] updated agenda: http://dpaste.com/122486/ +[21:14:36] ok lets roll +[21:14:51] 21.15 already +[21:14:58] true +[21:15:03] PSYCHO___: are you presiding? +[21:16:02] ok so lets start +[21:16:06] i was smashing my net a bit +[21:16:48] internet has swine flu +[21:17:26] yeah looks so +[21:17:29] * wired whistles +[21:17:36] !herd kde +[21:17:37] PSYCHO___: (kde) abcd, alexxy, carlo, cryos, dagger, deathwing00, jmbsvicetto, keytoaster, lxnay, mrpouet, patrick, scarabeus, spatz, sping, ssuominen, tampakrap, tgurr, wired +[21:17:38] aarfff dinner time :( +[21:17:42] so listen up +[21:18:08] anyone of you did read that mail from Ingmar? or you just idled like usual? +[21:18:21] yes we did +[21:18:22] * spatz read it +[21:18:25] * wired did read it +[21:18:27] i did +[21:18:36] http://article.gmane.org/gmane.comp.kde.scm-interest/724 +[21:18:46] there is my response to that mail thread +[21:19:06] give us a min to read +[21:19:08] it is how i imagine layout that would suit us packagesr best +[21:20:29] *** Joins: j0 (n=quassel@g227216073.adsl.alicedsl.de) +[21:20:29] anyway the question that waits here: "Is anyone willing to work on this?" +[21:21:15] yes +[21:21:26] did you get any response from upstream? +[21:21:33] nope, this mail is last in that thread +[21:22:16] so we are waiting until upstream responds to that first, or not? +[21:22:39] actualy nope, i expect someone coordinate with ingmar and prepare full proposal to them +[21:22:55] because my 6 lines about layout are not exactly "full proposal" +[21:23:00] upstream surely knew we have split kde +[21:23:11] yes they do +[21:23:12] the real question is, do they really want to take this route? +[21:23:40] well some stated that they would like it, some otherwise +[21:23:48] i've also seen discussions about splitting in the past going nowhere (two at least) but never mind +[21:24:10] well this time they are migrating to another SCM so it might have better chance to win :] +[21:24:18] agreed +[21:24:42] does Ingmar (ping) have anything else to say in this topic? (apart from what you said in the mail?) +[21:25:19] well he is aparently not around, so the interested person will have to mail him or irc him at some better time +[21:25:30] do binary distros (pretty much everybody) have split packages or monolithic ones? +[21:25:46] debian has them split +[21:25:52] after compilation tho +[21:25:56] hello +[21:26:05] they compile them in monolithic way and ship them in split way +[21:26:08] hey Ingmar +[21:26:09] scarabeus, tampakrap hi +[21:26:18] hello +[21:26:54] doesn't matter how they do it, only whether they do it. if this change forces everybody to split their packages whereas now they have monolithic ones we might face some opposition +[21:26:56] scarabeus: as you said, i'd like to see upstream move to a buildsystem layout more similar to what xorg has +[21:27:19] scarabeus: i'm less interested in splitting out the libs, or base, but the debian packager i talked to found that more important than anything else +[21:27:34] spatz: other distros follow upstream's way, so they will be forced to change it +[21:27:36] presumably because they can easily split the rest after buil +[21:27:39] d +[21:27:45] s/can/can & already do/ +[21:28:21] well from what we can say the initiative to do the thing will have to cover 2 areas) explaining what to do and how ) showing some example repo done that way +[21:29:04] yeah +[21:30:04] so ANY volunteers for this? +[21:30:09] yes +[21:30:21] and you? +[21:30:29] Ingmar: also i would like to see at least one relevant upstream guy acking that we are not just wasting our time +[21:30:30] I am, obviously :) +[21:31:01] well, let's start with a proof of concept for one module +[21:31:04] i myself will try to help +[21:31:48] i'd put together a proof of cencept first & see what they say on the relevant mailinglists +[21:32:01] ok that sounds reasonable +[21:32:12] splitting kdenetwork or kdeedu might be quite easy +[21:32:24] Ingmar: did you get any affirmative responses from other packagers (and more importantly) by any upstream developer? +[21:32:51] scarabeus: i was thinking kdenetworok, so yeah :) +[21:33:09] tampakrap: packagers yes (debian & gentoo, didn't ask anyone else), didn't ask any specific upstream devs +[21:33:20] ok +[21:33:33] Ingmar: also we should steal some irc channel to have it covered, i guess we cant chit-chat on g-kde or e-kde since its bit offtopic :] +[21:33:36] on the kde-scm-interest ml, some were in favor, and some where against +[21:34:16] any name ideas? :] +[21:34:39] #kde-split +[21:34:41] /j #kde-build-split :) +[21:34:48] ok +[21:35:01] *** Parts: wohnout (n=wohnout@88.86.113.238) +[21:35:23] anything else on the subject? +[21:35:36] i would say that for meeting we covered it +[21:35:46] i personaly will try to motivate few more people +[21:35:52] but that is non-meeting subject :] +[21:36:03] Ingmar: apart from kde-scn-interest ml, any other mailing lists you'd like to see us subscribed? +[21:36:55] kde-buildsystem +[21:37:08] well, if you have more minions, you know where to send them :) +[21:37:20] okz +[21:37:41] ok i think we're done with this for now +[21:37:48] next topic plz? +[21:37:54] first topic plz :) +[21:37:55] tampakrap: now something qt i would say +[21:38:00] since there is more qters +[21:38:09] scarabeus: lets just do the agenda?! +[21:38:27] as you wish +[21:38:33] ok documentation +[21:38:41] *** scarabeus changes topic to 'KDE Team meeting 19.11. 19:00 UTC: Topic 1: Documentation' +[21:38:43] stabilization first +[21:38:44] *** scarabeus changes topic to 'KDE Team meeting 19.11. 19:00 UTC: Topic 2: Documentation' +[21:38:54] http://dpaste.com/122486/ +[21:38:56] *** scarabeus changes topic to 'KDE Team meeting 19.11. 19:00 UTC: Topic 1: stabilisation' +[21:39:35] ok so since only samuli is working on it with me has anyone looked on the bug +[21:39:43] or attempted to fix blocker bugs +[21:40:04] bug # plz? +[21:40:15] * wired hasn't looked at kde 4.3.3 bugs lately, but will +[21:40:25] bgu 292455 +[21:40:26] bug 292455 +[21:40:28] spatz: https://bugs.gentoo.org/292455 "KDE 4.3.3 stabilization request"; Gentoo Linux, Applications; NEW; ssuominen@g.o:kde@g.o +[21:40:41] bug 2: Documentation +[21:40:43] erm +[21:40:43] PSYCHO___: https://bugs.gentoo.org/2 "How do I attach an ebuild."; Gentoo Linux, Ebuilds; RESO, FIXE; tneidt@fidnet.com:hallski@g.o +[21:40:45] damn this +[21:40:49] as spatz said +[21:40:51] lolz +[21:41:02] lol +[21:41:28] so 13 bugs +[21:41:47] i can try to help this weekend +[21:41:50] i want each member of kde team to fix at least 1 +[21:42:28] 12 bugs, 3 stable req and 1 keyword req +[21:42:29] also i want someone to look on current open bugs +[21:42:40] and decide which should be blocking the stabling +[21:42:50] and on this i want volunteer that will actualy do it +[21:43:05] and also close the remaining kde3 bugz +[21:43:13] we can't really do much with keyword/stable requests +[21:43:43] are still there are normal bugs, and not all bugs are now blocking the stabilisation even if they should +[21:43:47] so who will do it +[21:45:13] ok i'll do it since noone is interested +[21:45:19] meaning the bug wrangling +[21:46:11] *** PSYCHO___ changes topic to 'KDE Team meeting 19.11. 19:00 UTC: Topic 2: documentation' +[21:46:12] ok +[21:46:19] next topic +[21:46:41] as i stated +[21:46:54] I want devoted person focusing on updating our documentation with nedy +[21:47:02] as wired I can try to help this week end (I've an exam tomorrow and I've to finish a project) +[21:47:04] yes but i disagree with that +[21:47:45] tampakrap: so how would you do the documetnation +[21:47:53] everyone of us should just realize that documentation is *VERY* important and write two words before a major update or whatever +[21:48:01] apart from that i have another idea that you may like +[21:48:31] *** Joins: ssuominen (n=ssuomine@gentoo/developer/ssuominen) +[21:48:38] speak up :] +[21:48:43] since guidexml requires gorg in order to have a fully rendered (human readable) doc +[21:49:15] i have created an svn repo in my home server that checks out through a hook to a gorg-accessible path +[21:49:22] so it can be read immediatelly +[21:49:48] i can give access to the team here to my home server so we can *ALL* (and i mean ALL, even HTs) develop the guide +[21:49:56] no excuses about permissions etc +[21:50:13] unless you can provide us such a hook, since you have access in overlays.g.o +[21:50:14] well that was done even on git server remember +[21:50:16] I agree, so +1 +[21:50:27] i wrote complete guide in overlay as non-dev +[21:50:59] yes but i'm talking about an immediate co to an xml gentoo.org-like site +[21:51:17] which makes things easier +[21:51:25] this once again shows the shortcomings of guidexml +[21:51:42] well ok +[21:51:48] tampakrap: you then write up something and enforce it +[21:52:01] well, i don't agree with that, it shows that noone cares about docs which is sad +[21:52:38] come on, i just stated something, we can proceed in voting i guess, or go in your way then +[21:53:20] well i am willing to use it, problem is that noone else will edit it, its the same problem as is now +[21:53:36] we can give it a shot +[21:53:37] we can keep those guides in our public_html folders to see it right-away +[21:53:39] until next meeting +[21:53:42] but noone edit it anyway +[21:53:50] that's not the same +[21:53:56] but we should *also* have someone in charge +[21:54:18] well i wanted someone in charge +[21:54:22] so he can say +[21:54:26] that someone would check other commits and will _in_time_ get closer to the docs team +[21:54:30] sorry I'm late; I forgot about the time change :( +[21:54:31] i could be in charge of docs since i am the main editor a while now, but i don't like this idea +[21:54:36] You XY wrote module for AB but did not document it, so do it now. +[21:55:12] so actualy devs introducing something new will be somehow forced to do the docs +[21:55:38] because "anyone does docs and we are happy" simply is NOT working +[21:55:43] the problem is that we don't update the docs BEFORE the change (minor or major) +[21:56:31] well that would be responsibility of doc master, to point when and what needs to be changed +[21:56:35] and that won't change by itself, even if we could write the docs in speech-to-text app +[21:57:22] i dont expect the lead to do the work, but delegate to other devs, and if those wont document, i am even willing to remove them from team +[21:57:31] okay i could do that but i'd expect from the members to respect more the documentation part +[21:58:31] okay if noone has a problem with that then i'll take charge of this position +[21:58:40] *** Quits: ayoy (n=ayoy@gentoo/developer/ayoy) (Remote closed the connection) +[21:58:52] tampakrap++ +[21:58:53] *** Joins: ayoy (n=ayoy@cs78245237.pp.htv.fi) +[21:58:53] ok +[21:59:06] i'll also introduce my system to gentoo-desktop mailing list (i hope devs+HT's are subscribed there) +[21:59:09] PSYCHO___: huh ? remove them from team ? for that ? (I agree document is an important thing does not matter) ... but blame them instead +[21:59:23] while we're on the docs subject, note that I'm taking care of Qt docs +[21:59:27] *** PSYCHO___ changes topic to 'KDE Team meeting 19.11. 19:00 UTC: Topic 3: upstream coordination' +[21:59:32] mrpouet: it is even more important that coding +[21:59:42] just recall what hapened when we masked kdeprefix +[21:59:46] I meant it's a bit....excessive +[21:59:51] mrpouet: its seriously important for users +[21:59:56] mrpouet: and we present our work to users +[22:00:00] tampakrap: I said that I was agree :] +[22:00:02] mrpouet: we need to be 100% covered there +[22:00:22] (document is important) but the consequence is.... excessive imho +[22:00:41] mrpouet: now noone cared, so i will be really evil until they start to care +[22:00:52] well +[22:00:55] i must say +[22:01:04] docs have always been one huge strength of gentoo +[22:01:08] *** Joins: Pesa (n=Pesa@bluemchen.kde.org) +[22:01:13] and lately they're degrading fast +[22:01:15] PSYCHO___: sadistic :P +[22:01:17] so I like this initiative +[22:01:29] lets bring them back :) +[22:01:42] hello :) +[22:01:49] ok so lets loko onto the next toppic +[22:01:51] second late to the party +[22:01:57] :D +[22:02:01] as i can see some people had really the problem with TZ +[22:02:02] :D +[22:02:05] Pesa: hi :) +[22:02:12] Pesa: or you know that you are 1h late? :P +[22:02:17] uhm... +[22:02:20] 1h :O +[22:02:25] he does not +[22:02:27] date -u +[22:02:29] Pesa: ^^ +[22:02:32] damn! timezone :s +[22:02:43] Pesa: I had the same issue :D +[22:02:43] sorry +[22:02:50] ok so lets get to the topic :] +[22:02:56] you'll read logs, lets go! +[22:03:09] who is willing to track upstream patches, and apply them where required +[22:03:10] yep +[22:03:30] wired: or do like me, have a linux clock setting up to UTC :D +[22:03:43] this requires also requesting backports from TRUNK to branch on upstream +[22:04:50] PSYCHO___: you meant a unique guy ? other devs can't import patches from upstream ? +[22:05:03] (it's ambigous) +[22:05:11] they can, but should coordinate with him +[22:05:14] (at least for me with my fuc*$*$$* english) +[22:05:16] it can be even more people +[22:05:29] the point is that we would have the patches applied where needed +[22:05:34] in both overlay/tree +[22:05:57] PSYCHO___: mhhh... personally I could be interested +[22:06:01] Hello +[22:06:05] boss! +[22:06:06] sorry for being late +[22:06:08] jmbsvicetto: hi +[22:06:09] :) +[22:06:09] currently we mostly wait on upstream to release new version +[22:06:11] welcome jmbsvicetto +[22:06:14] hello boss +[22:07:09] Hi everyone +[22:07:16] ok, come on guys, he is half gnome, at least one more volunteer ;] +[22:07:20] its not that hard job :] +[22:07:30] i could help but not that much +[22:07:36] because i am mostly trunk user +[22:08:00] PSYCHO___: what's up? +[22:08:08] :( +[22:08:10] PSYCHO___: it's not an argument :p +[22:08:16] jmbsvicetto: you want log so far? +[22:08:17] Am I 1 hour late?? :| +[22:08:18] i want someone to coordinate patches with upstream :] +[22:08:20] I'm half gnome... and ? :D +[22:08:21] someone dedicated :] +[22:08:22] jmbsvicetto: you are :P +[22:08:49] * jmbsvicetto failed to read UTC :\ +[22:09:05] wired: yes, please (logs) +[22:09:30] jmbsvicetto: ok i'll wgetpaste then hold on +[22:09:49] PSYCHO___: reavertm and ABCD would be perfect for this i guess +[22:09:49] ABCD: how about you? dont want to do this? :] +[22:10:02] tampakrap: exactly my thinking, but reaver is not around now +[22:10:47] the silence after i ask someone something :D hilarious +[22:11:12] PSYCHO___: that would mean I'd actually have to figure out if commits to trunk are relevant/apply on the 4.3 branch... +[22:11:22] (which means more work :( ) +[22:11:26] btw, after this topic, I've another one (tiny) +[22:12:00] trunk after .70 is 90% incompatible with current branch +[22:12:19] (I'm pretty sure you will agree, but I wanted to talk about that during meeting anyway) +[22:12:28] jmbsvicetto: http://dpaste.com/122503/ +[22:12:30] ABCD: i mean more watch what bugs they fix, and ask them to patch it for branch too +[22:13:02] something like "i know you fixed crash X for trunk, but the error is in branch too, so could you fix it too so others dont have to wait for 4 months?" +[22:13:05] wired: thanks +[22:13:28] and second responsibility would be just applying what users add to bugzilla as patches from upstream +[22:13:39] deciding if it is worth or not and so on +[22:13:45] PSYCHO___: so long as someone files a Gentoo bug, and mentions the upstream bug; otherwise I'd never find it :) +[22:13:48] i dont expect that person to review all commits +[22:13:59] ABCD: thats the idea :] +[22:14:09] i dont expect you to browse the upstream one ;] +[22:14:20] in that case, it shouldn't be too difficult +[22:14:58] i know, i just want someone to do it +[22:15:07] so i wont meet 20 days open bug with patch from upstream +[22:15:29] *** PSYCHO___ changes topic to 'KDE Team meeting 19.11. 19:00 UTC: Topic 4: kde3 removal' +[22:15:39] ssuominen: around? +[22:15:50] ok as you might noticed kde3 is going away +[22:15:56] next topic, ssuominen is in progress of it :P +[22:15:57] its quite flawless i can say +[22:16:04] * tampakrap points at #-commits +[22:16:09] http://dev.gentoo.org/~scarabeus/kde3almostgone.png +[22:16:09] wave your hands while you still can +[22:16:19] its going awayyyyyyyyyyyy +[22:16:19] this is what it did to our bugs +[22:16:27] so i want to hear one thing only here +[22:16:34] is something more required on that matter from us? +[22:17:17] nothing i can think of +[22:17:26] me neither +[22:17:30] ssuominen is really doing a great job with this +[22:17:31] thats why i wanted ask others +[22:17:40] bye-bye bugs :D +[22:17:57] wontfix closing is fast :P but dont get used to it :D +[22:18:10] :D +[22:18:20] lets go to RDEPENDs +[22:18:22] * tampakrap is waiting for kde5 - kde4-removal +[22:18:41] tampakrap: go ahead and write kde5 then! +[22:18:42] jmbsvicetto: boss its your area +[22:18:52] jmbsvicetto: so elaborate why rdepend use deps are bad +[22:19:30] *** Joins: pontecorvo (n=pontecor@93-183-229-187-dynamic.retail.datagroup.ua) +[22:19:36] okeey, anyone else? :] +[22:19:41] :P +[22:19:51] i personally like use flags for rdepends +[22:20:06] but i'd like to hear why they're bad from those who don't +[22:20:13] * PSYCHO___ dont care, einfo was always enough for me +[22:20:17] wired: well it is poluting the ebuild +[22:20:21] they are not entirely required +[22:20:27] its not pollution +[22:20:31] so einfo with install X for feature Y +[22:20:42] its only a few words and its helping you do things pre-emerge +[22:20:50] wired: if you stabilise package, it is polution, if you have to wait on optional rdepend to be stabilised +[22:21:07] in that case +[22:21:12] lets work on a per case basis +[22:21:41] for example, obvious or important rdepends could go in use flags, others in info +[22:21:46] that actualy might work +[22:22:33] if an rdepend disables/enables half the package's functionality, it should definately have a USE +[22:22:45] if its a hidden option in the 3rd menu from the right +[22:22:53] it could live without it :P +[22:22:56] *** Quits: pontecorvo (n=pontecor@93-183-229-187-dynamic.retail.datagroup.ua) (Remote closed the connection) +[22:23:35] but we *must* make sure we have einfo if we don't have USE +[22:23:36] make it policy +[22:23:41] thats sound sane +[22:24:05] agreed +[22:24:12] add to CODE maybe? +[22:24:15] yeah +[22:24:27] oh sorry +[22:24:30] *** Joins: pontecorvo (n=pontecor@93-183-229-187-dynamic.retail.datagroup.ua) +[22:24:30] yeah, *docs* man +[22:24:40] ok someone can grab it from summary later then +[22:24:41] :D +[22:24:41] :] +[22:24:41] sorry, reading backlog +[22:24:51] i would kick you now, but we are in meeting +[22:25:04] jmbsvicetto: not entirely smart thing to do during continuous meeting :D +[22:25:16] PSYCHO___: It isn't that rdepend use flags are bad, it's just that there are too many +[22:25:34] at least it used to be too many -> quanta was the best/worst(?) example +[22:25:53] yes, because we are following upstream +[22:26:24] jmbsvicetto: well thats why it is per decision basics +[22:26:33] svn plugin can be controled by svn useflag +[22:26:34] wired / PSYCHO___: I'm not sure they cause so many issues when marking it stable +[22:26:46] we can always have a use flag masked in a profile +[22:26:50] jmbsvicetto: I DO, i try to stable such package right now +[22:27:05] :P +[22:27:09] PSYCHO___: I was trying to catch something ;) +[22:27:16] i think what i said above is good as a rule of thumb +[22:27:43] devs should decide per case depending on the importance of the deps +[22:27:47] so we don't end up with 30 RDEPEND USE flags +[22:27:48] :p +[22:27:54] I don't have a problem with a case-by-case, but then we'll get a bug for each package that we don't provide a use flag :P +[22:28:18] wontfix, because that's how we want it +[22:28:34] or fix, because we did a second thought +[22:28:38] * jmbsvicetto puts user cloak: I want use flag X for installing package Z when I install package Y!!! +[22:28:46] http://www.pastebin.cz/26457 +[22:29:06] jmbsvicetto: we already have wontfix bugs like that +[22:29:08] Ingmar: I'll try to poke you later, but I'm also interested in upstream's work on splitting KDE +[22:29:11] its up to us, not user decision +[22:29:16] yes, I know +[22:30:28] ok, i guess we covered our last point +[22:30:34] so lets move to qt issues :] +[22:30:37] w8 +[22:30:39] wait plz +[22:30:49] mrpouet has sth to add +[22:31:04] hm? +[22:31:11] or had :P +[22:31:15] mrpouet: u here? +[22:31:21] i have to say something too +[22:31:36] tampakrap: then speak :] +[22:31:38] go ahead +[22:31:42] i'll start since mrpouet is somewhere else :P +[22:32:13] recently i fixed a bunch of live ebuilds, reported issues, patches etc +[22:33:07] since i recompile kde and qt live packages very frequently, i would like your permission to create a doc which will track live ebuilds' upstream and downstream bugs, etc +[22:33:15] which are broken and need love etc +[22:33:43] if you think that a doc is not appropriate i could do a page in gentoo-wiki for example +[22:34:11] tampakrap: go ahead, try to motivate some non-team people to help you +[22:34:18] tampakrap: so you can recruit your minions ;P +[22:34:30] on that note, we could create a script +[22:34:31] no way, you are the ht lead +[22:34:34] that picks up your daily rebuild +[22:34:44] and generates a webpage of what failed and what worked +[22:34:45] :p +[22:34:52] you mean something like dirk-dashboard? +[22:34:52] ;] +[22:34:57] contonuous integration +[22:34:57] or something like bump-tool? +[22:35:07] http://dev.gentoo.org/~scarabeus/vystup.html +[22:35:08] something like buildbot? +[22:35:27] a script that takes logs and uploads them somewhere +[22:35:29] something like that PSYCHO___ +[22:35:45] like the thing gnomies have +[22:35:49] tampakrap: well do it if you want it +[22:35:55] i can create a custom script if we don't have something ready +[22:36:03] we don't +[22:36:05] ok ok +[22:36:09] covered +[22:36:11] just give me the logs :P +[22:36:28] ok so lets moove to the qt since mrpouet is not around +[22:36:36] wait a minute +[22:36:47] it seems not covered +[22:37:06] wired: the script would be usuable if it could automatically take the build.logs from the failed packages +[22:37:11] and upload them somewhere +[22:37:33] tampakrap: its not entirely meeting material, and we have meeting already for 1h30minutes... just discuss this with wired on -kde afterwards :] +[22:37:33] yeah +[22:37:37] and we can add a comment next to each one of them, like upstream bug or whatever +[22:37:39] we'll talk about it off list +[22:37:43] off meeting* +[22:37:43] ok ok +[22:37:51] *** PSYCHO___ changes topic to 'KDE Team meeting 19.11. 19:00 UTC: Topic QT 1: qt mono package' +[22:37:58] !herd qt +[22:38:00] (qt) abcd, ayoy, carlo, hwoarang, spatz, tampakrap, wired, yngwin +[22:38:14] surprisingly i am here +[22:38:21] one of our biggest issues +[22:38:26] with the split ebuilds +[22:38:29] the USE flag madness +[22:38:31] is now solved +[22:38:38] because anything < 4.5.3 is off the tree +[22:38:41] \รถ/ +[22:38:41] lol, when? +[22:38:54] i still see people struggling with it +[22:39:03] because they are updating to 4.5.3, not? +[22:39:11] yes +[22:39:12] yay +[22:39:19] once they update, we're done with this shit +[22:39:29] so its solved from our side +[22:39:50] the only thing left is the Qt update blocker madness +[22:40:01] but i think people are beginning to understand that b blocks are autosolvable +[22:40:05] but we'll still have to support latecomers for a long time +[22:40:28] we'll have to support latecomers no matter what +[22:40:39] yngwin: agreed, but that doesn't really change anything if we merge splits into a monolithic +[22:40:45] s/anything// +[22:41:05] it would, but anyway +[22:41:28] i mean, they'd still have to do some migration work +[22:41:38] like update with no blockers +[22:41:40] :) +[22:42:06] yes, but that would be clearer than the current mess with blockers and useflags - portage is just not giving very clear feedback to users +[22:42:20] i agree with the feedback thing +[22:42:45] but with the useflags issue _mostly_ gone, do you feel the blockers are good enough a reason to change things? +[22:42:52] well, we could say that that's a portage bug ;) +[22:43:09] it is mostly a portage problem yes +[22:43:16] xorg packages, for example, don't have blockers for maximum versions, only minimal, so users see less blockers +[22:43:18] well portage should shut up about autosolved blocks +[22:43:20] but we'll have to work with portage +[22:43:29] i dont understand why it writes them out +[22:43:36] qt has both maximum and minimum version blockers and that's creating weird issues +[22:43:39] most users get only confused +[22:43:43] imo the right way to do this is fix portage +[22:43:58] i really want to get into portage development but i just can't these days +[22:44:01] *** Joins: tampakrap_ (n=tampakra@ppp-94-66-145-248.home.otenet.gr) +[22:44:01] why do we need maximum version blockers? +[22:44:04] i am considering doing so in the future +[22:44:16] downgrading Qt isn't really supported anyway +[22:44:31] Sput: you can't mix Qt versions +[22:44:35] Sput: to make sure user has exactly the same version of all packages +[22:44:35] Sput: mixing versions anyhow is neither +[22:44:36] period :P +[22:44:46] wired: i'd like to too ;) +[22:44:51] yes, but the common case is upgrade, yes? +[22:45:01] again, see xorg use case +[22:45:01] to my mind this shows why we need monolithic +[22:45:06] something like MDEPEND +[22:45:07] downgrading doesn't usually work either +[22:45:08] so minimum blockers would be enough to force all qt packages be updated if one is updated +[22:45:12] if package is around then require this version +[22:45:16] otherwise do not care +[22:45:18] so called +[22:45:22] MAGIC DEPENDENCY +[22:45:29] :) +[22:45:38] with only minimum blocks users won't get blockers +[22:45:49] come on its exactly what you want, that might be actualy easy to do with current code +[22:45:55] it will just need new eapi :/ +[22:46:24] PSYCHO___: current code can't do it, i've tried to express it with complex bash but it still shells out blockers +[22:46:27] we need new depend type +[22:46:30] anyway, we said we'd discuss it on ML, which as far as i can see has not happened +[22:46:43] it did not +[22:46:44] wired: i said so, new depend type MDEPEND +[22:46:49] PSYCHO___++ +[22:46:57] who wants to start the ML discussion? +[22:46:58] and it is easy to adjust +[22:47:00] the portage code +[22:47:04] about this +[22:47:13] yngwin: I can +[22:47:19] great +[22:47:22] next topic +[22:47:35] status of qt-tng +[22:47:42] *** PSYCHO___ changes topic to 'KDE Team meeting 19.11. 19:00 UTC: Topic QT 2: Status of new qt-tng.eclass' +[22:47:56] I've been reviewing it for last 1,5 hours +[22:47:59] hwoarang said he couldnt continue with this because of circumstances +[22:48:10] i think it's ready +[22:48:12] yes so are we happy with it enough to post it in -dev? +[22:48:26] provided that we remove prepare_translations? +[22:48:45] this one seems not so handy +[22:48:52] tries to address a common case +[22:48:58] let's prepare the eclass for qt@ before sending it off to -dev +[22:48:59] but the common case doesn't really exist +[22:49:06] except there isn't a common case :) +[22:49:14] so lets remove that +[22:49:21] I will +[22:49:23] yes, we already said that +[22:49:38] ok +[22:49:47] ok, ayoy, can you finalize the eclass and send it to qt@ ? +[22:49:47] hey, btw +[22:49:48] *** Quits: tampakrap (n=tuxicity@gentoo/developer/tampakrap) (Read error: 54 (Connection reset by peer)) +[22:49:56] yngwin: yes I can +[22:50:15] great +[22:50:18] then we can all have a look and comment if needed, then send it to -dev +[22:50:21] are we all happy with the eclass name? +[22:50:26] * ayoy is not +[22:50:29] not really +[22:50:36] ayoy: i talked with picard the other day, he said he liked it +[22:50:36] you already voted on it, but didnt decide anything +[22:50:39] i am not but i don't really care +[22:50:41] qt4-edge kicks testicals very hard, I like it +[22:50:51] not -edge +[22:50:54] we need that for overlay +[22:51:03] qt4v2 +[22:51:03] else we'll have to start overriding and crap +[22:51:11] wired: you mean that qt4-edge will stay in overlay? +[22:51:17] we need eclass versioning dammit +[22:51:26] yngwin++ +[22:51:31] ayoy: yes, we need to keep developing there, don't we? :P +[22:51:37] we do +[22:51:43] yngwin: indeed +[22:51:44] indeed, wired is right +[22:51:53] I propose qt4-next :/ +[22:51:58] qt42morow +[22:51:58] better :) +[22:52:03] qt4-v2 +[22:52:08] read it ^ +[22:52:10] qt4evar +[22:52:11] in english +[22:52:16] PSYCHO___: we did :P +[22:52:33] :] +[22:52:41] qt4-blesmrt +[22:52:42] :] +[22:52:43] qt4-r2 +[22:52:45] ok, let's not waste time on bikesheds +[22:52:50] ^^ in the gentoo spirit +[22:52:54] lol +[22:52:56] :) +[22:53:09] i like that, wired +[22:53:10] this meeting is already taking 2 hours :/ +[22:53:16] let's move on +[22:53:17] * spatz likes it too +[22:53:23] :D +[22:53:25] * ayoy too +[22:53:25] so name unchanged +[22:53:27] ? +[22:53:28] ok, qt4-r2.eclass +[22:53:30] no, changed +[22:53:41] next topic +[22:53:46] w00t, we got rid of startrek +[22:53:47] ok 3. +[22:53:50] #gentoo-qt +[22:53:52] do we want it? +[22:53:58] plz no +[22:54:01] no +[22:54:02] i dont see the need +[22:54:02] *** PSYCHO___ changes topic to 'KDE Team meeting 19.11. 19:00 UTC: Topic QT 3: #gentoo-qt' +[22:54:05] I'd say we rather need a separate meeting +[22:54:09] than a separate channel +[22:54:11] its already registered and when i was bored I added permissions +[22:54:18] so if you ever feel like it +[22:54:18] :) +[22:54:24] ok, but plz no +[22:54:26] :) +[22:54:47] i think -kde is fine as well, but its there if we need it +[22:54:50] ok, so we all agree on 'no' +[22:54:57] neeeext +[22:55:01] let's keep it +[22:55:01] ok, we have a backup for a nuclear war or sth +[22:55:06] *** PSYCHO___ changes topic to 'KDE Team meeting 19.11. 19:00 UTC: Topic QT 4: einfo mess' +[22:55:12] 4. +[22:55:13] but we'll continue to use -kde for the time being +[22:55:18] it was already cleared out yesterday +[22:55:23] by wired +[22:55:23] btw DONT RUSH +[22:55:32] :D +[22:55:37] the messages only show for qt-core now +[22:55:37] qt-core only +[22:55:37] ? +[22:55:38] so I think it's better +[22:55:41] awesome +[22:55:41] tommy[d] complaint many times about this warning overload +[22:55:48] tampakrap_: i already fixed it +[22:55:51] confined it to qt-core +[22:55:54] yes, change was committed yesterday +[22:55:56] ok, I love it +[22:56:02] cool +[22:56:05] we can (and should) shorten the text, but it's much less spam now +[22:56:10] yeah +[22:56:10] if any more cutting is needed, let us know +[22:56:15] like 11 times less +[22:56:18] lol +[22:56:19] :) +[22:56:21] great, so next +[22:56:24] 5. +[22:56:25] gitorious +[22:56:30] wait +[22:56:32] we could look at the text again +[22:56:38] see if it can be shortened +[22:56:40] only downside is no commit bot coolness +[22:57:02] yngwin: i can do it +[22:57:09] i also like the suggestion to put it in out docs and refer in einfo to our docs page +[22:57:34] wired: ok, do it and let us know what you come up with +[22:57:34] thats not bad either +[22:57:38] k +[22:57:41] will mail qt@ +[22:57:47] i'll do the docs btw +[22:57:48] oooh I like that +[22:57:53] alright +[22:57:53] ok then +[22:57:55] no one thought otherwise :) +[22:57:57] why not github? +[22:58:04] next topic +[22:58:11] tampakrap_: i'll do the Qt docs +[22:58:13] many ppl don't have github accounts but want overlay access +[22:58:17] keep it split so we actually do something +[22:58:24] they can create +[22:58:25] or die +[22:58:37] and gitorious is the new black, or something +[22:58:45] oh +[22:58:48] * ayoy checks +[22:58:53] i like gitorious because you an have more people administer the repo +[22:59:03] can* +[22:59:06] it's better in most ways, except cia.vc integration +[22:59:12] I like the bot we have in #-kde +[22:59:13] the only real disadvantage is cia +[22:59:17] do we care enough? +[22:59:17] i am now the bus factor for github +[22:59:18] yngwin: good point +[22:59:38] no +[22:59:40] i mean kde doesn't have cia either, big deal +[22:59:41] I do only a bit +[22:59:58] not really, cia bot is nice, but there are other ways +[23:00:04] i like the cia wow factor as well, but if gitorious is better/more reliable/more popular +[23:00:09] like capslock +[23:00:11] my commit number got too high because of qting-edge, i almost lost my gentoo/slacker cloak +[23:00:13] lets go there and switch the hooks to keep github in sync +[23:00:25] hey hey +[23:00:26] btw +[23:00:26] ! +[23:00:36] if we switch to gitorious +[23:00:41] we still have github as a backup, no? +[23:00:47] we still have the bot +[23:00:50] period. +[23:00:54] right +[23:00:56] touche +[23:00:58] ayoy++ +[23:00:58] heh right +[23:01:00] new ppl who only have gitorious access won't be able to push to github +[23:01:02] lol +[23:01:02] :) +[23:01:10] spatz: no issues, we'll push for them +[23:01:10] so not really +[23:01:13] so vote for it +[23:01:22] yes, vote +[23:01:27] as in topic it is named as voting for gitorious as main repo +[23:01:28] gitorious +[23:01:30] +1 gitorious +[23:01:40] ok then, +1 gitorious +[23:01:46] gitorious +[23:01:46] gitorious + github as backup +[23:01:54] * spatz switches url order in .git/config +[23:02:17] ABCD? +[23:02:29] abstain +[23:02:33] ok +[23:02:37] btw can we do the same trick with kde-testing to get cia bot there as well? +[23:02:53] lol +[23:03:00] only if people actually push to gitorious as well +[23:03:06] better poke PSYCHO___ to fix it +[23:03:07] :p +[23:03:08] you mean github +[23:03:12] yeah +[23:03:13] :D +[23:03:22] if git.o.g.o has cia integration you don't have to +[23:03:23] ok last topic +[23:03:25] s/gitorious/github/ +[23:03:26] so we need to make an announcement about that, to push to gitorious as main repo, and change layman url +[23:04:05] any volunteers? +[23:04:12] announcement in like -dev? qt2? +[23:04:13] qt@? +[23:04:21] qt@ +[23:04:27] i'll do it +[23:04:30] no big deal :) +[23:05:08] im Qt PR +[23:05:09] :p +[23:05:09] last topic: removal of changelogs from overlay +[23:05:15] that one was mine +[23:05:17] also proj page +[23:05:39] lets remove them, they keep breaking my nerves, git logs are enough! +[23:05:48] NO +[23:05:48] wired++ +[23:05:58] seriously +[23:06:02] why not? +[23:06:05] i can't stand them, overlays shouldnt have changelogs +[23:06:10] duplicate info +[23:06:15] qting-edge is also a training area for new recruits / devs-to-be +[23:06:35] yngwin: most overlays are +[23:06:37] it's good practice to get used to using echangelog +[23:06:43] yngwin++ +[23:06:44] yngwin: repoman will scream anyway +[23:06:53] repoman wont scream +[23:06:57] it doesn't +[23:06:58] I think that's the least of the recruit's problems +[23:07:01] yes, that is why my policy is to use echangelog in all overlays +[23:07:02] spatz++ +[23:07:07] it doesn't scream, it warns +[23:07:10] *** Quits: nirbheek (n=nirbheek@gentoo/developer/nirbheek) ("Gone.") +[23:07:10] repoman ignores changelogs for distributed scms +[23:07:14] spatz: ^ +[23:07:17] PSYCHO___: i meant in cvs +[23:07:20] recruits should be taught to read repoman's warnings :) +[23:07:22] spatz: i wrote the code to portage, so i know about its behaviour +[23:07:32] I mean when they commit to the tree +[23:07:36] as long as portage is using cvs and echangelog, i want us to use it in the overlay +[23:07:47] i really don't like it, i forget it because this is the only overlay we use changelogs +[23:07:47] from the ones i use +[23:07:51] echangelog that is, not cs :p +[23:07:55] cvs* +[23:07:59] lol +[23:08:15] can we vote or do you veto? +[23:08:19] for the record i agree with wired +[23:08:21] :D +[23:08:27] i'd like a vote for this +[23:08:28] :) +[23:08:40] also, for users who checkout the overlay, they may expect changelogs +[23:08:45] i would, anyway +[23:08:56] no overlay has changelogs, so why would they? +[23:08:57] *** Quits: krakonos (n=krakonos@kangaroo.kolej.mff.cuni.cz) (Client Quit) +[23:09:07] I'm for changelogs in the overlay +[23:09:09] yngwin: well users are educated to git log or visit gitweb these days, thanks to kde-testing :P +[23:09:14] because portage does +[23:09:47] besides, git log is blazingly fast, its not like you have to cvs log :p +[23:10:02] echangelog in git is also fast +[23:10:06] ;] +[23:10:07] most users dont know how to handle git +[23:10:20] plz vote and end, i want to go to shower +[23:10:23] ayoy: sure, but when you don't echangelog in most overlays +[23:10:24] they can use the gitorious web-ui +[23:10:27] you tend to forget +[23:10:37] wired: then add echangelogs to other overlays +[23:10:39] PSYCHO___: s/vote/veto/ +[23:10:42] :) +[23:10:56] meh +[23:11:02] yngwin: me dont care you are no longer subproject and you are lead, so it is up to you +[23:11:17] yngwin: 2 months ago i could veto your veto but now it is entirely up to you :D +[23:11:22] lol +[23:11:24] lol :D +[23:11:35] i want better arguments than "I'm too lazy" +[23:11:36] yngwin: we hate you +[23:11:44] yngwin: its not im lazy +[23:11:48] tampakrap_: i'm honoured +[23:11:53] it's that i am lazy +[23:11:54] yngwin: fucked up 3way merge strategy +[23:11:58] its dup info, no real advantages :) +[23:12:03] anyway +[23:12:12] we dropped it because it breaks merges a lot +[23:12:17] it was invented to overcome VCS shortcomings we no longer have +[23:12:27] who merges anything in qting-edge? +[23:12:29] we still have in portage +[23:12:34] I've seen it once maybe +[23:12:39] yngwin: portage is cvs, we need it there +[23:12:45] yes, better spend the echangelog time to help portage to move to git i'd say :P +[23:12:45] because it still has to deal with those shortcomings - we don't +[23:13:09] when the tree moves to git the changelogs would probably be thrown out the window +[23:13:11] wired: yes, and i want the overlay to be similar +[23:13:25] then we will remove them as well +[23:13:27] ofc.... +[23:13:29] * PSYCHO___ throws the orange duck from one hand to another and looks on the clock +[23:13:32] still, cvs commit progress is *very* different from git commit process +[23:13:38] PSYCHO___: it's yellow! +[23:13:46] not this one +[23:13:49] yngwin: if recruits can't handle that difference between qting-edge and cvs, then they shouldn't be devs, really :P +[23:13:51] it's Czech duck +[23:14:10] hmm, there is something to that +[23:14:13] so it has weird dots and lines all over and above it? +[23:14:58] ok i have to go, don't care that much about this subject :P +[23:15:01] ok, let's give yngwin time to think about this and wrap this party up +[23:15:09] yngwin: http://dev.gentoo.org/~scarabeus/0911-meeting_summary.txt fix the FIXME parts, me blobs to shower +[23:15:10] yes, ok +[23:15:10] alright +[23:15:15] yngwin: its up to you, next meeting +[23:15:17] let's continue this topic on ML! :D +[23:15:19] yay! +[23:15:31] wait! +[23:15:35] you all FREEZE! +[23:15:40] wut? +[23:15:45] i'll think about it, and we can discuss it again later, ok? +[23:15:48] lets discuss our project page a bit +[23:15:50] yngwin: OK +[23:15:50] don't forget do update your qting-edge/.git/config to new pushurls :D +[23:15:52] * PSYCHO___ does the squeek sound with his duck +[23:16:05] spatz: send a mail to qt@ about it +[23:16:07] can somebody shut up that PSYCHO? +[23:16:10] lol +[23:16:14] he said freeze +[23:16:29] if you need to go, you can go +[23:16:44] i wrote up a first version, but I'd like feedback from all of you +[23:16:49] stuff that should be there +[23:16:51] stuff that should go +[23:17:06] we can continue discussing this after the meeting, we don't need to hold everybody up +[23:17:11] i do want to ask qt devs if thet would prefer a separate meeting, as these combined meetings take long +[23:17:19] ++ +[23:17:19] no +[23:17:22] YES +[23:17:34] if +[23:17:38] we keep it to 2-3 hours combined +[23:17:40] im fine +[23:17:44] issues concern both teams usually +[23:17:45] a pity is that half of the team will have just 2 meetings +[23:17:47] kde and qt one +[23:18:06] tampakrap++ +[23:18:28] i'll write a mail to kde@ and qt@ and we can discuss it then +[23:18:38] or just desktop +[23:18:40] if we started at 18 UTC or started with Qt stuff I'd be fine +[23:18:42] btw, okay to import my patch in phonon ? :] +[23:18:43] desktop mailing list +[23:18:54] mrpouet: good morning! +[23:19:11] i'm not sure everyone is on desktop ml +[23:19:11] *** Quits: ayoy (n=ayoy@gentoo/developer/ayoy) (Remote closed the connection) +[23:19:19] should be +[23:19:19] wired: did you smoke something ? +[23:19:24] *** Joins: ayoy (n=ayoy@cs78245237.pp.htv.fi) +[23:19:30] mrpouet: lol no i don't smoke ;) +[23:19:45] :p +[23:19:48] have to go bye +[23:19:50] :/ +[23:19:52] bai +[23:19:57] bye tampakrap_ +[23:20:00] cya +[23:20:04] *** Quits: tampakrap_ (n=tampakra@gentoo/developer/tampakrap) (Remote closed the connection) +[23:20:07] wired: what your sentence has to do with my question ? :D +[23:20:07] we're wrapping up anyway +[23:20:31] wired: good job on the project page, I'm sure there will be improvements/additions over time +[23:20:33] mrpouet: i asked you to talk about your issue a while back but you didn't respond :P +[23:20:57] * mrpouet has a girl-friend :( +[23:21:01] yngwin: indeed. thanks +[23:21:11] a girl friend is boring you know.. :D +[23:21:17] mrpouet: so do I, but now its sacred... errr meeting time! +[23:21:28] lol +[23:21:43] wired: aaarfff I know !! :( +[23:22:28] i think we can wrap this up now +[23:22:28] :p +[23:22:38] ok, last call +[23:22:40] mrpouet: tell em about your patch +[23:22:45] before they all leave +[23:22:45] :p +[23:22:51] * mrpouet setups a sighandler for SIGGIRL-FRIEND +[23:23:02] ... +[23:23:09] ohhh better +[23:23:15] ignore signal :D +[23:23:23] ==> [ ] +[23:23:25] ^^ +[23:23:27] mrpouet: you have 2 minutes +[23:23:58] 30s gone +[23:24:07] okay so, I wrote a patch in order to add a support for external subtitles (files) +[23:24:07] lalala +[23:24:39] it works just fine, sandsmark approved it (on upstream) +[23:24:56] it would be nice then to patch kaffeine&dragon +[23:25:10] but before we need to import my patch in phonon +[23:25:24] see https://bugs.kde.org/show_bug.cgi?id=213710 +[23:25:31] m-s/phonon or qt-phonon or both? +[23:25:33] for technical details +[23:25:40] yngwin: m-s/phonon +[23:25:46] ok +[23:26:35] currently we can : auto-detect patch (recursively in the media directory), load a patch manually, setting up the subtitle encoding +[23:26:47] rrraaahhh !!!! fucking shit !!! +[23:26:57] auto-detect subs * +[23:27:03] lol +[23:27:06] s/patch/subs +[23:27:08] o_O +[23:27:15] * mrpouet stabs himself +[23:27:39] you're putting quite a show +[23:27:47] :D +[23:27:50] :D +[23:27:51] looks to me the patch has merit, but i'm not kde herd, and i think PSYCHO___ has left +[23:28:02] the patch work +[23:28:02] s +[23:28:08] pretty well +[23:28:12] :) +[23:28:12] * wired tested it +[23:28:30] so i suggest you open a bug and poke kde team +[23:29:34] there is already a bug :) +[23:29:36] ok, meeting closed +[23:29:38] ------------------------------------- -- cgit v1.2.3-65-gdbad