15:08:32 <rdieter> #startmeeting kde-sig
15:08:32 <zodbot> Meeting started Tue Aug 26 15:08:32 2014 UTC.  The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:08:32 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:08:36 <rdieter> #topic roll call
15:08:50 <rdieter> hi all, friendly kde-sig meeting , who's present today?
15:09:31 <dvratil> hi
15:09:39 <tosky> hi
15:09:53 <pino|work> me
15:09:56 <jgrulich> hi
15:10:15 <Kevin_Kofler> Present.
15:11:02 <rdieter> #info rdieter dvratil tosky pino|work jgrulich Kevin_Kofler present
15:11:08 <rdieter> #chair dvratil tosky pino|work jgrulich Kevin_Kofler
15:11:08 <zodbot> Current chairs: Kevin_Kofler dvratil jgrulich pino|work rdieter tosky
15:11:13 <rdieter> #topic agenda
15:11:19 <rdieter> ok, agenda, what to discuss today?
15:13:39 <rdieter> I can't think of anything offhand, anyone else?
15:13:50 <dvratil> looks like a short meeting today :)
15:15:02 <Kevin_Kofler> Getting Plasma 5 into Rawhide maybe?
15:15:11 * danofsatx-work has arrived
15:15:19 <Kevin_Kofler> Now that F21 has branched, we should start getting stuff done in Rawhide for F22+.
15:15:24 <rdieter> #info danofsatx-work present
15:15:32 <rdieter> Kevin_Kofler: good point, agreed
15:15:39 <rdieter> lets go with that for now
15:15:40 <Kevin_Kofler> We aren't going to ship another release with 4.11.x LTS, are we?
15:15:49 <rdieter> #topic plasma5 status, ready for reviews/rawhide ?
15:16:05 <dvratil> jgrulich, ^^ moar reviews! :)
15:16:19 * rdieter is ready to help with reviews more this round
15:16:39 <dvratil> I have the specfiles from Copr, so packages are done - all deps are in Rawhide already, so it's just about submitting the couple packages for review
15:16:39 <rdieter> any estimate the number of packages involved brining in plasma5 stuff?
15:16:42 <jgrulich> dvratil: great!!
15:16:44 <danofsatx-work> dvratil: do you have a quick how-to anywhere on upgrading to 5?
15:16:59 <danofsatx-work> (in F20, at least)
15:17:07 <rdieter> danofsatx-work: http://copr.fedoraproject.org/coprs/dvratil/plasma-5/
15:17:14 <dvratil> plasma5 copr is ~20 packages
15:17:25 * Kevin_Kofler is curious how slowly that thing will crawl on llvmpipe on a P4, seeing how OpenGL 2 is now a requirement. :-(
15:18:01 <rdieter> once plasma5 is in, I assume any kde4 plasma applets need porting or retirement?
15:18:07 <dvratil> does anyone know when KDE Applications 14.something  (or whatever is the official name now) are going to be released?
15:18:08 <danofsatx-work> oh, that wasn't there the last time I looked. thanks dvratil
15:18:21 * rdieter looks on techbase
15:18:21 <Kevin_Kofler> Yeah, like for Kicker applets back in F9.
15:18:22 <tosky> dvratil: it's 14.12, guess when...
15:18:27 <dvratil> tosky, thanks
15:18:37 <dvratil> that's in time for F22, right?
15:18:46 <dvratil> so we will have additional packages with Applications
15:18:48 <tosky> rdieter, Kevin_Kofler: yes, applets needs to be ported, I think part of kdeplasma-addons have been ported or dropped during Randa
15:18:57 <tosky> dvratil was there, so he can say more
15:19:07 <rdieter> https://techbase.kde.org/Schedules only mentions frameworks and plasma5, nothing about applications yet
15:19:07 <dvratil> dvratil wasn't active in this area :)
15:19:20 <Kevin_Kofler> tosky: More than kdeplasma-addons, I'd be worried about all the third-party kde-plasma-stuff.
15:19:28 <tosky> rdieter: right, send a nag $somewhere, it was on Albert's blog
15:19:50 <rdieter> ok, <nod>, could've sworn I'd heard or read something
15:20:03 <tosky> that's why maybe it's a bit early to think about switching (/me runs away avoiding the hammers)
15:20:18 <rdieter> tosky: true too
15:20:36 <rdieter> that doesn't mean we can't start reviewing stuff, just don't build anything yet until we're more certain
15:20:41 <Kevin_Kofler> The plan that Albert announced is: Frameworks feature release every 1 month, Plasma every 3 months (with monthly bugfix releases), Applications every 4 months (with monthly bugfix releases).
15:20:44 <dvratil> well, Plasma 5 is there already, that's fine. For apps: the KDE 4 apps work perfectly with Plasma 5
15:21:12 <dvratil> so if apps are late and suck, we just don't ship them and only ship Plasma 5 - and people will just use the "old" Dolphin, etc.
15:21:13 <dvratil> PIM
15:21:25 <Kevin_Kofler> If I compute the lowest common multiple, that means a new release of everything together only once a year, and within that year, a big mess.
15:22:04 <tosky> no, I guess the releases will be never together
15:22:18 <tosky> just use different day of the month
15:22:23 <tosky> it's happening now
15:22:33 <Kevin_Kofler> Just to make it even more of a mess.
15:22:55 <Kevin_Kofler> They even admitted to doing that on purpose just so people stop talking about a SC.
15:23:16 <rdieter> so, anyone have any reservations or objections to targetting f22 for initial plasma5 introduction?
15:23:26 <Kevin_Kofler> dvratil: Of course. That's what we did for F9 too. (Shipped with kdepim 3.5, and also KDE 3 versions of the third-party/extragear/… apps.)
15:24:00 <Kevin_Kofler> This time, upstream is even hinting us at it by making a mixed kdelibs4/KF5 apps release.
15:24:16 <rdieter> I can work on some f22/plasma5 tracker bugs
15:24:30 <Kevin_Kofler> Integration will suffer, but we made it work more or less in F9.
15:24:41 <Kevin_Kofler> The problem this time will be that upstream now defaults to different settings dirs.
15:24:41 <tosky> rdieter: is this just the initial proposal, right? What is the deadline for the decision (more or less, month)?
15:24:47 <Kevin_Kofler> So settings can get out of sync.
15:25:08 <rdieter> tosky: a long ways methinks, I don't think a fedora 22 schedule exists yet (but I'll look now)
15:25:12 <Kevin_Kofler> We didn't have this problem in F9, where we decided (unlike some other distros) to stick with upstream defaults and put all settings into ~/.kde.
15:25:41 <tosky> rdieter: if it follows the old "6 month", wll it be let say around March next year, or before?
15:26:01 <rdieter> http://fedoraproject.org/wiki/Releases/22/Schedule  , is pretty sparse on details yet
15:26:14 <rdieter> tosky: yeah, approximately
15:26:41 <tosky> which means, uhm, at least two other revisions of plasma 5
15:27:04 <rdieter> yes
15:27:49 <Kevin_Kofler> Around feature freeze, we'll have something like 5.3.0 ± 1 release (i.e., 5.2.3, 5.3.0 or 5.3.1) depending on slippage.
15:27:56 <Kevin_Kofler> Final release will be in the 5.3.x phase.
15:28:06 <Kevin_Kofler> So I guess we'd target 5.3 either way.
15:28:11 * than is present
15:28:15 <Kevin_Kofler> Assuming both projects stick to their planned schedules.
15:28:22 <rdieter> #info than present
15:28:27 <rdieter> #chair than danofsatx-work
15:28:27 <zodbot> Current chairs: Kevin_Kofler danofsatx-work dvratil jgrulich pino|work rdieter than tosky
15:29:28 <tosky> this is the default, but will workspace 4.11 be still available?
15:29:41 <rdieter> tosky: no, they are not parallel-installable
15:29:47 <Kevin_Kofler> Apps will probably be at 14.12, getting 15.4 in could be tough if F22 releases in May, impossible if it releases in March or early April.
15:29:54 <rdieter> that's why no plasma5 is in fedora yet
15:30:36 <rdieter> tosky: perhaps we or some enterprising soul could create a 3rd-party copr/repo for anyone interested in that though
15:30:58 <Kevin_Kofler> Don't forget that F21 will get updates (security ones at the very least) until 1 month after the F23 release.
15:31:21 <Kevin_Kofler> So people don't have to rush to F22 immediately if they don't want Plasma 5.
15:31:35 <tosky> rdieter: so does fedora policy disallow packages which are mutually incompatible?
15:31:41 <Kevin_Kofler> Also don't forget that we'd be shipping something like 5.3.2.
15:31:45 <rdieter> tosky: in general, yes
15:31:55 <Kevin_Kofler> Not like 4.0.3 as in F9. :-)
15:32:22 <Kevin_Kofler> I think that F22 is the right time to get Plasma 5 in.
15:33:01 <Kevin_Kofler> I must say I'm not sure I like Plasma 5 (I hope I won't curse at it like at KMail 2!), but delaying the introduction is not going to solve the problem if there is one.
15:33:28 <rdieter> tosky: do you think not having kde-workspace-4.x available anymore will be problem?
15:34:20 <Kevin_Kofler> tosky: Also don't forget that 4.11.x LTS will eventually get EOLed. (Current plans are: Support it for 1 more year, IF there are bugfixes going in that make it worth doing releases.)
15:34:21 <tosky> rdieter: I personally still think there are rough edges which will be polished in the time, when more applications are fully ported (retrofeedback on frameworks, feedback on plasma)
15:34:26 <rdieter> it may be a good idea to keep the possibility of having kde-workspace-4.x somewhere (like the 3rd-party repo option)
15:34:34 <tosky> things that couldn't be figured before doing the real porting job
15:35:02 <rdieter> tosky: understood, agreed
15:35:30 <Kevin_Kofler> tosky: The big problem with supporting both is that it conflicts with providing an upgrade path that Just Works.
15:36:04 <Kevin_Kofler> A working upgrade path uses packages with the same name and higher EVR, or an Obsoletes on the old NEVR.
15:36:50 <Kevin_Kofler> But of course, if the old version is getting upgraded or Obsoleted, you can't install it without playing with ugly stuff like "yum downgrade" (or "rpm -Uvh --oldpackage") and exclude lists.
15:37:27 <rdieter> I can commit to providing kde-workspace-4.x somehow, if there's demand/use-case for it
15:37:32 <Kevin_Kofler> Letting users choose means to use Conflicts instead, but then you fail to upgrade existing Plasma 4 users to 5, they'd have to move manually.
15:38:02 <rdieter> implemented via playground or copr repo probably, but that detail doesn't matter much (yet)
15:38:23 <Kevin_Kofler> That issue is why we went for KDE 4 only in F9 and why I'm still sceptical about the idea of providing both.
15:38:32 <tosky> better to move the discussion out of this, I thought it could be possible to provide an double upgrade path (from 4.11 and for 5.3) in f23
15:38:55 <Kevin_Kofler> It would be possible, yes.
15:39:13 <Kevin_Kofler> But then, if you upgrade from F21, you get a different KDE by default than if you install a fresh F22 KDE, is that really what we want?
15:39:41 <Kevin_Kofler> Sorry, s/KDE/Plasma/g if you're pedantic. :-)
15:40:33 <rdieter> Kevin_Kofler: we won't be providing both (officiallyl)
15:40:34 <Kevin_Kofler> And I'm also worried that users would get used to the double offering and complain loudly about getting upgraded to Plasma 5 in F23.
15:40:41 <tosky> uhm, it could be a conservative choice; maybe there are past examples where it was done (or not done) to take inspiration
15:41:06 <tosky> well, f23 will be more than one year from now, so far enough
15:41:26 <Kevin_Kofler> rdieter: As I understand tosky's proposal, it was to provide both (with upgrade path for F21→F22 = keep what the user had) and to upgrade both to Plasma 5 for F22→F23.
15:41:36 <tosky> just asking :)
15:41:53 <Kevin_Kofler> tosky: -1 to your proposal, on practical grounds.
15:42:09 <rdieter> Kevin_Kofler: ok, consider me not in favor of that (mostly as you mentioned, it isnt practical)
15:42:26 <Kevin_Kofler> It also means having 3 (!) different variants for packaging: F21 where we only officially support Plasma 4, F22 where we have both, and F23 where we only support Plasma 5.
15:43:21 <Kevin_Kofler> Just moving F22 to Plasma 5 means we have only 2 variants (and for the Plasma 5 packages, basically only 1, because the Copr works similarly as F22 will work, upgrading the Plasma 4 packages).
15:43:56 <danofsatx-work> just a heads up - konversation is wigging out on me again. I'm probably going to be quiet the rest of the meeting.
15:44:05 <Kevin_Kofler> To support coexistence in F22, we'd have to change the packages to use Conflicts instead of Obsoletes, and then change them back for F23, no thanks!
15:45:40 <tosky> ack, ack, let's move if there are other points, the time is running
15:46:09 <Kevin_Kofler> I don't think there are other points. :-)
15:46:12 <rdieter> anything else plasma5 related, or move on?
15:46:40 <rdieter> moving on...
15:46:52 <rdieter> #topic open discussion
15:47:01 <rdieter> anything else before closing the meeting?
15:47:17 <Kevin_Kofler> So, one more thing…
15:47:25 <Kevin_Kofler> Somehow but not entirely related to Plasma 5.
15:47:42 <Kevin_Kofler> Do we have a plan how to deal with the monthly KF5 releases (mixed bugfix and features)?
15:48:03 <Kevin_Kofler> I think we want to import those all, assuming they don't start breaking sonames all over the place.
15:48:11 <jgrulich> as I know KF5 don't have bugfix releases
15:48:20 <Kevin_Kofler> (i.e. push them as updates)
15:48:28 <Kevin_Kofler> jgrulich: Right, they'll be mixed everything, Firefox-style.
15:48:36 * rdieter can polish the build-it script for use with kf5/plasma5 too
15:49:25 <Kevin_Kofler> Do we have agreement in principle that we'll want to push KF5 releases as updates to stable Fedora? (I'm for it (+1), as you may have guessed. :-))
15:49:26 <rdieter> Kevin_Kofler: I assume we'd want to pull in releases as they become available
15:49:56 <rdieter> +1 in general, modulo dependency changes
15:50:39 <Kevin_Kofler> Dependencies can be hacked around (see Qt 5.3). :-)
15:51:18 <rdieter> my point is accept all as default, and review dependency changes on a case-by-case basis
15:51:39 <Kevin_Kofler> That's of course necessary, agreed.
15:52:41 <Kevin_Kofler> It might also be possible to upgrade only individual Frameworks, though that could also end up involving dependency hackery (tell this Tier 3 that it'll build just fine with that old Tier 1 no matter what the upstream CMakeLists.txt claims).
15:53:06 <Kevin_Kofler> I'd only try doing that if we really can't upgrade some Tier 1 or 2 Framework.
15:53:36 <rdieter> yeah, let's not go there unless we really can't avoid it :)
15:53:57 <Kevin_Kofler> In general, we'll just want to upgrade the whole thing as a group.
15:55:41 <Kevin_Kofler> One thing to take care of will be that I have been warned that Plasma 5.x (at least 5.x.0) releases will likely always depend on the latest Frameworks.
15:56:19 <Kevin_Kofler> So if we want to push Plasma 5 updates, we need to push the Frameworks update first (or together, SC-style).
15:56:50 <Kevin_Kofler> Some applications could also end up like that.
15:59:31 <Kevin_Kofler> I think that's all on the practical stuff.
15:59:52 <rdieter> ok, time's about up, let's close, thanks everyone!
15:59:57 <Kevin_Kofler> The uncoordinated releases will surely be more work for us, but it's unfortunately upstream's decision, not ours. But we should be able to deal with it.
15:59:59 <tosky> I (personally) think the "on the latest KF5" could change when KF5 is more stable
16:00:25 <tosky> even in the 4.x world many SC applications could really use an old kdelibs
16:00:37 <tosky> but yeah, let's see
16:00:46 <rdieter> #endmeeting