15:04:20 <Kevin_Kofler> #startmeeting KDE SIG Meeting
15:04:20 <zodbot> Meeting started Tue Jul 29 15:04:20 2014 UTC.  The chair is Kevin_Kofler. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:04:20 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:04:24 <Kevin_Kofler> #meetingname kde-sig
15:04:24 <zodbot> The meeting name has been set to 'kde-sig'
15:04:26 <Kevin_Kofler> #topic Roll call
15:04:27 * jgrulich is present
15:04:30 * Kevin_Kofler is present, who else?
15:05:03 * tosky here
15:06:09 <than> present
15:07:20 <Kevin_Kofler> danofsatx-work, dvratil, jreznik, mbriza: Ping?
15:07:26 <dvratil> hi
15:08:08 <danofsatx-work> I'm here, was waiting on you
15:08:44 <danofsatx-work> had to go calm a user for moment
15:08:53 <pino|work> here
15:08:59 * jreznik is around but pretty busy
15:09:02 <jreznik> ping me if needed
15:09:38 <mbriza> hi, semi-present
15:10:13 <Kevin_Kofler> #chair jgrulich tosky than dvratil danofsatx-work pino|work jreznik mbriza
15:10:13 <zodbot> Current chairs: Kevin_Kofler danofsatx-work dvratil jgrulich jreznik mbriza pino|work than tosky
15:10:39 <Kevin_Kofler> #info jgrulich, Kevin_Kofler, tosky, than, dvratil, danofsatx-work, pino|work present, jreznik and mbriza semi-present.
15:10:44 <Kevin_Kofler> #topic Agenda
15:11:32 <dvratil> proposing splitting kde-runtime a little to improve coinstallability with Plasma 5
15:11:34 <Kevin_Kofler> #chair ltinkl
15:11:34 <zodbot> Current chairs: Kevin_Kofler danofsatx-work dvratil jgrulich jreznik ltinkl mbriza pino|work than tosky
15:11:42 <Kevin_Kofler> #info ltinkl present (late).
15:12:12 <Kevin_Kofler> There's officially welcoming danofsatx-work as voting WG member, replacing the inactive Siddharth Sharma, that was proposed before.
15:12:39 <tosky> oh, welcome :)
15:12:44 <jgrulich> sorry, I have to go so I won't be available
15:12:45 <ltinkl> welcome aboard
15:13:01 <danofsatx-work> thank you gentlmen, it is my honor to contribute to the best DE on Fedora.
15:13:05 <Kevin_Kofler> There should be a vote, really. :-) Now we have the agenda though.
15:13:10 <than> danofsatx-work: welcome!
15:13:13 <Kevin_Kofler> Is there anything else to discuss this week?
15:13:15 <dvratil> welcome!
15:13:33 <ltinkl> Kevin_Kofler: can you please update the wiki pages?
15:14:30 <Kevin_Kofler> #topic Proposal: New WG composition: Dan Mossor (danofsatx-work) replaces the inactive Siddharth Sharma
15:14:41 <Kevin_Kofler> So, can we formally vote for or against the proposal?
15:14:43 <Kevin_Kofler> +1
15:14:59 <Kevin_Kofler> And yes, welcome on board!
15:15:13 <ltinkl> +1 from me too
15:15:15 <dvratil> +1
15:15:17 <tosky> +1
15:15:18 <mbriza> +1
15:15:34 <than> +1
15:15:45 <Kevin_Kofler> That's +6, i.e. enough. :-)
15:15:54 <danofsatx-work> woot!
15:15:58 * danofsatx-work bows
15:16:06 <Kevin_Kofler> #agreed The proposal passes (+6, -0, 0 abstentions, 5 absent), welcome on board Dan!
15:16:29 <danofsatx-work> Thank you, again. I am truly honored.
15:17:06 <Kevin_Kofler> So with the new WG composition, we should reconsider the default browser issue. :-) – Look here: https://fedoraproject.org/wiki/Talk:Fedora_Plasma_Product/Integration – Firefox no longer has a majority.
15:17:20 <Kevin_Kofler> (17:17 now)
15:18:20 <danofsatx-work> I am for no FF. at all.
15:18:34 <Kevin_Kofler> Me too.
15:18:44 <Kevin_Kofler> Firefox be gone! (Ideally from Fedora as a whole!)
15:19:07 <ltinkl> I'm still undecided tbh, but do we have to go thru this now? we have more important stuff to do than this imo
15:19:33 <danofsatx-work> however, there are some (many?) features missing from the Rekonq and konquerer options.
15:21:04 <Kevin_Kofler> What I see is that Rekonq and Konqueror both actually have MORE features than stock Firefox (without third-party, non-Fedora, sometimes even non-Free, extensions).
15:21:10 <Kevin_Kofler> E.g. builtin ad blocking.
15:21:33 <danofsatx-work> yes, native OS usability is outstanding.
15:21:38 <Kevin_Kofler> Also kioslave support.
15:21:46 <danofsatx-work> however, I'm also with ltinkl - let's shelve this for F22.
15:22:11 <Kevin_Kofler> Shelving only makes sense if we ship F21 with what we have always shipped (Konqueror).
15:22:25 <Kevin_Kofler> F21 won't even be a Plasma Product release, but a KDE Spin one as always.
15:22:51 <danofsatx-work> well, I haven't tried a working live TC yet to know how well everything works. it's on my todo.
15:23:14 <tosky> there were some hints to upstream mailing lists about mozilla devs not being totally closed about patches, if someone is willing to maintain them
15:23:20 <ltinkl> if you look at the technical stuff (https://fedoraproject.org/wiki/Fedora_Plasma_Product/Technical_Specification), there's still a lot of gaps
15:23:33 <ltinkl> Installation methods and media
15:23:34 <ltinkl> and
15:23:41 <ltinkl> Hardware requirements
15:23:43 <ltinkl> mainly
15:23:48 <ltinkl> we should decide on those
15:24:02 <ltinkl> what size/media will we target?
15:24:11 <ltinkl> what HW will we support?
15:24:18 <ltinkl> 32? 64 bit only?
15:24:21 <ltinkl> etc
15:24:59 <ltinkl> and, while it's probably still a bit too early... Plasma 5? :)
15:25:13 <tosky> too early
15:25:14 <tosky> next :D
15:25:18 <ltinkl> given that there's still plenty of time before F22
15:25:30 <Kevin_Kofler> Media: live image, I guess CD won't be possible (I'm having a hard time trying to get a CD-sized Kannolo going even ripping off stuff like SELinux), so I guess we'll stick to 1 G(i?)B.
15:25:45 <ltinkl> ye I know it's too early NOW but we must think like several months ahead
15:25:49 <Kevin_Kofler> Installation: Path of least resistance = stick to liveinst from Anaconda.
15:26:09 <ltinkl> agree with liveinst
15:26:10 <Kevin_Kofler> A couple KDE distros are working on a cross-distro Qt 5 live installer though, let me dig up the link.
15:26:17 <danofsatx-work> change #topic?
15:26:20 * satellit FYI last f21  boot.iso had KDE 0726
15:26:26 <ltinkl> size... dunno, 1 or 2 gigs is fine I guess
15:26:34 <Kevin_Kofler> #topic Plasma Product Discussion
15:26:42 <ltinkl> #topic Installation methods and media
15:26:45 <ltinkl> sry :)
15:26:48 <Kevin_Kofler> That could be an alternative for the future (especially if Anaconda developers follow through on their threat of dropping liveinst).
15:27:17 <ltinkl> yes
15:27:21 * ltinkl likes that
15:27:34 <Kevin_Kofler> (but even without Anaconda doing that, it could be an option)
15:28:01 * Kevin_Kofler would love a GTK+-free Plasma Product by default (especially now that we moved the Scientific parts to an add-on and are focusing on Plasma again).
15:28:52 <ltinkl> ok, let's vote in the install methods and media?
15:29:08 <ltinkl> so that we move the technical docs somewhere
15:29:35 <jgrulich> ok, I'm here again, did I miss something? :)
15:30:18 <ltinkl> so here's the vote proposal: For the time being, we will be using anaconda's liveinst and targetting 2 GB media
15:30:30 <Kevin_Kofler> Darn, I can't find the link again.
15:30:32 <ltinkl> +1 from me obviously
15:30:35 <Kevin_Kofler> Why 2 GB?
15:30:40 <Kevin_Kofler> The target has been 1 so far.
15:30:50 <ltinkl> hmm
15:31:02 <ltinkl> will we safely fit in there?
15:31:12 <ltinkl> (perhaps yes without the sci stuff)
15:31:42 <mbriza> and will there be a way to choose what to install?
15:32:16 <than> Kevin_Kofler: i agree with ltinklm +1 fir 2GB
15:32:20 <Kevin_Kofler> Ah, there's my link to the installer:
15:32:22 <Kevin_Kofler> #link https://github.com/calamares/calamares
15:32:48 <Kevin_Kofler> #info (not ready for production yet, to be investigated in the future)
15:32:51 <jgrulich> I think if we don't fit to CD then it doesn't matter if we have 1GB or 2GB
15:33:21 <ltinkl> ye, if we leave out the CDs, I don't think it matters if it's 1 or 2 GBs
15:33:45 <kc8hfi> There might be people with a bunch of 1 gig usb sticks around though.  if the size is 1gig, it'll still fit on their old stucks
15:33:50 <danofsatx-work> the "official" Fedora swag USB sticks are 2GB. At least the one I got from Masta at Texas Linux Fest last month was.
15:33:51 <ltinkl> better have some spare space left, we can ship extra stuff at least
15:33:51 <kc8hfi> s/stucks/sticks
15:33:56 <Kevin_Kofler> Also download sizes matter.
15:34:00 <than> ltinkl: ++1
15:34:32 <Kevin_Kofler> Installing an image with only the stuff most people will need and then adding the extra stuff is nicer than having a huge image to download with lots of stuff the user doesn't need.
15:34:33 <ltinkl> so 1 or 2? :)
15:34:46 <ltinkl> Kevin_Kofler: that's true as well
15:34:54 <than> +1 for 2GB
15:35:09 <Kevin_Kofler> I'd say 1, or if we cannot reach that (but without Firefox we should be able to! :-p ), then maybe something like 1.2, 1.5 or whatever.
15:35:21 <Kevin_Kofler> Less to download, and leaves room for an overlay on a 2 GiB USB stick.
15:35:28 <jgrulich> + 1 for 2GB including firefox
15:35:31 <mbriza> 1.44GB
15:35:39 <tosky> is it important to decide it now? I mean, if it turns that 1.3 GB are enough, are we going to fill the disk until 2 GB are full?
15:35:54 <pino|work> mbriza: :D
15:35:54 <Kevin_Kofler> I don't want us to go CD → 1 GiB → 2 GiB → 4 GiB → DVD → DVD-DL → BluRay just because we can!
15:36:16 <pino|work> there's plenty of stuff you can put on 2gb keeping that as limit
15:36:25 <Kevin_Kofler> We need to limit the size inflation as much as we can! (Ideally, stop it entirely, but that doesn't only depend on us, there's creeping bloat all over the distro. :-( )
15:36:31 <danofsatx-work> 1.4GB - http://en.wikipedia.org/wiki/MiniDVD
15:37:03 <danofsatx-work> set that as the target, it leaves ~600MB overlay on a 2GB Live USB
15:37:16 <Kevin_Kofler> danofsatx-work: I like that (if and only if 1 is really not reachable anymore!), it's a hardware-enforced size limit, so it's less prone to people just bumping it again for no reason.
15:37:29 <ltinkl> danofsatx-work: good idea, like it
15:37:54 <Kevin_Kofler> (That was also a big reason I disliked doing away with CD size, I *knew* we'd have this discussion again so soon. :-( )
15:39:52 <ltinkl> so go for 1.4GB, MiniDVD format?
15:40:04 <ltinkl> (seems like a good compromise too)
15:40:10 <jgrulich> yep, makes sense
15:40:31 <Kevin_Kofler> Can we really not do 1 anymore?
15:40:48 <ltinkl> we'll see in the end I guess
15:40:53 <Kevin_Kofler> And if yes, why? Just because you want Firefox? Then that's yet another killer reason to NOT ship it!
15:41:20 * ltinkl didn't say he wanted Firefox :)
15:41:25 <Kevin_Kofler> Firefox drags in a whole extra HTML engine (and a huge one at that), when we already have 2 (!) on the KDE spin.
15:41:35 <Kevin_Kofler> OK, just because *someone* wants Firefox. :-)
15:41:38 <Kevin_Kofler> Sorry.
15:41:59 <Kevin_Kofler> Code duplication that WILL bloat our spin.
15:42:17 <Kevin_Kofler> That, and integration is why Firefox is bad on a KDE/Plasma image.
15:42:36 <Kevin_Kofler> Then there are all the reasons why it's just bad to begin with, but we don't need to rehash those now. :-)
15:42:51 <ltinkl> next time I see the word "Firefox" in this channel, I'm leaving ;)
15:43:59 <Kevin_Kofler> Let's move on to the next topic, or we won't get done…
15:44:01 <ltinkl> let's move on, I'll put the "1.4GB, MiniDVD in the tech specs" as a tentative target
15:44:03 <ltinkl> ye
15:44:10 <Kevin_Kofler> ltinkl: OK
15:44:14 <ltinkl> #topic Hardware requirements
15:44:37 <Kevin_Kofler> Uhm, that wasn't really on the agenda. ;-)
15:44:57 <Kevin_Kofler> CPU requirements are defined by Fedora as a whole.
15:45:07 <ltinkl> sry, I just moved one bullet down in the tech specs
15:45:11 <Kevin_Kofler> 32-bit i686 = 686 with cmov
15:45:18 <tosky> ltinkl: before going on with this, wasn't there an agenda proposal from dvratil?
15:45:18 <kc8hfi> the live respin is gettin up there,  924 megs
15:45:22 <Kevin_Kofler> x86_64 = base x86_64 (which includes SSE2)
15:45:34 <Kevin_Kofler> tosky: Right.
15:45:35 <ltinkl> tosky: sry, must have missed that, I came a bit too late
15:45:40 <Kevin_Kofler> The only thing we can tweak is memory.
15:45:45 <ltinkl> dvratil: all yours then
15:45:48 <Kevin_Kofler> And there we should go with upstream recommendations.
15:46:10 <Kevin_Kofler> #topic Proposal: splitting kde-runtime a little to improve coinstallability with Plasma 5
15:46:14 <Kevin_Kofler> dvratil: Your turn.
15:46:29 <dvratil> Soooo, in order to have maximum co-installability between KDE 4 and Plasma 5, we need to split two things from kde-runtime: that's khelpcenter (simple app - I have no idea why it even is in kde-runtime), and -docs
15:46:53 <dvratil> here's updated spec file, so if someone can review it after (or during) the mtg: http://paste.fedoraproject.org/121721/46411140/
15:47:06 <pino|work> dvratil: because applications ship documentation, and it was deemed good to have something for users to read them
15:47:23 <pino|work> (or something like that, if i remember correctly baaaack then)
15:47:24 <dvratil> I'd like to get this to Fedora asap, as that's the last thing that blocks the Copr repo with Plasma 5 to install all packages
15:47:43 <dvratil> pino|work, could be kde-baseapps or something, but that's not relevant atm
15:47:45 <ltinkl> dvratil: make sense
15:47:55 <dvratil> khelpcenter is provided standalone now in Plasma 5
15:48:06 <dvratil> so it will go as a smooth update to khelpcenter 4.13.3
15:48:10 <Kevin_Kofler> I guess we can split it out, make kde-runtime Requires: it, then the Plasma 5 repo can provide a build with a higher EVR.
15:48:11 <tosky> dvratil: how does it this improve the coinstallability? Just for khelpcenter?
15:48:23 <dvratil> and kio-extras-docs Obsoletes kde-runtime-docs
15:48:48 <Kevin_Kofler> (assuming khelpcenter from Plasma 5 can read the docs for KDE 4 (and 3 for that matter) apps, otherwise we need another solution (renaming the executable and patching stuff to find it, ugh…))
15:48:59 <dvratil> I would expect so
15:49:53 <tosky> it should be able to do it, yes
15:50:09 <danofsatx-work> did the actual base format of the docs themselves change from 3 to 4 to Plasma 5?
15:50:13 <tosky> I think kdelibs4support could be needed, though
15:50:25 <tosky> danofsatx-work: it's not plasma-related, and yes, the DTD was updated
15:50:33 <dvratil> arguably we could split the kde-runtime package a bit more (-kcm, -kio, kglobalaccel, kde-cli-tools) - but the question is whether that makes sense atm
15:50:39 <danofsatx-work> ok, but is it backwards compatible?
15:50:41 <Kevin_Kofler> dvratil: kde-runtime has more docs than just the kio-extras ones.
15:50:55 <dvratil> Kevin_Kofler, khelpcenter installs it's own docs
15:50:56 <tosky> danofsatx-work: backward compatibility is provided in kdelibs4support
15:51:01 <danofsatx-work> ok
15:51:10 * danofsatx-work goes back to his corner
15:51:31 <Kevin_Kofler> And does it still work for KDE 3 docs? IIRC, the KDE 4 khelpcenter can view those just fine.
15:51:52 <ltinkl> dvratil: wouldn't kdelib4support clash with kdelibs-4 then? :)
15:52:05 <dvratil> ltinkl, kdelibs4support is coinstallable with KDE 4, it's a framework
15:52:28 <ltinkl> dvratil: ok, we will have another clash then, the translations
15:52:36 <tosky> Kevin_Kofler: I didn't try that in a long time; I think we could have broken some documentation few years ago, so maybe docbook 4.1.x documentation could not work even now
15:52:39 <dvratil> ltinkl, how come?
15:52:42 <ltinkl> they get installed into the same dir, most of the times with the same name too
15:52:55 <dvratil> hmm
15:53:04 <dvratil> only on the applications level
15:53:06 <dvratil> not in Frameworks
15:53:11 <ltinkl> some tools got renamed (like kreadconfig->kreadconfig5)
15:53:12 <dvratil> (the names there are different)
15:53:13 <ltinkl> ye, apps
15:53:15 <Kevin_Kofler> I can view the Quanta Plus docs in khelpcenter, but there are strange error messages on the console.
15:53:23 <Kevin_Kofler> But the stuff shows up.
15:53:34 <ltinkl> dvratil: ye the frameworks are fine, but not the apps
15:53:34 <dvratil> ant that could be solved by splitting the KDE 4 translation packages
15:53:51 <ltinkl> dvratil: I don't see how
15:53:53 <dvratil> and the Plasma 5 package would obsolete that specific KDE 4 translaction subpackage
15:53:57 <Kevin_Kofler> (The errors are about meinproc failing with exitCode 2.)
15:54:05 <ltinkl> dvratil: it can't
15:54:08 <Kevin_Kofler> (meinproc4 actually)
15:54:09 <dvratil> ltinkl, why?
15:54:11 <ltinkl> dvratil: let me explain
15:54:20 <dvratil> ltinkl, don't tell me all translations in KDE 4 are in one huuuuuuge file
15:54:21 <ltinkl> all the translations are in one RPM
15:54:36 <ltinkl> now suppose you have plasma 5 and digikam
15:54:39 <ltinkl> from KDE 4
15:54:52 <Kevin_Kofler> You can do what I did to the KDE 3 kde-i18n.
15:55:01 <ltinkl> you can't obsolete KDE 4 translations RPM with the one from Plasma 5
15:55:02 <Kevin_Kofler> for i in (everything that's in KDE 4)
15:55:05 <Kevin_Kofler> rm -rf $i
15:55:12 <Kevin_Kofler> end
15:55:14 <dvratil> ltinkl, you can obsolete kde-18n-digikam-Czech
15:55:18 <dvratil> ah, darn
15:55:24 <dvratil> you would have to obsolete all langauges manually
15:55:25 <ltinkl> there's no such thing...
15:55:39 <dvratil> ltinkl, that's why I said we would split kde-i18n-$language packages
15:55:40 <ltinkl> all the translations for one language are in one RPM
15:55:41 <dvratil> to per-app
15:55:54 <ltinkl> that means updating _all_ the KDE 4 apps
15:55:55 <dvratil> have per-application subpackages (where it makes sense)
15:56:02 <tosky> Kevin_Kofler: meinproc4 fails maybe because of some entity not defined or so; if you enable more debug, run khelpcenter from the command line, and you see more information, please send them to me
15:56:02 <dvratil> why?
15:56:08 <Kevin_Kofler> The kde-i18n packages are still like that. (These days, they should probably use a whitelist instead, but I never got around to it.)
15:56:48 <Kevin_Kofler> Distro with Plasma 4 as default: delete all the conflicting translations from Plasma 5, and vice-versa.
15:57:06 <Kevin_Kofler> That's how we did it for kde-i18n vs. kde-l10n back in the days (and still do for kde-i18n, as I said).
15:57:18 <ltinkl> ye...
15:57:27 <dvratil> sound a bit harsh
15:57:30 <dvratil> *sounds
15:57:43 <Kevin_Kofler> I actually used scripts to get a list of all the translations that conflicted, and then scripted the rm -rf into %install.
15:57:43 <dvratil> you will end up with workspace localized, but most apps in english
15:57:51 <Kevin_Kofler> tosky: When I get around to it, sure.
15:57:55 <tosky> oki
15:58:06 <ltinkl> dvratil: nope
15:58:40 <Kevin_Kofler> dvratil: The secret is to delete the translations of the version you don't ship. :-)
15:58:47 <ltinkl> dvratil: you just emove stuff that exists in KDE 5 and KDE 4, ie that has a newer (ported) version
15:59:09 <dvratil> I see
15:59:13 <Kevin_Kofler> (We still do blacklist kdewebdev translations from kde-l10n, by the way.)
15:59:24 <Kevin_Kofler> (because kdewebdev in KDE 4 is a bad joke)
15:59:33 <Kevin_Kofler> (no Quanta, nor anything else that does web development)
16:01:17 <Kevin_Kofler> I'm not saying it's a nice and clean solution, but it's an effective one with the constraints that we have (one big l10n package with per-language subpackages).
16:01:58 <Kevin_Kofler> I really really don't want to do split l10n packaging.
16:02:18 <Kevin_Kofler> There are already over 50 subpackages, adding a per-app splitting dimension will make them go in the thousands or worse!
16:03:18 <ltinkl> I think it's well over 60 :)
16:03:51 <Kevin_Kofler> That's mathematically over 50. ;-)
16:04:24 <Kevin_Kofler> Anyway, doing per-app splits will make them too many!
16:04:58 <ltinkl> ye, that would be hell
16:05:17 <ltinkl> oh and
16:05:27 <ltinkl> the frameworks ship translations bundled :(
16:05:34 <Kevin_Kofler> Though it could make us beat TeXLive's package count. ^^
16:05:35 <ltinkl> to add some extra complication layer
16:06:07 <Kevin_Kofler> Didn't they also regress some of the frameworks to using Qt's silly Not Invented Here translation system?
16:06:19 <ltinkl> but they won't clash with existing stuff so it doesn't matter
16:06:25 <tosky> there is no split translation packages, every package will bring the translations
16:06:27 * Kevin_Kofler hates that Qt-only translation system.
16:06:29 <tosky> like other libraries
16:06:49 <tosky> even if they are gettext based, this has nothing to do with ts vs po
16:06:51 <Kevin_Kofler> tosky: But the point is that it makes it harder to blacklist the translations if they conflict with KDE 4 ones.
16:06:52 <ltinkl> https://bugreports.qt-project.org/browse/QTBUG-40444
16:07:05 <Kevin_Kofler> Those .qm ones at least won't conflict. ^^
16:07:10 <Kevin_Kofler> (but they suck in other ways)
16:07:11 <tosky> I understand that, I have no other solutions
16:07:12 <ltinkl> the frameworks (the Qt-only ones) have this problem
16:07:30 * ltinkl notes arguing with ossi is like banging head against wall
16:07:40 * Kevin_Kofler knows that feeling.
16:08:02 <ltinkl> so ye, frameworks use PO files but they get transformed into QM
16:08:08 <ltinkl> and there the fun begins :)
16:08:31 <Kevin_Kofler> Ewww…
16:08:48 <Kevin_Kofler> Why don't you just stick to gettext? Everyone has gettext installed, it's part of glibc, darnit!
16:09:07 <tosky> not all frameworks, luckily
16:09:16 <tosky> applications are going to use ki18n
16:09:21 <ltinkl> ye just the Qt-only ones
16:09:41 <Kevin_Kofler> Qt-only KDE frameworks shouldn't exist to begin with.
16:09:43 <ltinkl> because Qt-only code can't load mo files coming from gettext
16:10:39 <ltinkl> anyway, offtopic here, another one on agenda?
16:10:43 * ltinkl has to run in a minute
16:11:27 <Kevin_Kofler> #topic Flock 2014
16:11:45 <Kevin_Kofler> #info Next week, there will be Flock 2014 in Prague (Aug 6 to 9, 2014).
16:12:03 <Kevin_Kofler> I suppose several of us will be there. :-)
16:12:19 <Kevin_Kofler> Unfortunately, there isn't anything KDE-related on the schedule.
16:12:32 <Kevin_Kofler> (at least not directly)
16:14:38 <Kevin_Kofler> Anything interesting KDE SIG / Plasma WG members shouldn't miss? I guess cwickert's Spins discussion/workshop at the very end will be interesting.
16:16:17 <Kevin_Kofler> Looks like there isn't much more to say on this topic, so…
16:16:19 <Kevin_Kofler> #topic Open discussion
16:16:27 <Kevin_Kofler> … anything else? Or can I close the meeting?
16:16:51 <ltinkl> Kevin_Kofler: pls add danofsatx-work to the membership, ty
16:16:58 <Kevin_Kofler> OK, will do.
16:18:06 <danofsatx-work> I gotta run, thanks for the welcome folks.
16:18:27 <Kevin_Kofler> FYI, I won't be available for the meeting next week.
16:18:45 <Kevin_Kofler> I'll leave you others to figure out whether you'll be enough to hold a meeting, and if yes, who will lead it.
16:18:46 <danofsatx-work> not sure if I will be, either - it's finals week for me
16:19:48 <Kevin_Kofler> If you know you won't attend, please say so ASAP so we don't end up with 2 or 3 people wasting their time waiting for everyone else. If you know you WILL be available, that's also good to know in advance, too. Thanks for your cooperation. :-)
16:19:59 <Kevin_Kofler> That said, thanks all for coming!
16:20:09 <Kevin_Kofler> #endmeeting