From b8817572b3b6c09e8554884b0ed0b22450c73f26 Mon Sep 17 00:00:00 2001 From: Johannes Huber Date: Fri, 17 Aug 2012 06:24:40 +0000 Subject: Meeting log 2012/08/16. --- meeting-logs/kde-project-meeting-log-20120816.txt | 539 ++++++++++++++++++++++ 1 file changed, 539 insertions(+) create mode 100644 meeting-logs/kde-project-meeting-log-20120816.txt diff --git a/meeting-logs/kde-project-meeting-log-20120816.txt b/meeting-logs/kde-project-meeting-log-20120816.txt new file mode 100644 index 0000000..c6ea614 --- /dev/null +++ b/meeting-logs/kde-project-meeting-log-20120816.txt @@ -0,0 +1,539 @@ + 1. Roll call + !herd kde + (kde) abcd, alexxy, creffett, dilfridge, jmbsvicetto, johu, +kensington, mschiff, patrick, reavertm, scarabeus, thev00d00 + you're repeating yourself +-*- creffett is still here +-*- johu is here +-*- dilfridge is here +-*- tampakrap is here + tampakrap wanna rejoin? + no +-*- dilfridge thinks we should just do it + jmbsvicetto / Thev00d00 ? +-*- ago here too + :D + ok meeting opened + 2. KDE SC stabilization (15 minutes) + * Discuss/vote the options: + a) First 4.8.5 as decided in a former meeting, then 4.9.1 / 4.9.2. + b) Skip 4.8.5, start with 4.9.0 / 4.9.1 directly. + c) Other? + tampakrap: do you know anything about kde-stable subproject? + here + isn't 4.8.5 mostly bugfix? + yes + problem is, noone of the team is running it + yes we can stable it realy fast because of no new deps... + judging from prior experience, we should probably skip 4.9.0 + and all ~arch users have already upgraded to 4.9 + dilfridge: wrong i run 4.8.5 on netbook + dilfridge: I'm here to run it + ok cool & cool :) + there are 2 issues: da translation and a missing theme for splashx + the translation compile error should occure on kdepim-l10n as we split +this up + are there fixes / workarounds? + if we decide on option b) i would start with 4.9.1 as upstream done a +lot of bug fixing since 4.9.0 + dilfridge: yes we can patch it + both? + for l10n + my question is whether it fixes any bugs that are relevant to us + with the theme i hadnt a look so far + creffett: which version? + johu: 4.8.5 + we had two fixed tracking bugs as i remember right + any opinions about the direction a) b) c)? + A imho +-*- dilfridge votes a) + ++a, then on to 4.9.1 +-*- johu votes a) + I'm here FYI + Thev00d00: then use your voice :P +-*- Thev00d00 reading backlog + a) + After the vote I would just add a note, plese give me a voice when I can + ago: can we do 485 faster than the 30 days? + johu: sure, for amd64 and x86 + b) + but scarabeus can do it on ppc :P +-*- ago hides + ago: feel free to do and say whatever you want... btw if you leave +and rejoin you'll be op in #gentoo-kde :] + dilfridge: thanks... + speaking of scarabeus... + summary: majority is for 485 and continue with 491/492 afterwards + dilfridge: no need to leave - /cycle + ah ok + 3. Solaris patches (5 minutes) + * We apply many patches to support Solaris, but there seems to be no +prefix + keyword. Does anyone know anything about them? If we are supporting +Solaris, + Kensington would like to push these patches upstream. Does anyone +have + access to a box to test if they are still useful? + that was kensingtons topic but we can talk about it +-*- dilfridge wanders off in search of a beer +-*- johu personally dont cares about minor arches in kde point of view... + ok, is know that every +1 releases is better than the precedent, but in +this case I would copy kernel's team strategy about stabilization, they +stabilize always non the first release, e.g. x.x.7/8 so, since the stable kde +works pretty good, how sound think to stabilize a major release of 4.9? + e.g. 4.9.4 + instead aof proposed 4.9.1 + ago: the past has shown that with start of stabilization we fixed a lot +of bugs + and .1/.2 are in common the most valuable releases + johu: yes, sure, but for me, go to 4.8.5 to 4.9.1(in that case) seems +like a regression, since there will be a lot of bugs + I don't prefer agos idea + Thev00d00: reason? + ago: which bugs to you mean " since there will be a lot of bugs"? + /s/to/do/ + I think ago means upstream bugs + johu: mean usually bugs of first release + dilfridge: yes + thats why i prefer not to stable a .0 release + we're more concerned about finding Gentoo / packaging bugs, and +having two runs of stabilization inside one 4.X cycle helps there + johu: me too, but I'm only said to increase that .0 :P + ok we are finished now with 2) ? + ago: the kernel moves a lot faster than kde and they used to +have parallel development + jmbsvicetto: yes, but is just the concept to stabilize not the first +release + ago: thats what we are doing :D + ago: kde basically throws away the previour minor release when +they launch a new one. So it's very unlikely we'll get a 4.8.6 with any fixes +and 4.9.4 will likely take around 4 / 5 months + I think we should target .1 ... usually we go for .2 anyway then +:D + people will moan + they like fast fast stabilisation + :-) + keep ppc please in mind... + Thev00d00: who wants a newer kde, go to ~arch + the stable users expect minor bugs as possible + thats right! + 3. Solaris patches (5 minutes) + * We apply many patches to support Solaris, but there seems +to be no prefix + keyword. Does anyone know anything about them? If we are +supporting Solaris, + Kensington would like to push these patches upstream. Does +anyone have + access to a box to test if they are still useful? + that was kensingtons topic but we can talk about it + ago: how about this, + we now decide "490 will never go stable, we talk about 491 when +it's out for a while" + dilfridge: fine + and then we can always still say we wait for a later release + if it's too buggy. + the one problem with testing is, +-*- johu is chairing + many problems for users occur when they upgrade major version +-*- creffett suggests hitting people with the gavel until they move on + so, many problems we will only see once many people upgrade to 4.9 + but anyway, this is not urgent now + so let's continue + so where are the dinosaurs? + [21:40:05] 3. Solaris patches (5 minutes) + [21:40:05] * We apply many patches to support +Solaris, but there seems to be no prefix + [21:40:05] keyword. Does anyone know anything +about them? If we are supporting Solaris, + [21:40:05] Kensington would like to push these +patches upstream. Does anyone have + [21:40:05] access to a box to test if they are +still useful? + [21:40:07] that was kensingtons topic but we can +talk about it + whats about the solaris stuff? +-*- creffett votes "no opinion" + well reavertm is obviously logging but away, I sent scarabeus a +reminder but got no reply yet + jmbsvicetto? +-*- dilfridge thinks "remove the patches if noone is interested in a keyword" + johu: solaris? I don't know anything about it + ok then we can give kensington the go to drop it + johu: I'd ping the prefix team about that. If we get no reply, +drop them and wait for someone to cry about them ;) + ? + jmbsvicetto: good statement lets move on + 4. KDE stable subproject (10 minutes) + * Discuss the new KDE stable subproject, as proposed by ago. + ago: its your turn :P + well + I explain all in a mail sent to all, anything not clear? + or everyone didn't look at it? + how many ppl do you have gathered so far? +-*- johu likes the idea but testers are not very long term motivated in +general + johu: this is the point of start for new developers interested to join +kde + in gentoo obviously + I think we can always use more people who run stable/stable +candidate and fix bugs there + because most kde devs run 9999 + I honestly don't see if there's much to gain from having +separate sub-projects for HTs and stable KDE, but if there are enough people +wanting to do stable kde work and not general HT work, then go for it + ok, since there is the time, let me re-explain for all :) + well, we don't really have an active HT group last I checked... + creffett: yes + jmbsvicetto: the HT project seems dead + creffett: but what would prevent anyone from being a member of +HT and do stable work? + obviously :D + [21:49:39] dilfridge: The last I heard, Qt was broken on +Prefix. Once that is fixed, the solaris patches should become relevant. + so the goal of kde-stable is involve people without doing ebuild quiz + jmbsvicetto: I have no problem with that, but we kind of need to +restart the project first + ago: I understand, but I don't think there's much to gain from a +stable sub-project. If you get people interested on that, I won't object, +though + Now the quiz for arch/herd tester has been changed, but I remember When +I did it for arch tester...is a pita + creffett: jmbsvicetto: johu: we could see it as an alternative +approach to HT + dilfridge: HTs did a more general job + ok + dilfridge: they also helped with patches, testing stuff, +following upstream (live) commits + jmbsvicetto: when members counts our HT project? + but to be clear, I don't have anything against a stable +sub-project. If you can gather people wanting to do that, great :) + I just find ago's idea very useful, because our kde team work is +often much focussed on the bleeding edge, and only the one guy leading the +stabilization runs the candidate + +1 dilfridge + i would vote for a more upstream oriented direction + like kdepim bug day + johu: I think there are a lot of people interested in kde (in general), +we do it for improve QA on gentoo +-*- dilfridge gets a headache hearing "kdepim bug day" + take a aspirin :P + how about we start by re-establishing a KDE herd-testing group + @all: which members counts ht project? + and from there, if we have time, inclination, and interest, we make +a sub-group for stable + I know many people and AT that runs kde, they will happy to help + creffett: better not, we should really focus this on "stable" + dilfridge: why not general testers first? + so let me summarize: we have no objections, ago takes care of +establishing that group of people and updates our site + creffett: because it's getting to "undefined"... + any additions? + vague + johu: ok, I'm just asking about HT, if there are no people, we just make +it as dead? + ago++ + yes + yes + ++ + last chance, any additions? + yes + [21:57:12] dilfridge: dunno. feel free to drop all +non-upstreamed stuff. + kde-stable probably will inherit things from HT, e.g. you can ask a test +to any member and/or similar, we can document it + so, see it as an improvement from HT without quiz + sounds reasonable I think + fine + agreed + 5. Bugs (30 minutes) + * app-cdr/k3b: Excessive use of REQUIRED_USE (and wrong combination + USE="lame"+"encode") REQUIRED_USE was added, otherwise USE="-encode +lame" + does nothing. https://bugs.gentoo.org/show_bug.cgi?id=417235 + Options: + 1. Revert to original behaviour - we don't care that +USE="-encode lame" + does nothing + 2. Keep the REQUIRED_USE, but rename lame -> mp3 + 3. Drop the encode flag, but move the optional RDEPS to an elog + 4. Drop the encode flag and keep optional RDEPS (current +behaviour) + kensington is not here, any opinions? + #2 + 2 + tampakrap: you wanna rejoin? :D +-*- dilfridge has no opinion + I said no! + :D + _ /msg Chanserv add #gentoo-kde tampakrap ... + i am so forgetful +-*- johu votes for 2 + 2 is fine + * cmake-utils.eclass: add support for dev-util/ninja + https://bugs.gentoo.org/show_bug.cgi?id=430608 + do we want to support two different build systems? + i would vote for an new eclass that inherits cmake.eclass + I'd suggest we only allow this with I_KNOW_WHAT_I_AM_DOING + AFAIK ninja just generates make files? + nope it's a make alternative + cmake generates the files for ninja, as it generates Makefiles for +make + oh I see + actually, before we decide on this one someone should try to build +whole kde with the new generator :D + and no, I'm not volunteering +-*- johu has a lot of things to compile as x86 arch member, no interest + we can add this to the eclass + I am willing to build/test stuff + +1 for applying the patch + but the generator variable should only be respected if +I_KNOW_WHAT_I_AM_DOING is set + but not willing to fix or patch anything + to avoid an insane number of bugs + imho + if there is anything to compile give me a list + :D + same as tampakrap here + I don't think I_KNOW is needed + yeah after all it needs to be set in ebuild or make.conf + but make should be preferred + even if ninja is present + for sure + agreed then? + yes + can we at least have some elog about untested backend? + or einfo + elog spam FTL + how about, + we only output a message if the build fails + must be possible somehow + then telling "please use make backend before reporting bug" + yeah, sounds good + bad idea, elog beforehands is sufficient + * app-office/calligra-2.4.3: move fonts to separate packages + https://bugs.gentoo.org/show_bug.cgi?id=427910 + for every make based package? :( + *make + didnt I close that one already + dilfridge: i know you closed the bug but i want to discuss this + argh android + ok +-*- creffett thinks it's pointless to split off a few small files here for no +appreciable gain + is there an license breakage? + isn't there a license violation by splitting oxygen-icons? :) + we dont split it :P we remove svgas + tampakrap: not really since we use the bindist useflag I think... + dilfridge: I think there would be a license violation if we +didn't provide a way to get the official tarball + dilfridge: but we should probably ask licenses@ about that + from technical point of view this is a totally senseless bug.... + there is no purpose at all (you save some kbs on HD) and get with new +bumps maybe more work + we could extend LICENSE var if its needed... + the overall reaction to this bug seems to be a definite "meh." + mhm + "we are not debian" :P + le sigh + [22:24:41] New bug: https://bugs.gentoo.org/431680 +"app-office/calligra-2.5.0 has dev-db/mysql automagic"; Gentoo Linux, KDE; +CONF; nikoli:dilfridge + * www-client/rekonq-1.0: please move Nunito-Regular.ttf to separate +package + https://bugs.gentoo.org/show_bug.cgi?id=427914 + this is the related bug to the last one... + its ONE file! + same reaction + recruit the guy to do those things by himself + the question is, are these fonts already somewhere else... + tampakrap: do it + he is in #gentoo-kde btw + but even then, if versions differ we're creating the bugs from +hell + tampakrap: yes we know :] + so summarize? + summary: RESOLVED DONTCARE + cleanest way would probably be "the fonts are already in a +dedicated font package, so we depend on it and delete them locally" + but creating a new font package for one file, NO + creffett: ++ :D + and if versions differ that may lead to strange problems + so I think I'm with creffet + whats about the license problem? + that needs to be spelled out in detail first + who asks license@? + as long as we dont even know if there is a license problem, ... +-*- creffett files a bug to add "DONTCARE" as a bugzie option + RESOLVED MEH + this log is public... + dilfridge: how about to involve upstream? + good luck + we can do it, and calligra upstream is usually responsive, but +before that we need to figure out if there actually IS a problem + and a gain by the move + so, anyone figure out if there is a license problem, and a gain by +the move, + and then I can talk to calligra upstream (who know me) + anybody interested? + ok i take that as no + * net-libs/libkolabxml-0.8.0[php] fails + https://bugs.gentoo.org/show_bug.cgi?id=430858 + The cause here appears to be that FindPHP4.cmake does not look in + /usr/include/php5.*. (and there is no FindPHP5.cmake). This +potentially means + that every search for PHP in cmake is broken (though it appears that +nothing + in kde-base at least has IUSE="php, explaining this not being +caught) + my turn + I've upstreamed this one, but just wanted to see if anyone else has +opinions on it + this issue is connected to kde491 stable :P + it is? + sounds good to push this upstream + its a dep of kdepim-runtime, if we solve this properly we can servce +users the feature + mmkay + well + question 1: does anyone know of a KDE package that actually +uses/deps on PHP? + not that i know.... + yes + a kdevelop plugin + kdevelop parts + yes + hm, I'll look at that + and it's working pretty well actually + tampakrap: i miss you + but basically what happens here is libkolabxml calls +FIND_PACKAGE(PHP4 5.3 required) or something to that effect + <3 + because there is no FindPHP5 module + but regardless of that, our PHP is in /usr/lib/php${PV} + there is no module in official cmake or kde packages you mean? + or noone ever wrote one? + tampakrap: no official module + a google search turned up a couple custom ones, but basically all +they did was replace "php4" with "php5" which still doesn't solve things + then ask kensington to try to push one upstream + since he is pretty known in buildsystem now + my concern here is that I don't know if there's a nice way to do +this for Gentoo's PHP style + is there a nicer way to specify the paths available than listing +every PHP minor version? (e.g. 5.3, 5.4, 5.5 when it comes out...) + creffett: good proposal from tampa, kensington knows a lot of cmake +stuff + johu: okay, will shoot him a note + creffett: not sure about that, I still remember the FindBoost pain + listing every minor version does not look dirty to me tbh + tampakrap: we then have to bump the modules every time a new PHP +comes out + other distros don't slot their php generally + if you want to avoid that, then you need to write a proper build +system first + 6. Open floor (15 minutes) + I know, deal with it + tampakrap: "deal with it" wasn't quite what I was hoping to hear :P + life is hard :) + http://dev.gentoo.org/~dilfridge/shirts-from-hell-small.jpg + so, regarding open floor, and since I missed the discussion for HT +and stable subproject + may I revive the topic? + is ago still here? + ago is chuck norris + ago: ^ + he is everwhere + (ago's highlight works only with the :) + ok so + in short + scarabeus I think invented to have HTs back then, with the first +candidate being me + but it turned out to be a failure as an idea, since people that +wanted to do ebuild stuff were fine with just overlay access + and the HT status offers a cloak only, which is bullshit + so, I decided in a previous meeting to stop that and just have a +list with overlay committers + indeed :) + and try to make them directly developers + so, if you are going to invent any sub-project again or whatever +-*- johu wants reviewboard or similiar for overlay access by users + don't put any paperwork there, and try to motivate people to get +dev status directly + johu: clone the repo in gentoo's github account, there's your +reviewboard + tampakrap: that doesnt solve the problem that they can push the +official overlay + don't follow + they can send merge requests, they can easily get account without +quiz (just by asking) + so what's the problem? + just go for a moment in another place :) + btw kde is one of the best-staffed projects I know at the +moment... + anyway, I think I made my point regarding the HT subproject, feel +free to ping me for anything regarding getting new contributors + I'm interested + either to provide experience or mentor people + tampakrap: the goal is have more testing, not just rename HT project + tampakrap: my + arg + ignore me + _ /ignore johu + done + :D + ago: you want to create a project that does what exactly? + sorry for asking but you had internal discussion I suppose instead +of doing it in gentoo-desktop ml :) +-*- johu will prepare kde 485 next week + take care of testing next stable version on a completely stable +environment + ok, my personal opinion is that you don't want a subproject or a +new team for that + you need to document procedure, write intergration tests maybe, +and put it somewhere under QA + and make it more general, as it doesn't seem to me something that +can be kde only + alternatively: + KDE upstream have a QA team now that test the betas when they come +out, you could ask for their suggestions and ways of working + and cooperate in order to have a good set of products BEFORE the +next major release hits distros (and ours as well) + tampakrap: but we're NOT talking about KDE betas here + tampakrap: wait, you can't know more details about it, let me explain :) + true, we are talking about QA tests before stabilization + which is something that I'm doing professionally the past 8 months +:) + we're talking about all the problems that always ONE guy had to +fix, the one gentoo-kde dev who is overseeing the stabilization and the only +one still running that version :P + tampakrap: now we have decided t ostabilize 4.8.5, so when johu will +prepare a list I will start to test and use it in the next time but I can't +ask to other member/tester to use beta or software that have potentially bugs, +because they will use it ~ as a primary system +-*- dilfridge thinks we should close the meeting, his laptop battery is giving +up... + yeah sorry + dilfridge + + + we can move the discussion in gentoo-kde + no no + i have topic too + Quassel for android needs nick completion... + Thev00d00: ++ + Sput: ^ + i will start with moving defaulting KDE_SCM to git + err sorry, wrong person + any objections? + no, sounds ok + what is still in svn? + 1/3 i would guess + there you go then :-) + we'll probably have portage in git before they finish + Thev00d00: afaik it has if you long-tap the search button or something + kdegames for example, but svn2git rules are heavily in construction + since the upstream migration is far over 50% then, I see no +problem with switching default + ok thanks] + Sput: it works! my word :-) + meeting is over, thanks to all + johu: thanks for chairing :D + G'nite all -- cgit v1.2.3-65-gdbad