KDE/Meetings/2007 10 31-transcript

From openSUSE

<Bille> "it is six o'clock"
* dirk suggests to wait a few more minutes
* Bille is wearing a Troll outfit
* Beineri eats the children's sweets
<Bille> Seli: wearing your white wizard costume again?
* dirk tastes the new blood smoothie
<Seli> Bille: no, it's in the laundry today
<dirk> ok.. do we have an agenda?
<Bille> Shall we begin? Topic dirk sets the channel topic to "http://opensuse.org/KDE/Meetings - Halloween Meeting * no sweets until its over * | http://opensuse.org/KDE/Upgrade | http://opensuse.org/KDE4 http://lists.opensuse.org/opensuse-kde/ | KDE 4.0 beta4 released!".
<Beineri> dirk: the as last added points on http://opensuse.org/KDE/Meetings?
<Beineri> and stuff from last week listed on http://en.opensuse.org/KDE/Meetings/20071017
<dirk> I suggest to start with the action items?
<Beineri> go ahead
<dirk> ok, first one
<dirk> KDE Team to review the community wishlist
<dirk> what is the status. Will? Stephan? Lubos?
<Bille> I haven't reviewed it yet
<Bille> well, not formally
<Beineri> I don't think that there is anything within that we want/has to be in the core distro
<Beineri> so it's more something for KDE:Community package(r)s
<Bille> o-x-s?
<Beineri> what's o-x-s?
<dirk> ok, next item
<dirk> Prepare KDE Packaging Cookbook with specfile templates for common types of applications or KDE components, suitable for novice packagers (wstephenson)
<dirk> Bille: what's the status?
<Bille> version 1 is at http://en.opensuse.org/KDE/Packaging/Cookbook
<Bille> with a skeleton specfile and a 'worked example' packaging knice from kde-apps.org
<Bille> dear readers: comments welcomed
<dirk> Bille: my comment: metavoid and I have been doing that already last week
<dirk> the result is here: http://en.opensuse.org/SUSE_Package_Conventions/Specific_Packages#10.4._KDE_3.x_Packages
<dirk> The KDE 4.x packaging guidelines are under
<dirk> http://en.opensuse.org/Packaging/SUSE_Macros/KDE4_Macros
<Bille> dirk: so that needs to be coordinated. my idea is not to give an overview but specific recipes for different types of apps.
<dirk> Bille: I agree. I don't understand what you mean by "specific recipes" though
<dirk> is this a duplicate of the next action item, "Explain SUSE/KDE specfile specifics better, for experienced packagers" ?
<Bille> dirk: eg skeleton specfiles for application, style, karamba widgets, windeco
<dirk> Bille: are there so many differences between which kind of thing it is in the way you package it for KDE 3.x ?
<dirk> Bille: but okay. I would suggest to note down the action item to coordinate on that topic
<Bille> dirk: no, but i want a super flat learning curve
<dirk> anyone want to join? metavoid is unfortunately still away
<Bille> to prevent the casual packager getting too frustrated from having to run osc build 15 times before getting all the %files right
<dirk> Bille: the learning curve is already pretty steep since you have to know about packaging in general already ;)
<Bille> the step by step guide i wrote today should mean you can follow most of the steps and get a working package without knowing anything
<metavoid> dirk: I'm here
<Bille> s/most of//
<metavoid> good morning
<dirk> hey metavoid
<dirk> Bille: I guess it makes sense to have the explanations on one page and the tutorial on another page, in order to not duplicate the documentation
<Bille> agreed - good job they invented hypertext!
<Bille> so next tiem
<Beineri> next, "Plan a schema for KDE:* and Qt:* Build Service projects"
<dirk> I have that one
<Bille> packaging specifics was already covered by dirk and metavoid, for the record
<dirk> I've talked with a couple of people and mostly had a draft plan in my head
<dirk> I have not fully written it up yet
<Beineri> in your head means it's not identical to http://en.opensuse.org/KDE/Meetings/Buildservice_Projects ?
<dirk> the start is here: http://en.opensuse.org/KDE/Meetings/Buildservice_Projects
<Bille> dirk: did you assign the action item to yourself?
<dirk> however, plan B) and C) is missing because I haven't finished them :)
<Beineri> ah :-)... ok, write to mailing list when ready as I guess nobody can comment on it ad-hoc anyway
<dirk> Beineri: I agree, however I would like everyone who has feedback to send it to me or add it to the wiki page
<dirk> I plan to write a full mail to opensuse-kde ASAP
<Beineri> then "Add 'always keep on top' option to SUSE2 window decoration" has answer "Can't reproduce, when adding the button to a custom layout it shows up fine with SUSE2 decoration (dirkmueller)"
<Beineri> who reported that in last meeting?
<Beineri> rabauke
<Beineri> was asked to file a bug report about it anyway
<Bille> just for reference, assign action items to yourself before starting work or even thinking about work on them. helps prevent hypertension.
<Beineri> last, "Get opensuse-updater's notifications fixed to not fail focus stealing checks and appear behind other windows any more"
<Seli> that one doesn't make sense, since notifications are passive popups, but assuming it's actually about the window, I think it's only #333386 (already fixed)
<Beineri> which is released as online update already
<dirk> who added that action item ?
<dirk> Bille: yes, which is why I asked you to add the names to the action items as they were discussed in the last meeting ;)
<Beineri> also rabauke talked about in the meeting :-)
<Seli> the original text was "regarding the opensuseupdater. could it place its notification above kicker/the panel and not hide it underneath?"
<Seli> doesn't make much sense to me either
<Bille> dirk: as i said, i didn't feel comfortable about that since it was not clear to me that someone suggesting an AI was also the default assignee.
<dirk> Seli: I would assume it is talking about the passive popups
<Bille> Seli: it's when he's using a coverable Kicker.
<dirk> Seli: I've seen that they're misplaced if the kicker panel is not in bottom possition but in the top afaik
<Bille> dirk: the conventional way to do AI assignation during the meeting is to say "AI: Fuzzy - be more organized"
<dirk> in any case, I think its a bugreport if its reproducible anyway, and shouldn't end up as an action item
<Beineri> so on to the new stuff
<dirk> ok, are we done with old action items?
<Bille> Seli: "allow other windows to cover the panel" is the label.
<Bille> dirk, Beineri: yes, done here.
<Beineri> has nobody the page open? first one, "How can KDE ease users' migration to another opensuse version or PC? KDE-tools to backup settings and data, e.g. Kamion2"
<dirk> amazingly quiet here
<dirk> Has anyone tried Kamion2?
<Beineri> that's http://kamion2.sourceforge.net/
<Beineri> which is for KDE4
<dirk> there doesn't seem to be an openSUSE package yet
<dirk> I think it was a google summer of code project, right?
<Beineri> starting to have it as KDE:Community package would be a good way to be able to try it *hint*
<Beineri> but then, as it depends on KDE4 :-|
<Beineri> AI: hurry with repository proposal ;-)
<Bille> I'd like opensync plugins for syncing kwallets and akregator read flags between PCs, not to mention bookmarks. but that's just a pipe dream.
<dirk> my question would be: does it help with the KDE3 synchronisation? would it help with a KDE3 -> KDE4 transition as well?
<Beineri> documentation seems to be mostly "under construction"
<Beineri> dirk: my bet would be "no"
<dirk> Its licensing is not really friendly. It is GPLv2 only
<dirk> AI: talk to the author to license it properly
<dirk> AI: build a package for anyone to try
<Beineri> there is the synchronisation expert ;-)
<dirk> any takers ? :)
<Bille> dirk: spin the bottle then
<Bille> 2nd AI would be a great opportunity for someone to try packaging, with help and mentoring from us
<Beineri> seems we have no answer (yet) to "how can KDE ease" :-)
<Beineri> next one is some kind of meta question
<Beineri> "Is GUI-driven and well integrated file/folder synchronisation/backup getting more important with increasing popularity of external device ranging from USB-sticks to external harddrives? E.g. Synkron"
<Bille> i think so
<Beineri> both added by rabauke btw
<Bille> i see a lot of people in #kontact wanting to know how to sync PIM data and settings between machines.
<Beineri> Bille: so we have an answer and can close this question ;-)
<dirk> Bille: how is syncing pim data related to this action item? wasn't it just about syncing documents, music or photos?
<dgollub> just a hint: there is also csync - which is kind of rsync but supports bidirectional synchronization .. not just unidirectional syncs like rsync - at it's planned to have same facilities like opensync - conflict handing: latest changed file wins, user decides, .... http://www.csync.org/
<Bille> dirk: it's part of file/folder synchronisation IMO
<dirk>
<dgollub> opensync has currently quite some limition with syncing _big_ files ... it's more inteded to sync content-related data ..which needed to be converted between different data...
<dgollub> like pim.
<dirk> I agree.. PIM synching is usually combined with complicated conversion, while file sync is never converting the format
<dgollub> csync - was targeted to sync full homes.. during login - usecase: laptop, workstation...
<dirk> looks like there is no synkron package yet
<Bille> ok, let's tackle the simple problem of file sync first
<Bille> synkron is also GPLv2
<dirk> dgollub: interesting.. there is a buildservice package even
<dirk> dgollub: did/do you use it?
<dgollub> nope - Gladiac aka. andreas schneider is the author - actually csync was his diploma thesis...
<dirk> oh, I did not know that :)
<Bille> dgollub: so csync is a newer approach to the problem Unison solves?
<dgollub>
<dgollub> Bille: iirc - unison is just rsync bonded to a GUI - right?
<Bille> dgollub: right, with the conflict solving UI
<dgollub> iirc csync will provide callbacks like opensync to allow this kind of conflict resolution by UI.
<Beineri> nothing more to add?
<dgollub> UDS is currently onging...
<Bille> and?
<dgollub> looks like they starting ranting on opensync-devel regarding opensync and conduit and doing synchronization on desktop ;)
<Beineri> /ignore
<dgollub> not quite sure if anyone is familiar with the conduit project... http://www.conduit-project.org/
<Bille> dgollub: interesting, thanks
<dgollub> but i'm in contact with the developers of conduit... and try to convince them that there is only one synchronization solution regarding content-related data ;)
<Beineri> then there was a request for "Packages for Qt Jambi and Qyoto", thread here: http://lists.opensuse.org/opensuse-factory/2007-10/msg00372.html
<Bille> yep, and they have started packaging
<Beineri> someone built already some qt4-smoke and qt4-qyoto package and maybe looking for moving under KDE:*
<Beineri> nobody volunteered for Qt Jambi yet
<Bille> we can encourage them to move to Qt: i'd say
<Beineri> there are obviously Mandriva packages which can be looked at for inspiration: http://www.kdedevelopers.org/node/2937
<dirk> what is Qt: ?
<Bille> part of your upcoming project schema?
<dirk> ah, didn't know that :) okay
<dirk> I guess we should record the action item to contact the current qyoto packager and move his project into KDE:Qt
<Bille> ok. AI: Bille: talk to qyoto packagers
<Bille> next item
<Beineri> and to ask "unknown voluntary packager" to create Jambi package
* dirk looks around
* Beineri is sure everyone has an own opinion about "Number of bug reports increases rapidly (http://ktown.kde.org/~coolo/opensuse_bugs/) - what to do?"
<Bille> what's that, i can't hear you? i have sand in my ears!
<dirk> Beineri: who added that, btw? ;)
<Beineri> about 31 of them are rated "major" or critical
<Beineri> dirk: me
<Beineri> several for kdepim stuff, so we can be sure there will be a cummulative online update for it :-)
<Beineri> three for Kopete, so same
<dirk> my problem with the current bug list is that there are a lot of bugs coming up where I have no idea where they come from
<dirk> it seems to be that 10.3 has some real issues with dbus/hal/kbd starting order, so a lot of people report issues related to that
<dirk> and not all reporters can help us to track them down, or even respond at all
<Beineri> that graphs seems to count also enhancement, so move those to 11.0?
<dirk> is the graph really only about 10.3 bugs?
<Bille> just be prepared for some weird ones caused by #336669 - i noticed it first as unresponsive konquerer, when it was D kioslaves
<dgollub> dirk: isn't there a race with dbus and consolekit/policykit?
<dirk> dgollub: yes, something like that
<Beineri> 10.3 has about 170 reports which the graphs seems to show
<dgollub> dirk: afaik timo is already aware of that...
<dirk> dgollub: I know
<dgollub> dirk: but not quite sure if he or someone else fixes this.. but
<dirk> dgollub: my point is: from the recent raise of bugreports, a considerable amount of them should be related to those issues
<dgollub> dirk: now i see...
<Beineri> 25 bugs are classified as minor
<dirk> ok, possible solutions?
<dirk> a community bugslashing day
* Beineri thinks we have to do a better job with identifying which are suse-specific and which are inherited from upstream only
<dirk> - invite people to review and help with debugging the issues so that the overall progress is faster
<dirk> - find a way to fix all bugs in zero time
<dirk> - .. ?
<Bille> - put head in sand
<dirk> Beineri: I agree.
<Beineri> only 14 bugs have votes for them
<dirk> Beineri: the question is what should we do about bugs that are upstream? just close them? redirect them to bugs.kde.org ?
<Bille> has everyone read our four-toed friends' bug triaging manifesto?
<dasKreech> Fix them ? :)
<Beineri> do we have any (unfixed) bug which has (many) duplicates?
<Bille> it might help to use whiteboards to separate our bugs from upstream bugs as the gnome-opensuse team are doing
<Beineri> dirk: I saw that you starting closing bugs with REMIND and reference to upstream bug report...
<Bille> dasKreech: us: n them: infinity
<Beineri> dasKreech: we can't fix all bugs :-)
<dasKreech> Beineri: no but if you have the suse bugs licked then choose one bug from up stream as a project and raise hell about the rest :)
<dirk> Beineri: correct. I've been doing that where I think that it is an issue which I cannot solve timely and which is not important enough to solve for suse customers first
<Beineri> dirk: and then we're again missing Bugzilla upstream integration to recognize changes there :-(
<dirk> dasKreech: hmm, so to understand you correctly.. you're suggesting that the openSUSE KDE team should first fix all suse only bugs, and then look into upstrema bugs?
<dirk> Beineri: did I hear you say "launchpad" ? ;)
<dasKreech> Well .. unless the upstream is dire
<Beineri> dirk: no need to rewrite the core Bugzilla part imo ;-)
<dirk> Beineri: how about we talk to the novell bugzilla team to ask about their input about some bugzilla integration features?
<dasKreech> I think it would make sense to suseusers (by extension devs) that bugs that only affect Suse be looked at
<dirk> perhaps federico1 can comment if opensuse-gnome team has done already so, and if, what the result is
<Bille> dirk: what are those features?
<dasKreech> since there is a possibility other bugs might get fixed by outside but suse specific bugs ... probably not so much
<Beineri> dirk: if you know whom to ask and where to get the motivation/money/pressure to get it done from :-)...
<federico1> dirk: oh, about bugzilla?
<dirk> dasKreech: I agree that there are probably not that many suse specific bugs
<dirk> dasKreech: however, there are two issues
<Beineri> federico1: whom to kick/beg to gain Bugzilla upstream integration
<federico1> dirk: we are gathering a list of features we want (mainly to track other bugzillas), but haven't sent them to the bugzilla team yet
<dirk> dasKreech: a) unti you actually debugged the issue and sometimes only when you have coded the fix, you know if its suse specific of not
<federico1> Beineri: is that actually implemented anywhere? a neewer version of bugzilla, perhaps?
<dirk> dasKreech: so only figuring out if its suse specific already eats 60% of the time for working on the bug
<Beineri> federico1: where do you sign? :-)
<dasKreech> ah :)
<Beineri> s/you/I/
<dirk> dasKreech: problem b) is, suse specific bugs might be very minor that only very few users hit, and there might be more grave bugs that everyone hits, but that are upstream bugs
<dirk> federico1: can you summarize the list of features that you need from bugzilla? is that written somewhere?
<dasKreech> yeah dire bugs
<Beineri> http://en.opensuse.org/GNOME/Bugs#Policy_for_bug_triaging is very verbose...
<dirk> dasKreech: okay. :-)
<dirk> dasKreech: how do we tag/find/figure out which bugs are dire? :)
<dirk> Beineri, federico1: thanks
<dasKreech> They crash the computer X-)
<federico1> dirk: yeah, at the bottom of that page we have our feature requests
<Beineri> is anyone interested in triaging bug reports/bugslashing day?
<Beineri> not them happening but helping :-)
<Bille> sure
<dirk> federico1: interesting read.
<Beineri> Bille: you're paid to do that anyway ;-)
<dirk> federico1: I would love to see that discussed opensuse project wide though
<Beineri> Bille: until it hurts and even further <g>
<dirk> federico1: but that is getting off-topic. It would be great if we could team up with that effort though
<dirk> federico1: but I guess its a given that we're not going to tag our bugs with gnome-wrong-out-of-the-box ;-)
<Beineri> aren't there new Bugzilla guidelines/tags/classification upcoming anyway?
<federico1> dirk: yeah, for now we want to see how it works for the gnome sub-project, and it if works well we can extend it to the rest of the distro
<Beineri> also, why invent new stuff like "gnome-accessiblity" when "accessibility" already exists as keyword?
<federico1> dirk: we've been assigning severities more or less intuitively, but it may be useful to have hard criteria like "does this actually keep you from getting work done?"
<Beineri> and "should_go_upstream" meaning "Indicates that this bug filed upstream, but that we want to keep it open for tracking purposes."
<federico1> Beineri: hmm, there's an a11y keyword? I didn't know that
<Beineri> https://bugzilla.novell.com/describekeywords.cgi
<federico1> should_go_upstream is a bit overloaded... it can mean "we don't want to fix it here, let's push it upstream", "this is already filed upstream but we may take care of it here", "we took care of it here and we are waiting for upstream to accept the patch", etc.
<Bille> so, can we move on to the next topic
<Beineri> don't think that the explanation is ambigous
<Bille> and pick some ideas out of the logs on this one offline?
<Beineri> Bille: what's the next topic? :-)
<Bille> KDE4 development environment on openSUSE
<dirk> Bille: I was waiting for anyone to wake up :)
<Bille> "it's seven thirty" as beineri's computer just said.
<dirk> but it seems we have a bad day today, and we only see ghosts here :)
<Beineri> Bille: there are the old ones mainly dealt with last meetings. is there anything new to add?
<dirk> rotfl
<Beineri> Bille: still in the office?
<Bille> YES!
<dirk> Bille: you should really load an irc client on your mobile ;)
<Bille> so for everyone else's edification: dirk and I have been working on KDE4 development instructions for opensuse.
<Beineri> Bille: you can try to figure out on Friday how to turn it off ;-)
<Bille> the techbase instructions are updated and I have a customised build script that works on x86_64
<Bille> AI: Bille to pull it together and reference from opensuse.org
<Bille> anything else?
<dirk> Bille: why do we need a customized build script?
* dirk uses the standard KDE build scripts for years :)
<Bille> dirk: build script is perhaps the wrong word, it's that .bashrc template from techbase
<dirk> Bille: the next agenda item would be: misc)
<dirk> Bille: I don't want to advertise that one. its pure horror :)
<dirk> s,its,it's,
<Beineri> how about a KDE 4 Development pattern?
<Bille> well, it's the first one you find if you go through techbase. i have censored the worst bits
<Bille> Beineri: +10
* Beineri sees only "Qt 4 development"
<Beineri> and "KDE Development" contains "libqt4-devel"?
<Beineri> AI: add KDE4 development pattern to KDE:KDE4 project
<dirk> Beineri: it was my impression that we have one already
<dirk> Beineri: regarding that AI: KDE:KDE4:DEVEL would be *just* the answer to that
<Bille> dirk: i didn't see it when i was testing the instructions yesterday, and i looked.
<dirk> see the discussion about splitting the build service repos
<dirk> Bille: that can quite be the case. my problem is that I don't even *know* how to add a new pattern to the buildservice :)
<Beineri> dirk: mhm? which packages to (minimally/required) to install for KDE4 developement?
<Bille> nor me
<dirk> I have a package list in my home directory though
<Beineri> good place ;-)
<dirk> well.. I didn't want to keep it there forever :)
<dirk> it was on my todo to figure out how to push it somewhere so that others can use it/work on it
<dirk> anyone want to help on that?
<Bille> dirk: go on then
<Bille> that means, "yes i'll help"
<Bille> anything else in 'misc'?
<Beineri> let's have a vote to rename it to "misK" :-)
<dirk> veto!
<dirk> any new topics? benJIman ? cb400f ? metavoid ?
<Beineri> so, anything interesting in the next two tweeks until next meeting?
<Bille> fixin' KDE4 bugs for RC2
<dirk> I guess the next meeting shouldn't be done one a day where everyone seems to not spent time in front of the computer :)
<dirk> Beineri: so November 14th?
* Beineri has vacation on 14th
<dirk> should we do it an hour later again?
<Beineri> 14th Nov, tagging of RC1
<Bille> err, yes RC1
<Beineri> are still sweets left?
<Beineri> dirk: how "later again"?
<dirk> Beineri: e.g. 18:00 GMT, not 17:00 GMT
<dirk> I don't care much either way
* Beineri doesn't care :-)
<Beineri> Bille: wanting to put up the log of this meeting? :-)
<Bille> Beineri: i'll defer to you thanks.
<Beineri> whoever started the meeting should end it :-)
<dirk> +++ATH0
<proteus> boa tarde pessoal
<Beineri> dirk: topic
<dirk> see ya in two weeks! :)