[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]