15:04:54 <Kevin_Kofler> #startmeeting KDE SIG Meeting
15:04:54 <zodbot> Meeting started Tue May 27 15:04:54 2014 UTC.  The chair is Kevin_Kofler. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:04:54 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:05:00 <Kevin_Kofler> #meetingname kde-sig
15:05:00 <zodbot> The meeting name has been set to 'kde-sig'
15:05:03 <Kevin_Kofler> #topic Role call
15:05:08 * Kevin_Kofler is present, who else?
15:05:17 * jgrulich is present
15:05:18 * rkratky is here
15:05:18 * satellit_e listening
15:05:28 <than> present
15:05:45 <rdieter> here (eventually... another ~5 min)
15:07:20 <danofsatx-work> here
15:08:42 <dvratil> hi
15:09:04 <tosky> here
15:09:55 <Kevin_Kofler> #chair jgrulich rkratky than rdieter danofsatx-work dvratil tosky
15:09:55 <zodbot> Current chairs: Kevin_Kofler danofsatx-work dvratil jgrulich rdieter rkratky than tosky
15:10:37 <Kevin_Kofler> #info Kevin_Kofler, jgrulich, rkratky, than, rdieter, danofsatx-work, dvratil, tosky present.
15:10:43 <Kevin_Kofler> #topic Agenda
15:10:56 <dvratil> KF5 import update
15:11:25 <Kevin_Kofler> rdieter proposed talking again about whether and how we want to do a KDE/Plasma product for "Fedora next".
15:11:38 <pino|work> metoohere
15:11:47 <Kevin_Kofler> #chair pino|work
15:11:47 <zodbot> Current chairs: Kevin_Kofler danofsatx-work dvratil jgrulich pino|work rdieter rkratky than tosky
15:11:52 <Kevin_Kofler> #info pino|work also present.
15:12:05 <dvratil> Kevin_Kofler, maybe wait for ltinkl with that?
15:12:21 <Kevin_Kofler> Any idea where he is?
15:12:28 <dvratil> I  justpinged him
15:13:04 <Kevin_Kofler> Let's start with the KF5 import update.
15:13:09 <Kevin_Kofler> #topic KF5 import update
15:13:13 <Kevin_Kofler> dvratil: Your turn.
15:13:23 <jgrulich> I pinged him before 2 hours and no response since then
15:13:46 <dvratil> jgrulich finished all reviews of Tier 1 and I just got tons of email that all repos were set up, so I'll import and build all Tier 1 packages today
15:14:02 <dvratil> I'll submit Tier 2 later today, or tomorrow
15:14:31 <dvratil> Tier 2 is very small, so I expect it to be done quickly, and then I'll start imporint Tier 3
15:14:52 <dvratil> that's about it :-)
15:15:17 <Kevin_Kofler> Tier 3 is where the bulk of the stuff lies, right?
15:15:41 <dvratil> yeah. And they have inter-dependencies, so they need to be built in strict order
15:16:16 <Kevin_Kofler> #info KF5 tier 1 passed all package reviews.
15:16:22 <dvratil> which is fine since we are pushing to rawhide now, but it will be major PITA once it goes stable and we will need to set up build orverride for each package
15:16:25 <Kevin_Kofler> #action dvratil will import and build all tier 1 packages today.
15:16:31 * dvratil will have to write a script for that :)
15:16:53 <Kevin_Kofler> dvratil: I think using a dedicated buildroot is the better solution there.
15:16:58 <Kevin_Kofler> Just as for the KDE 4 updates.
15:17:09 <dvratil> yup, will work too ;)
15:18:50 <Kevin_Kofler> What about my request for qt5-devel and kf5-devel metapackages that Require qt5-*-devel resp. kf5-*-devel?
15:19:15 * Kevin_Kofler wants to be able to BR kf5-devel rather than a bazillion packages that is different from package to package and can change from release to release.
15:19:27 <dvratil> you don't want to BR kf5-devel
15:19:35 <Kevin_Kofler> (It'd also help for a KF5 version of our kde4foo.spec.)
15:19:51 <Kevin_Kofler> Sure I do. I'd BR *-devel if that were possible/allowed…
15:19:56 <dvratil> that will will be the same as BR kdelibs-devel - it will drag in *everything* and even more than kdelibs - which is exactly what kde frameworks are supposed to solve
15:20:13 <Kevin_Kofler> BR kdelibs4-devel was great, all KDE packages needed that and just that.
15:20:52 <Kevin_Kofler> (well, some of them needed more stuff (e.g. kde-workspace-devel), but usually kdelibs4-devel was all they needed from KDE)
15:21:04 <Kevin_Kofler> I want the same for kf5-devel.
15:21:06 <dvratil> yes, which sucks
15:21:10 <Kevin_Kofler> I don't see the point of the splits to begin with.
15:21:29 <Kevin_Kofler> So I want something that works around that nonsense so that my work as a packager doesn't become a PITA.
15:21:34 <Kevin_Kofler> Is that so hard to understand?
15:21:35 <dvratil> it allows you to ship only the bare minimum that apps depend on
15:21:38 <Kevin_Kofler> Yes, I'm lazy like that.
15:21:43 <tosky> is the point of this package to have a unique dependency in package? If yes, I think it's the wrong approach
15:21:53 <Kevin_Kofler> The runtime deps will be only the necessary ones anyway!
15:22:14 <Kevin_Kofler> The metapackage would just simplify our BRs in all KF5-based packages.
15:22:45 <tosky> that's exactly going the opposite direction of the idea of Frameworks
15:22:57 <Kevin_Kofler> RPM is smart enough to figure out that you don't need a dep on, say, kf5-plasma, if nothing links to it, even if you had kf5-plasma-devel in the buildroot.
15:23:06 <Kevin_Kofler> Having too much in the buildroot isn't going to hurt anybody.
15:23:14 <dvratil> it slows down the build
15:23:19 <Kevin_Kofler> It takes a few seconds more of build time, sure.
15:23:37 <dvratil> with the slowness of yum and Koji? It's gonna be more than that
15:23:37 <Kevin_Kofler> But most time does not go into installing packages (and downloading them once, then they're cached).
15:23:59 <dvratil> FWIW I already packaged about dozen "KDE 5" apps and yes, I had to copy a longer list of deps from CMakeLists.tx and that was it. Took me about 1 minute instead of 10 seconds
15:24:10 <jgrulich> yeah, and yum-builddep foo will automatically install all kf5-*-devel packages → nonsense
15:24:20 <Kevin_Kofler> Building the SRPM and actually building the package take at least as much time and those are not affected at all by having a "wildcard" (metapackage) BR.
15:24:43 <Kevin_Kofler> jgrulich: Who cares? yum-builddep is something only a handful people use.
15:24:55 <Kevin_Kofler> 99% of our users won't notice the difference, and it makes our jobs a lot easier.
15:25:20 <Kevin_Kofler> Also ensures we won't accidentally build a package without some optional features just because we forgot one of the bazillion kf5-*-devel BRs.
15:25:43 <pino|work> reading build logs, this unknown...
15:25:43 <Kevin_Kofler> And tosky, yes, it goes against the idea of Frameworks, but I'm opposed to the idea to begin with. This works around the worst part of it.
15:26:04 <Kevin_Kofler> pino|work: Well, go read them then, and see how often things are accidentally missing!
15:26:21 <Kevin_Kofler> Many times that I read a build.log for some other reason, I notice missing BRs.
15:26:32 <pino|work> i do read the build log of whatever i upload to debian, yes
15:26:42 <pino|work> if you don't do, that bad for you, really
15:26:48 <dvratil> I think that's part of packager's job
15:26:49 <jgrulich> Kevin_Kofler: and how many KF5 packages do you maintain that it should help you with your packaging work?
15:26:50 <tosky> the solution is fix the dependency, not trow in all the possible dependencies
15:27:06 <Kevin_Kofler> The build logs don't get read at every new version, but BRs can change each time.
15:27:14 <tosky> so users will continue to thing that "KDE is bad, it installs everything!"
15:27:31 <Kevin_Kofler> jgrulich: I will be comaintaining dozens when KF5 starts replacing kdelibs4 in apps.
15:27:40 <Kevin_Kofler> (see how many kdelibs4 packages I now comaintain)
15:28:23 <Kevin_Kofler> tosky: It will NOT install everything for users.
15:28:30 <Kevin_Kofler> Users don't care about BuildRequires.
15:28:31 <jgrulich> also once the BR are collected, you don't care about them in future
15:28:43 <Kevin_Kofler> They care about runtime Requires and those are automatically detected by RPM anyway.
15:28:55 <Kevin_Kofler> So it will NOT drag in extra packages for our users.
15:29:00 <Kevin_Kofler> Just make our work as packagers easier.
15:29:08 <Kevin_Kofler> jgrulich: Not true. New BRs can be added.
15:29:10 <tosky> point taken, but still it's not the logical solution
15:29:22 <Kevin_Kofler> (That's how most of the missing non-KDE ones now happen, and it'll also happen with kf5-*-devel.)
15:29:44 <Kevin_Kofler> Upstream adds a new BR, makes it optional, we don't notice, the stuff doesn't get built.
15:30:04 <Kevin_Kofler> Worst case, the new BR is even needed for a feature that worked without the BR before. (Yes, we've had THAT happen all too often, too.)
15:30:20 <pino|work> if the new BR is not a kf5 framework, your solution will solve nothing
15:30:35 <Kevin_Kofler> Of course, the solution will not solve the non-KDE ones.
15:30:43 <Kevin_Kofler> It just prevents it getting INTRODUCED also for KDE ones now.
15:30:54 <Kevin_Kofler> (which wasn't an issue at all with good old kdelibs4-devel)
15:30:57 <pino|work> you need to a) diff previous version against new version b) read logs, in any case
15:31:23 <Kevin_Kofler> We actually need an option to fail the build on any missing optional deps that are not explicitly disabled on the CMake command line.
15:31:39 <jgrulich> if it would be just a few packages then I'm fine with that, but that's too many packages to be all installed automatically
15:31:40 <Kevin_Kofler> (That option, we'd set for RPM builds.)
15:32:00 <Kevin_Kofler> jgrulich: Again, it'd be used only at build time.
15:32:21 <jgrulich> and koji builds will be ten times slower
15:32:28 <Kevin_Kofler> Nothing is going to be INSTALLED on the users' systems (unless they explicitly install kf5-devel, and then they actually WANT all those packages, it's also a use case I'd expect!).
15:32:52 <Kevin_Kofler> jgrulich: Time the builds, come back when you have the data.
15:33:11 <rdieter> (back finally, sorry).  It's not as bad either way, but let me go on record to say I'm opposed to any metapackage proposal, currently
15:33:14 <Kevin_Kofler> 10 times is WAY overblown.
15:33:48 <Kevin_Kofler> Maybe 5%, on packages that build one .cpp file and ship that.
15:33:55 <rdieter> how many core kf5 packages are there?
15:34:04 <Kevin_Kofler> (and for those, you'd still have the option of BRing the individual kf5-*-devel stuff)
15:34:09 <Kevin_Kofler> rdieter: Core? I don't want core!
15:34:17 <Kevin_Kofler> I want kf5-devel to drag in ALL tier 1, 2 and 3 frameworks.
15:34:40 <rdieter> don't change my question, ok, rephrase: how many tier 1 pkgs are there?
15:35:07 <Kevin_Kofler> How's that relevant to the discussion?
15:35:27 <rdieter> Kevin_Kofler: we can stop the discussion right now if you want. :)  you're the only one who wants this.
15:35:38 <rdieter> (afaict)
15:35:42 <Kevin_Kofler> And I don't see what it hurts to HAVE it.
15:35:43 <dvratil> all tiers (including kdepimlibs and couple other unstables) are currently 96 packages
15:35:51 <Kevin_Kofler> I mean, people wouldn't be forced to use the metapackage.
15:36:06 <Kevin_Kofler> You can still BR the world explicitly and be happy with it.
15:36:19 <Kevin_Kofler> But it'd not force everyone to do that just because upstream decided so.
15:36:30 <pino|work> then its usefulness becomes more and more thin...
15:36:48 <Kevin_Kofler> What does it hurt to have such a metapackage?
15:37:01 <Kevin_Kofler> I expect third-party packagers to love that, too.
15:37:09 <rdieter> Can consider it later, or heck, feel free to submit one
15:37:22 <rdieter> kf5 import doesn't block on this (or vice-versa)
15:37:46 <rdieter> tech call here, afk again, sorry
15:39:03 <Kevin_Kofler> Well, logically, the right place for kf5-devel is as a subpackage of that kf5.spec.
15:41:10 <Kevin_Kofler> I don't want to have to choose between 2^96=79228162514264337593543950336 different combinations of BRs for my packages.
15:42:36 <pino|work> just like you told <Kevin_Kofler> 10 times is WAY overblown. eralier, now you're doing the same yourself
15:43:52 <Kevin_Kofler> Let's move on…
15:43:53 <jgrulich> Kevin_Kofler: or you can just simply properly read CMakeLists.txt or CMake output
15:44:21 <Kevin_Kofler> jgrulich: At every single new upstream release…
15:44:23 <rdieter> I guess I'm not opposed to kf5-devel per-se, but I am against using it in official packaging
15:44:24 <Kevin_Kofler> BRs can change.
15:44:34 <pino|work> <pino|work> you need to a) diff previous version against new version b) read logs, in any case
15:44:44 <pino|work> you can do a), filtering on cmake stuff only
15:44:57 <pino|work> (hint: filterdiff, part of patchutils)
15:45:11 <Kevin_Kofler> I guess we won't get to an agreement here… Let's move on.
15:45:13 <Kevin_Kofler> #topic Fedora Next Product
15:45:31 <Kevin_Kofler> So, any update there?
15:45:35 <rdieter> mattdm poked me earlier this morning
15:46:09 <rdieter> sorry, I kinda dropped the ball here, I'll have to dig up tickets to check on the official status wrt workgroup/product plans
15:46:25 <Kevin_Kofler> I'm tending towards the hardline approach of "we want a Product for 'KDE', i.e. Plasma Desktop + kdelibs/KF apps, as such, no more no less".
15:46:33 <Kevin_Kofler> And IMHO *all* desktop environments deserve to be Products.
15:47:44 <rdieter> I wanted to discuss at least, what you all want and how you think we should proceed
15:48:02 * rdieter hunts for relevant fesco/board tickets
15:49:36 <Kevin_Kofler> I wasn't impressed by the feedback to our Plasma Product proposal. They weren't happy with the KDE references that were in there and wanted a pure science focus (also with another name than Plasma) instead.
15:49:44 <rdieter> https://fedorahosted.org/fesco/ticket/1243  F21 kde spin still considered release blocking
15:50:22 <Kevin_Kofler> I think the expectation is also that we'd ship the scientific apps ON the image, which means it'd become very large and less interesting for other user groups.
15:51:03 <rdieter> hrm, I can't browse board tickets (anymore)
15:51:38 <rdieter> I could've sworn somebody had a ticket to ratify our workgroup charter at least
15:51:54 <Kevin_Kofler> Even as a scientist myself, I think that a minimal KDE spin (as now) without any target-specific apps is more useful.
15:51:58 <rdieter> maybe I searched for wrong keywords
15:52:26 <rdieter> ah, here we go
15:52:28 <rdieter> https://fedorahosted.org/fesco/ticket/1265
15:52:50 <rdieter> which references a non-public board ticket, https://fedorahosted.org/board/ticket/177
15:53:02 <rdieter> mattdm: ^^
15:53:11 <Kevin_Kofler> There was also an expectation that we'd steer clear of targeting developers just because Workstation claimed that user base first.
15:53:19 <tosky> uhm, maybe ltinkl has also some feedback (unfortunately he is not around, nor is jreznik)
15:53:28 <rdieter> I guess that's what we're waiting on, answers to:
15:53:34 <Kevin_Kofler> That just makes no sense, GNOME is not suitable for developers at all.
15:53:44 <rdieter> fesco decided: Recommend to the board that they consider this product for F22, and we commit to establishing milestones for it being on target for that in the mean time. For F21 we continue to consider the KDE Spin (or a renamed version) as release blocking. KDE Spin will continue to have a place on the download page for the Fedora Products.
15:53:59 <rdieter> Ask the board a) are they actually okay with a Plasma product in F22, and b) what non-technical criteria should constrain whether we even see fit to bring more product proposals to them in the future?
15:54:11 <Kevin_Kofler> And even on the premise that there should be zero overlap (which IMHO is total nonsense to begin with), who says it shouldn't be THEM who need to change their focus?
15:54:25 <rdieter> so I guess we are blocking on feedback from the board about those topics
15:54:28 <jwb> fwiw, there's an answer to b in the board ticket.  the rest of the board hasn't chimed in on it though
15:54:48 <jwb> the answer to b needs to be applied to a
15:54:49 <rdieter> jwb: mind sharing the answer?
15:54:51 <Kevin_Kofler> "We were there first" is ridiculous, for every new niche, are we going to get into a race of who's going to be allowed to target them?
15:54:52 <jwb> no
15:55:13 <jwb> because the board hasn't agreed to it explicitly, despite repeated attempts by me to get them to say ANYTHING
15:55:30 <tosky> so not even some possible deadline for this decision?
15:55:31 <rdieter> jwb: ok, thanks
15:55:57 <jwb> tosky, it would help if someone asked for an answer by some date i suppose
15:56:08 <jwb> me trying to get them to comment is failing miserably
15:56:30 <tosky> jwb: good point, but isn't there some "mandatory" deadline according for a go/non-go decision?
15:56:31 <Kevin_Kofler> I think having some overlap between the target user bases of desktop spins is going to be unavoidable. (In fact, IMHO, the overlap is a feature, it's called "choice".)
15:56:37 <rdieter> given fesco has already agreed to punt until f22 at least, there certainly isnt a rush, but that's no excuse to delay indefinitely either
15:56:39 <jwb> tosky, for F22?  no
15:56:49 <tosky> jwb: ok, thanks
15:57:54 <rdieter> we may as well move on, no point in rehashing this without the board feedback.  (sorry, for not finding that earlier)
15:58:24 <Kevin_Kofler> #topic Open discussion
15:58:34 <Kevin_Kofler> Well, then we're out of topics, and almost out of time…
15:58:59 <Kevin_Kofler> Anything else before I close the meeting?
15:59:57 <Kevin_Kofler> Well, that's all for today then, thanks for coming, and see you (hopefully) next week!
15:59:59 <Kevin_Kofler> #endmeeting