15:05:21 <Kevin_Kofler> #startmeeting KDE SIG Meeting
15:05:21 <zodbot> Meeting started Tue Mar 25 15:05:21 2014 UTC.  The chair is Kevin_Kofler. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:05:21 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:05:26 <Kevin_Kofler> #meetingname kde-sig
15:05:26 <zodbot> The meeting name has been set to 'kde-sig'
15:05:29 <Kevin_Kofler> #topic Role call
15:05:33 * Kevin_Kofler is present, who else?
15:05:40 * jgrulich is present
15:05:56 * ltinkl present
15:06:02 * tosky too
15:06:29 <rdieter> here (mostly, will be 100% in ~5 min)
15:08:38 <than_> present
15:08:55 * danofsatx-work is here
15:09:21 * jreznik is here
15:10:33 <Kevin_Kofler> #chair jgrulich ltinkl tosky rdieter than_ danofsatx-work jreznik
15:10:33 <zodbot> Current chairs: Kevin_Kofler danofsatx-work jgrulich jreznik ltinkl rdieter than_ tosky
15:10:47 <Kevin_Kofler> #info Kevin_Kofler, jgrulich, ltinkl, tosky, rdieter, than_, danofsatx-work, jreznik present.
15:11:20 <Kevin_Kofler> dvratil, mbriza: Ping?
15:12:05 <mbriza> hey, i'm here, sorry
15:12:06 <jgrulich> Kevin_Kofler: dvratil won't attend the meeting, he is not here :)
15:12:24 * ltinkl brb, something urgent at home, ~10 minutes
15:12:43 <Kevin_Kofler> #chair mbriza
15:12:43 <zodbot> Current chairs: Kevin_Kofler danofsatx-work jgrulich jreznik ltinkl mbriza rdieter than_ tosky
15:12:51 <Kevin_Kofler> #info mbriza also present, dvratil absent.
15:13:04 <Kevin_Kofler> #topic Agenda
15:13:22 <Kevin_Kofler> So, what's up now?
15:13:46 <Kevin_Kofler> Any updates about the productization process?
15:13:55 <jgrulich> I have just a small info, that Plasma Next from dvratil's COPR repository is working
15:14:03 <Kevin_Kofler> Yay!
15:14:15 <Kevin_Kofler> #info Plasma Next from dvratil's COPR repository is now working.
15:15:31 <jgrulich> I'll also prepare packages for libnm-qt and plasma-nm, because it is also mostly working http://www.imagehosting.cz/?v=snapshsws.png
15:16:28 <jgrulich> but probably next iteration of updates will be with the first kde-workspace release
15:17:18 <jgrulich> http://techbase.kde.org/Schedules/Plasma/2014.6_Release_Schedule → first Alpha release is next thursday
15:17:28 <rdieter> jgrulich: when do you think we will start seeing pkg reviews for some kf5 bits?
15:18:08 <rdieter> I'd like to see low-level stuff like ecm in rawhide asap
15:18:19 <tosky> please remember that KF5 beta1 will be tagged this Friday; after that, no more SIC changes, so maybe it could be a good starting point
15:18:25 <jgrulich> I would do it after some beta release of KF5
15:18:29 <rdieter> ok
15:18:31 <jgrulich> tosky: yep :)
15:18:39 <jreznik> jgrulich: does not work for me - black screen, that's all
15:19:19 <jgrulich> jreznik: weird, do you have latest kf5-kinit and kde5-workspace?
15:19:20 <Kevin_Kofler> #topic KDE Frameworks 5, Plasma Next
15:19:32 <Kevin_Kofler> Let's officially make this the topic, seeing how we're discussing it all this time. :-)
15:21:07 <Kevin_Kofler> "Plasma 2014.6"??? WTF, Ubuntu-style versioning now? :-/
15:21:15 <Kevin_Kofler> This is getting sillier every day.
15:21:25 <jgrulich> review all KF5 package should be easy, since all KF5 are almost same, we need to just review a few of them and prepare the rest according to reviewed ones and probably mark them as reviewed automatically
15:21:40 <Kevin_Kofler> (Is that the compromise to sort out the flamewar over whether this is Plasma 2 or Plasma 5?)
15:22:35 * Kevin_Kofler wonders how many different versions will actually be used and what we should put in our Version field at the end.
15:23:03 <Kevin_Kofler> Worst case: Release officially called 2014.6, tarballs called 5.0, plasma-desktop reports version 2.0.
15:23:16 <rdieter> as long as it's blue
15:23:22 <rdieter> (the bikeshed)
15:24:36 <Kevin_Kofler> Now we just need somebody to introduce udev/systemd-style versioning (one integer) and the chaos will be perfect. ^^
15:25:25 <Kevin_Kofler> jgrulich: I don't think that will work, formally.
15:25:42 <Kevin_Kofler> There are too many small differences (list of BuildRequires, for example).
15:26:12 <Kevin_Kofler> And this kind of process is only intended for stuff with really many packages like TeXLive, and even there some people were unhappy about it.
15:27:16 <rdieter> I'm sure we can sort out the reviews without too much trouble
15:27:16 <Kevin_Kofler> (For what it's worth, TeXLive was eventually packaged with only very few huge specfiles with many subpackages.)
15:27:36 <tosky> (ehm, "less" had had the one-integer versioning forever, but that's not important now I guess)
15:28:17 <Kevin_Kofler> tosky: So let's call it less-style versioning then. ;-) Not sure who first came up with it, maybe less wasn't the first either.
15:28:26 <tosky> uhm, good question
15:28:39 <Kevin_Kofler> It's the most obvious versioning style.
15:29:30 <Kevin_Kofler> rdieter: What we can do, of course, is to approve the packages relatively quickly if they really are similar enough to the others that passed already. But there should still be someone at least looking at each specfile.
15:30:10 <jgrulich> btw. I think they also plan to split kde-workspace to more packages, that's going to be fun for packagers :)
15:30:46 <rdieter> Kevin_Kofler: +1
15:30:49 <jreznik> reviewed automatically concept really does not exist in Fedora :D
15:31:48 <Kevin_Kofler> jgrulich: KDE (and also Qt now) upstream is really being a PITA with their split tarballs. :-(
15:32:42 * rdieter appreciates the splitting fwiw
15:33:12 <rdieter> formalizes interdependencies, and so all distros do it consistently
15:33:38 <rdieter> (even though sometimes its not done ideally)
15:33:54 <jgrulich> rdieter: yep, it's fine once it is done, but for the first time when you have to do all reviews etc.
15:33:56 * Kevin_Kofler doesn't appreciate it.
15:34:01 <Kevin_Kofler> 1. A lot more packaging work.
15:34:12 <jreznik> that can be scripted
15:34:26 <Kevin_Kofler> 2. Circular dependencies, and the hacks upstream comes up with to avoid them don't always help us.
15:34:44 <rdieter> kf5 shouldnt have any circular deps
15:34:48 <tosky> there should be no circular dependencies in Tier 1 and Tier 2 frameworks at least
15:34:57 <Kevin_Kofler> (In particular, plugins that are loaded at runtime, because then we have to add runtime Requires, and since those are also dragged in at build time, the dependency is still circular for us.)
15:35:23 <Kevin_Kofler> tosky: Even at runtime? (See above.)
15:35:35 * rdieter thinks we're heading into offtopic-for-meeting territory
15:35:51 <Kevin_Kofler> Of course, we can just leave the Requires off, but then things are not going to work as expected.
15:36:10 <Kevin_Kofler> This has already started in KDE 4 with kate-part.
15:36:27 <Kevin_Kofler> Now all the apps that use KTextEditor need to have a Requires: kate-part or they won't work at all.
15:36:41 <Kevin_Kofler> If we had added it to kdelibs (KTextEditor), we'd have had a circular dependency.
15:36:51 <rdieter> Kevin_Kofler: that's one example of a less-than-ideal split
15:37:10 <rdieter> but one bad example shouldn't mean it should never be done either
15:37:22 <Kevin_Kofler> Conceptually, the right place for kate-part is along with KTextEditor, which has been the setup in the past, until it got changed to a purely developer-centric organization that just screws packagers over.
15:37:48 <rdieter> Kevin_Kofler: +1
15:38:14 <Kevin_Kofler> And there's also a 3. Many many dependencies to track.
15:38:33 <Kevin_Kofler> With Frameworks, it's going to be particularly painful to get the BuildRequires for every package right.
15:39:00 <Kevin_Kofler> So far, every KDE app needed BR kdelibs4-devel and that was about it. (Some needed kde-workspace-devel or such, but in principle kdelibs4-devel was the thing.)
15:39:26 <Kevin_Kofler> Now you need to run cmake to even know what is required (or recursively scan all the CMakeLists.txt files).
15:39:34 <tosky> it will be there just at the beginning, then it's not going to change too much
15:39:57 <Kevin_Kofler> tosky: It'll still be a problem for every new app.
15:40:27 <tosky> no more than what happens when you have many non-KDE dependencies
15:40:33 <Kevin_Kofler> Of course, we could ship a kf5-devel metapackage that just drags in everything, but I suppose BR kf5-devel would be frowned upon even if we ship that.
15:41:18 <tosky> anyway, about this point of discussion (Plasma Next), is there something specific to discuss/decide?
15:42:38 <Kevin_Kofler> Looks like not, so let's move on.
15:42:49 <Kevin_Kofler> #topic Fedora Plasma Product
15:42:57 <Kevin_Kofler> Any news/updates there?
15:43:26 * ltinkl back
15:43:29 <rdieter> there was some feedback onlist, even if a lot of it wasnt particularly good or relevant
15:43:33 <Kevin_Kofler> The improvements to the PRD I suggested last week were made.
15:43:51 <rdieter> but happy the discussion happened nonetheless
15:43:58 <ltinkl> what do you think? should we submit this to fesco?
15:44:04 <rdieter> submit +1
15:44:08 <Kevin_Kofler> "Target Audience Case 1: Scientist" could benefit from a list of concrete apps, can I add some?
15:44:09 <ltinkl> jreznik: ^^ especially
15:44:16 <ltinkl> Kevin_Kofler: sure, go ahead
15:44:46 * jreznik did a few changes there too - especially some clear copy-paste from WS
15:44:49 <tosky> rdieter: public list?
15:44:54 <Kevin_Kofler> In particular, I'd list "Cantor, …" for numerical tools (leaving the "…" intentionally unspecified) and Kile for typesetting.
15:45:01 <ltinkl> Kevin_Kofler: yup
15:45:11 <rdieter> tosky: yes, https://lists.fedoraproject.org/mailman/listinfo/kde
15:45:21 <jreznik> ltinkl: I'd say yes - file a ticket, it's better to have it earlier than later and I expect many comments, so
15:45:31 <rdieter> in particular, thread starting here, https://lists.fedoraproject.org/pipermail/kde/2014-March/013196.html
15:45:53 <Kevin_Kofler> Should I also mention LyX for typesetting? (Do scientists actually use that? All the ones I know use raw LaTeX, i.e. Kile or some other LaTeX or plain text editor.)
15:45:58 <ltinkl> rdieter: so, can you please send it to fesco, with your fesco liason hat on? :)
15:46:15 <ltinkl> rdieter: (after the meeting)
15:46:16 <rdieter> ltinkl: ok, forgot about that hat. :-0
15:46:30 <jreznik> Kevin_Kofler: do it, even LyX could be worth there
15:47:20 <jreznik> would be nice to file it asap for tomorrows meeting before agenda is prepared
15:47:26 <Kevin_Kofler> https://fedoraproject.org/wiki/Fedora_Plasma_Product/PRD#Case_1:_Scientist
15:47:27 <jreznik> that reminds me to do it too :D
15:49:15 <ltinkl> also a small reminder, there is still a lot of open/TODO items in https://fedoraproject.org/wiki/Fedora_Plasma_Product/Integration
15:51:12 <Kevin_Kofler> Oh, for "Data Analysis, statistics & visualizations", there's RKWard as an obvious candidate, and LabPlot2 worth mentioning too, I'm adding those, too.
15:52:02 <Kevin_Kofler> The "Electronic lab" and "Robotics" stuff should probably point to the work done by the existing SIGs.
15:53:41 <ltinkl> #action rdieter to submit the Fedora Plasma Product proposal to Fesco
15:57:42 <Kevin_Kofler> IMHO, https://fedoraproject.org/wiki/Fedora_Plasma_Product/Integration should also mention kimapplet.
15:57:59 <Kevin_Kofler> So far, we have always chickened out of that.
15:58:00 <ltinkl> Kevin_Kofler: feel free to add it
15:58:23 <Kevin_Kofler> Proper input method support really means shipping the native KDE applet for that, and ensure we don't get the GTK+ stuff running.
15:58:44 * ltinkl agrees
15:59:12 * Kevin_Kofler also strongly objects to Firefox as a default browser!
15:59:18 <Kevin_Kofler> Either Konqueror or Rekonq.
15:59:34 <Kevin_Kofler> Firefox doesn't even have KDE integration enabled in Fedora.
15:59:35 <jreznik> IE!
15:59:38 <Kevin_Kofler> And I doubt it will ever be.
15:59:44 <Kevin_Kofler> So it's a complete no go for us.
16:00:18 <ltinkl> well, other distros ship Firefox with KDE integration
16:00:21 * Kevin_Kofler is partial to Konqueror, but could live with Rekonq as a default… as long as it's a KDE app!
16:00:26 <jreznik> that's tough question - we should allow good browser experience, where rekonq/konqueror are not yet there
16:00:32 <Kevin_Kofler> ltinkl: Good luck getting our Firefox maintainer(s) to approve that.
16:00:33 <jreznik> but also firefox is...
16:00:52 * jreznik has to use firefox as it at least work somehow (and it's laggy as...)
16:01:00 <Kevin_Kofler> jreznik: Uh, almost all websites just work with QtWebKit.
16:01:21 <Kevin_Kofler> KHTML is getting less and less supported due to rampant JavaScript abuse, but QtWebKit tends to just work.
16:01:25 <ltinkl> Kevin_Kofler: all websites that you visit ;)
16:01:35 <jreznik> Kevin_Kofler: it's far away from "work" unfortunately
16:02:04 <tjanez> hi
16:02:10 <Kevin_Kofler> In its current state, Firefox is not an acceptable default for a KDE spin.
16:02:38 <ltinkl> Kevin_Kofler: we'll see about that, that's why it's in the TODO list, with a question mark
16:02:56 <Kevin_Kofler> I want this changed right now, to not even suggest Firefox.
16:03:58 <Kevin_Kofler> As I said, it should say "Konqueror+kwebkitpart or Rekonq".
16:04:13 <rdieter> Kevin_Kofler: we can vote on it if you want
16:04:54 <ltinkl> ye, we can vote on it, after the meeting, this is not part of the Product proposal
16:04:58 <Kevin_Kofler> It's a KDE spin, it should use KDE apps.
16:05:05 <Kevin_Kofler> Firefox drags in many GNOME dependencies.
16:05:16 <Kevin_Kofler> Plus the (now bundled (ewww!)) xulrunner.
16:05:20 <Kevin_Kofler> It's HUGE.
16:05:44 <Kevin_Kofler> In addition to the 2 HTML engines we already (have to) ship (KHTML and QtWebKit).
16:05:55 <ltinkl> ok, we're running out of time for this meeting, any final thoughts/objections to the PRD?
16:06:06 <rdieter> where is it listed btw?
16:06:09 <Kevin_Kofler> It's just not practical to drag in Gecko.
16:06:18 <Kevin_Kofler> https://fedoraproject.org/wiki/Fedora_Plasma_Product/Integration – Default apps.
16:06:30 <rdieter> ah, Integration
16:07:03 <Kevin_Kofler> Firefox is a bad idea both from a technical standpoint (its own HTML engine, non-KDE dependencies) and from a user experience standpoint (no KDE integration).
16:07:31 <rdieter> ltinkl: looks like no :)
16:07:48 * jreznik thinks product should not be kde only but best tools to achieve goals in use cases but prefer kde/qt tech, where it makes sense
16:07:51 <ltinkl> ok
16:08:02 * rdieter agrees with jreznik
16:08:03 <Kevin_Kofler> ltinkl: I take it that Integration is not part of the PRD, because I definitely object to that one as long as Firefox is on it!
16:08:22 <Kevin_Kofler> jreznik: For the browser, it definitely makes sense.
16:08:32 <ltinkl> Kevin_Kofler: it's not, that's why it lives separately now, should ideally become part of the Tech Specs
16:08:32 <Kevin_Kofler> There are at least 2 KDE browsers that we can ship.
16:09:05 * redi_ has an almost universally better user experience with firefox than konqui
16:09:08 <Kevin_Kofler> I also think that being KDE-only should be a goal.
16:09:14 <ltinkl> #endmeeting