15:03:40 <rdieter_laptop> #startmeeting kde-sig -- http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2011-07-12
15:03:40 <zodbot> Meeting started Tue Jul 12 15:03:40 2011 UTC.  The chair is rdieter_laptop. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:03:40 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:04:17 <rdieter_laptop> #topic roll call
15:04:22 <Kevin_Kofler> Present.
15:04:22 <rdieter_laptop> who's present today?
15:04:30 * rnovacek here
15:05:02 <rdieter_laptop> than: ping
15:05:22 <than> present
15:05:25 * ltinkl is present
15:05:30 * jreznik is here
15:05:37 <rdieter_laptop> #chair Kevin_Kofler rnovacek than ltinkl jreznik
15:05:37 <zodbot> Current chairs: Kevin_Kofler jreznik ltinkl rdieter_laptop rnovacek than
15:05:52 <rdieter_laptop> #info rdieter Kevin_Kofler rnovacek than ltinkl jreznik present
15:06:17 <rdieter_laptop> #topic kde 4.6.5 status
15:06:25 <rdieter_laptop> hot topic 1: kde-4.6.5 status
15:06:47 <Kevin_Kofler> 4.6.5 has hit updates-testing.
15:07:18 <rdieter_laptop> yay, ltinkl backported an randr-related patch, we can include that build when ready too
15:08:03 <rdieter_laptop> so far, what we have looks solid
15:08:14 <rdieter_laptop> any other comment?
15:08:25 <ltinkl> yup, no problems witnessed so far
15:09:11 <Kevin_Kofler> One comment: Please don't forget to queue the updates when you file them.
15:09:31 <Kevin_Kofler> Thankfully, nucleo noticed they weren't queued and I queued them.
15:09:36 <rdieter_laptop> yeah, seems they'd been pending since last week (friday?)
15:10:10 <rdieter_laptop> anyway, let's move on then...
15:10:17 <rdieter_laptop> #topic kde 4.6.95
15:10:48 <rdieter_laptop> most of this is in rawhide now, sans split stuff pending review (and kde-l10n being worked on now)
15:11:10 <jreznik> two missing pieces - kde-l10n (building it right now), kdebindings partially splitted (pykde4)
15:11:11 <rdieter_laptop> have a few more kdegraphics pieces to review + kdebindings (minus PyKDE4 done already)
15:11:20 <jreznik> that's most important one (pykde4)
15:11:41 * Kevin_Kofler still wonders what the benefit of split kdegraphics packaging is.
15:11:42 <rdieter_laptop> have a few broken deps now due to missing kross(python)
15:12:30 <jreznik> I can help more with reviews but I'm quite busy with other RH work...
15:12:43 <rdieter_laptop> Kevin_Kofler: for one, there were dep failures, due to missing interdependencies not working with the monolithic mash
15:12:58 <rdieter_laptop> *probably* fixable, but...
15:13:48 <Kevin_Kofler> I think fixes for that have been committed to the 4.6 branch, we could have forward-ported them.
15:14:57 <rdieter_laptop> I'd been wanting to split out the libk* and okular for awhile anyway...
15:15:07 <rdieter_laptop> so now seemed a good time to do it
15:16:38 <rdieter_laptop> I was thinking about working on a separate 'kate' package, since the current setup is... painful (it's spread out over 3 packages!)
15:17:21 <jreznik> rdieter_laptop: +1 for separate kate - it's mess
15:17:21 <rdieter_laptop> but that'll need some care
15:17:38 <Kevin_Kofler> It'll also mean adding Requires to all the KatePart-using apps.
15:17:44 <Kevin_Kofler> Right now they get all they need through kdelibs.
15:17:55 <rdieter_laptop> Kevin_Kofler: true ):
15:18:21 <rdieter_laptop> I'm still a little surprised upstream did that apparent break of kdelibs' abi
15:18:53 <jreznik> makes sense to have all kate parts in one released tarball but yes - it's kdelibs's abi breakage
15:18:54 <Kevin_Kofler> AFAIU, it's not technically an ABI break because libktexteditor is still in kdelibs, but nothing actually IMPLEMENTING it is. :-/
15:19:05 <ltinkl> so what about keeping the part in kdelibs + separate kate package?
15:19:10 <Kevin_Kofler> It's a bit like that kdebase-runtime mess.
15:20:24 <jreznik> ltinkl: we don't have to take care too much - only correct katepart requires (in distro)
15:20:30 <jreznik> or as distro
15:20:45 <rdieter_laptop> and... I'm more than a little sad that our (and other distros) concerns and objections wrt tarball splits seem to have been largely ignored...
15:20:58 <Kevin_Kofler> Well, putting the Requires into kdelibs will make the dependency circular.
15:21:04 <Kevin_Kofler> (Same problem as for kdebase-runtime.)
15:21:14 <Kevin_Kofler> Putting it into apps means fixing all the apps.
15:21:50 <rdieter_laptop> maybe kdebase-runtime wouldn't be as bad though
15:22:10 <rdieter_laptop> depends on what the precise BuildRequires: for kate are...
15:22:38 <Kevin_Kofler> I don't think putting the dep into kdebase-runtime is that great an idea.
15:22:54 <Kevin_Kofler> Stuff might be missing the dep on kdebase-runtime the same way they're missing the dep on katepart.
15:22:55 <rdieter_laptop> Kevin_Kofler: it's better than in kdelibs
15:23:20 <rdieter_laptop> Kevin_Kofler: anything missing a dep on kdebase-runtime these days is arguably a bug anyway
15:23:26 <jreznik> do we have so many apps? to be fixed? I don't think so
15:23:50 <rdieter_laptop> and... anything that can't or shouldn't require -runtime can require katepart specfically
15:24:23 <Kevin_Kofler> jreznik: repoquery --whatrequires libktexteditor.so.4
15:25:18 <rdieter_laptop> libktexteditor.so.4()(64bit)
15:25:23 <rdieter_laptop> http://fpaste.org/f0zw/  err,
15:25:41 <Kevin_Kofler> rdieter_laptop: Yes, on an x86-64 machine, you need that ()(64bit) stuff. :-)
15:25:59 <rdieter_laptop> so, not so bad
15:26:17 <rdieter_laptop> Ugh, ok, here's an evil idea
15:26:37 <rdieter_laptop> so things are closer to just working, but it may have other problems
15:26:51 <rdieter_laptop> split libktexteditor into a subpkg, with Requires: katepart
15:27:36 <rdieter_laptop> meh, I'll look into that when the time comes.
15:27:48 <Kevin_Kofler> I have an even more evil idea: write an RPM 4.6 pluggable dependency generator script which adds a Requires: katepart to everything which links to libktexteditor.so.4 and does not provide it itself. :-)
15:27:53 <Kevin_Kofler> RPM 4.9, I mean.
15:28:17 <rdieter_laptop> that could work, but is a little more fragile
15:28:34 <Kevin_Kofler> In principle, we could also pull in kdebase-runtime through that kind of hack.
15:28:40 <rdieter_laptop> Ive always wondered if we could start improving auto deps ^^ yeah.
15:29:01 <rdieter_laptop> and auto-inject versioned deps on qt and kdelibs/kdebase-runtime that way
15:29:50 <rdieter_laptop> might be fun, maybe next gsoc. :)
15:29:59 <rdieter_laptop> or sooner
15:30:20 <Kevin_Kofler> I wish I had more time for dep generator hackery, but right now I need to get the Plasma code done.
15:30:40 <rdieter_laptop> sure. :)
15:31:16 <jreznik> would be nice to have it, indeed
15:31:48 <rdieter_laptop> Kevin_Kofler: hmm... if you have a few free moments, can you splat the general idea into the wiki somewhere?
15:31:56 <rdieter_laptop> (or blog or whatever... for posterity)
15:32:08 <rdieter_laptop> any other 4.6.95 issues?
15:32:12 <rdieter_laptop> or other pkg splits to consider?
15:32:26 <Kevin_Kofler> Re documenting the idea, I can have a try.
15:32:34 <rdieter_laptop> Kevin_Kofler: thanks
15:33:37 <rdieter_laptop> #action Kevin_Kofler to document pluggable dependency generator scripts to automatically add kde dependencies (for things like katepart, versioned qt or kdelibs/kdebase-runtime deps)
15:34:24 <rdieter_laptop> ok, let's move on...
15:35:00 <rdieter_laptop> #topic KDE_Plasma_Desktop_by_default feature
15:35:27 <Kevin_Kofler> So FESCo summarily rejected this on the grounds that this doesn't have endorsement from KDE SIG as a whole.
15:35:47 <jreznik> makes sense
15:35:52 <Kevin_Kofler> So I'm wondering: Shouldn't we endorse it as KDE SIG?
15:36:04 <Kevin_Kofler> I mean, do we really want to be stuck with GNOME as the default forever?
15:36:17 <jreznik> Kevin_Kofler: no, I don't want to be
15:36:20 <Kevin_Kofler> Even many of those people who previously LIKED GNOME now hate it…
15:36:47 <jreznik> but first - we have to find support through the whole Fedora - users, other teams etc.
15:36:52 <rdieter_laptop> that's just the nature of change, same thing happened when kde4 first landed
15:37:14 <Kevin_Kofler> jreznik: I think it's the opposite… we can only get that kind of support if we are the default.
15:37:14 <jreznik> we can't make it as default without support - same as desktop team would make default Gnome without the help
15:37:19 <Kevin_Kofler> Chicken & egg, I know…
15:37:32 <jreznik> Kevin_Kofler: some kind yes...
15:37:38 <rnovacek> Why there have to be any default? Why not two (or more) options on same level?
15:38:25 <Kevin_Kofler> Because influential people in Fedora think it's too hard for a user to choose between 2 options for their download. :-/
15:38:53 <Kevin_Kofler> At least the Ambassadors are now distributing multi-desktop DVDs instead of GNOME-only CDs.
15:39:03 <Kevin_Kofler> (Multi-boot live DVDs.)
15:39:12 <jreznik> Kevin_Kofler: multidvd is a great thing for us
15:39:17 <rdieter_laptop> I can't put my finger on it, but my gut tells me pushing to be default (now or perhaps ever) isn't a good approach to take
15:39:20 <Kevin_Kofler> But if you hit that huge "Download Now" button, you still get GNOME and only GNOME. :-/
15:40:00 <Kevin_Kofler> (also only 32-bit, but that's not really KDE SIG's fight)
15:40:10 <jreznik> I'm still fan of Fedora as a platform to build Gnome OS, Fedora KDE, server distro on top of it
15:40:24 <Kevin_Kofler> (The Ambassadors' multi-boot DVDs are also biarch.)
15:40:34 <rnovacek> I think this is good start for us. Stop Gnome to be default
15:40:39 <rdieter_laptop> my feeling is still to continue efforts to remove ambiguities, ie s/fedora desktop/fedora gnome/ essentially.
15:41:18 <Kevin_Kofler> rnovacek: Then put your name on the feature page…
15:41:31 <rnovacek> imho we don't need to be default desktop but not just the second one
15:42:17 <rnovacek> Kevin_Kofler: If the feature page says what I said, sure, I'll sign it :)
15:42:40 <rdieter_laptop> to be clear though, I'm abivalent to the proposal at hand, and am not against it.
15:43:17 <Kevin_Kofler> That said, at this point, I think only an official endorsement from KDE SIG can possibly get the feature reconsidered.
15:43:23 * jreznik is neither against it but if we want to success we have to invest more to the proposal, to have support (and at least tried to contact people etc.)
15:43:34 <Kevin_Kofler> Otherwise they'll likely not want to reevaluate it.
15:43:52 <jreznik> so I'm not sure this is feature for F16 but quite a long term effort...
15:44:40 <Kevin_Kofler> I think support (in all senses of the word) will automatically come once we are the default.
15:44:50 <Kevin_Kofler> It should really just be a matter of flipping a switch.
15:44:54 <jreznik> Kevin_Kofler: I don't think so - maybe from users
15:45:05 <jreznik> but we need it from other Fedora teams
15:45:30 <jreznik> documentation, design, release... and you know - a lot of these people are hard core gnome people
15:45:48 <jreznik> and we can't make the whole fedora desktop offering without them :(
15:46:19 <jreznik> find company which would support us (like red hat supports gnome guys...)
15:46:28 <Kevin_Kofler> Documentation will focus on whatever is the default.
15:46:36 <Kevin_Kofler> They're focusing on GNOME because it is the default.
15:47:14 <Kevin_Kofler> For design, well, a wallpaper is a wallpaper… And AFAIK more than one design team member is unhappy about GNOME 3.
15:47:58 <Kevin_Kofler> rel-eng is now trying hard to give KDE fair treatment, KDE showstoppers are considered blocking just as GNOME ones are etc.
15:48:13 <Kevin_Kofler> (It used to be different, but KDE has equal treatment for release criteria now.)
15:50:17 <Kevin_Kofler> (Other desktops are still discriminated against there, but that's once again not our battle to fight.)
15:50:23 <mjg59> Kevin_Kofler: While I can't speak for all of fesco, it's certainly my opinion (and that of some other members) that fesco isn't the body to decide which packages are installed by default
15:51:05 <mjg59> The feature process isn't intended to make changes that override other people's decisions
15:51:07 <Kevin_Kofler> mjg59: This isn't about individual packages, this is about the entire desktop including applications, i.e. everything a user will see.
15:51:46 <mjg59> You need to build rough consensus amongst the project that this is the appropriate thing to do
15:52:20 <jreznik> mjg59: yep, I think it's the first step
15:52:24 <mjg59> So identify the people who would be involved in making the change and work on convincing them
15:52:40 <mjg59> And if those people agree then fesco would almost certainly approve it as part of the feature process
15:52:47 <Kevin_Kofler> Desktop workspace + graphical applications == the entire interface a desktop user will see.
15:53:07 <mjg59> But bringing it up as a feature when relevant people don't agree will just result in the feature being refused
15:54:00 <Kevin_Kofler> Who are the "relevant people"? The "Desktop" team, i.e. in practice Red Hat's GNOME developer team? :-/
15:54:29 <mjg59> This is a policy decision rather than a technical one
15:55:11 <mjg59> So if you feel that there's no way that some people will agree then it something you'd need to take to the board
15:55:22 <Kevin_Kofler> Aren't all FESCo decisions policy decisions of some kind?
15:55:45 <mjg59> Policy decisions driven by technical needs
15:55:56 <Kevin_Kofler> And you haven't answered my question: WHO are the "relevant people"?
15:56:14 <mjg59> At the most basic level, rel-eng have control over what ends up in the composes
15:56:43 <rdieter_laptop> Kevin_Kofler: contributors... of influence.  that's how one gathers a consensus
15:57:02 <mjg59> So they'd probably be good people to start with, and they could tell you who *they* would pay attention to when making that decision
15:57:56 <rdieter_laptop> anyway, we're out of time
15:58:05 <rdieter_laptop> any final thoughts?
15:58:37 <Kevin_Kofler> So this means KDE SIG as a whole is still not willing to sign the feature proposal? :-(
15:59:29 <rdieter_laptop> I can't, in good conscience agree with the how/implementation, even if I do agree on the what and why
16:00:01 <rdieter_laptop> (personally)
16:00:07 <rdieter_laptop> Kevin_Kofler: we can do a formal vote, if you like
16:00:18 <ltinkl> I'd be more satisfied with users having the clearly visible choice
16:00:30 <ltinkl> be it the installer or the website
16:01:27 <jreznik> ok, it's time to end :)
16:01:30 <rdieter_laptop> ok
16:01:34 <rdieter_laptop> thanks everyone
16:01:37 <rdieter_laptop> #endmeeting