14:10:53 <rdieter> #startmeeting KDE SIG Meeting -- https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-07-21
14:11:05 <rdieter> #topic Role Call
14:11:12 <rdieter> #topic Roll Call
14:11:17 <rdieter> hee, who's present today?
14:11:22 * ltinkl present
14:11:23 * jreznik is here
14:11:33 * SMParrish here
14:11:37 * Kevin_Kofler is here too.
14:11:49 * thomasj here on a cheap chair
14:12:13 * G takes a cheap seat too
14:12:32 <than> present
14:12:39 <rdieter> all good seats here, let's get started on the agenda
14:12:42 <rdieter> #topic should we support old artwork + fedora system logo
14:13:27 <jreznik> we have solar theme in F11
14:13:43 <than> i don't see any problem to support old artwork
14:13:43 <jreznik> but different logo and as logo is in different package...
14:13:58 <Kevin_Kofler> I think we should support the themes as long as they work.
14:14:06 <Kevin_Kofler> Porting old KDE 3 themes is probably not worth the effort.
14:14:16 <than> Kevin_Kofler, i agree with you
14:14:16 <Kevin_Kofler> The logo is an issue though.
14:14:18 <jreznik> this is causing problems - and taking care about more than 1 theme...
14:14:27 <rdieter> Kevin_Kofler: +1, that's about the best we can do
14:14:59 <jreznik> I'm +1 too but it means with new theme we have to check old ones...
14:15:06 <jreznik> latest bug in solar...
14:15:48 <rdieter> anything not the latest, we could solicit help to keep things testing and working
14:16:20 <rdieter> I'd venture we could find a kde-sig'er or 2 interested, it's relatively low-hanging fruit
14:17:22 <rdieter> I suppose any old theme(s) that we cannot find (co)maintainers for, we could consider dropping as unsupported in those cases
14:17:35 <jreznik> ok, we should move kde system logo somewhere else than current theme directory...
14:17:52 <Kevin_Kofler> jreznik: +1
14:18:17 <jreznik> it's not a problem to maintain, not a problem to fix issues but testing... someone has to test it (I know me :D)
14:18:30 <Kevin_Kofler> The icon should be in a fixed place.
14:18:40 <Kevin_Kofler> I think supporting the themes will be trivial once that's fixed.
14:18:48 <jreznik> Kevin_Kofler: usr/share/pixmaps/ ?
14:18:49 <than> jreznik, where can we put it in?
14:18:54 <than> the icon
14:19:06 <jreznik> than: the logo to usr/share/pixmaps/
14:19:42 <jreznik> there's system-logo-white already, we can use this system wide logo (and hope they don't change it too often)
14:19:55 <than> it's ok with this directory
14:20:08 <than> most icons are installed here
14:20:10 <jreznik> for generic logo?
14:20:15 <Kevin_Kofler> system-logo-white is the wrong size, the size might not even be fixed in different derivatives and the generic logo is ugly.
14:20:25 <Kevin_Kofler> I think we should have a system-logo-kde.png.
14:20:28 <jreznik> because we don't want that bad generic logo
14:20:39 <Kevin_Kofler> Which would be the icon we currently have, just moved to a central place.
14:20:58 <jreznik> Kevin_Kofler: we can prepare new themes using current size of system-logo-white
14:22:24 <jreznik> with system-logo-kde.png we're duplicating one file (only few pixels smaller)
14:22:38 <jreznik> for generic logo, it's different issue
14:22:40 <Kevin_Kofler> The generic version is completely different.
14:22:48 <Kevin_Kofler> So it wouldn't be an exact duplicate.
14:23:46 <nicubunu> sorry to intervene, but i don't understand, you want to replace the fedora logo with a different logo but still be a fedora spin?
14:24:11 <Kevin_Kofler> nicubunu: The Fedora logo is still the Fedora logo.
14:24:24 <Kevin_Kofler> Just differently sized. The usage guidelines don't require a particular size.
14:24:25 <jreznik> nicubunu: it's why I'd like to have one Fedora logo - our is just different size
14:24:39 <Kevin_Kofler> And the generic version is the KDE logo, not a generic doodle.
14:24:43 <nicubunu> how gig do you need it?
14:24:45 <jreznik> but for generic logos we're using KDE logo
14:24:55 <Kevin_Kofler> That's what we currently use in the KSplash themes.
14:25:04 <Kevin_Kofler> (the Solar and Leonidas ones)
14:25:14 <nicubunu> isn't possible to have the default generic logo at a size suitable for you?
14:26:07 <Kevin_Kofler> I think the size is the smaller issue, the fact that we'd rather put up a KDE icon in KSplash than a "generic distribution" one is the bigger one. :-)
14:26:19 <jreznik> nicubunu: generic logo is ugly...
14:26:46 <jreznik> maybe we should have nicer generic logo (do we have new one?)
14:26:47 <nicubunu> jreznik: we are talking about the fedora logo with a slight gradient and a drop shadow?
14:26:52 <Kevin_Kofler> But of course the generic generic logo ( ;-) ) can't be a KDE one as a KDE logo in GNOME would be just plain wrong.
14:27:21 <jreznik> nicubunu: no, about generic one... not fedora logo
14:28:14 <jreznik> but I think we should have system-logo-white, not different one... but that again brings if we should support old artwork... if design team change it...
14:28:35 <nicubunu> oh, then i don't know how that looks, for me system-logo-white.png is a fedora logo
14:29:01 <rdieter> let me propose that we try to coordinate efforts with logos folks to get something that's usable for our needs here
14:29:02 <Kevin_Kofler> Isn't it some weird thing with sausages in it? ;-)
14:29:20 <jreznik> rdieter: +1
14:29:31 <jreznik> Kevin_Kofler: it's really ugly...
14:29:34 <Kevin_Kofler> Yeah, that sounds like the best path forward.
14:30:06 <Kevin_Kofler> I wonder if we could get them to use a Fedora Remix logo as the default generic logo?
14:30:24 <Kevin_Kofler> Or would that still carry too many restrictions to qualify?
14:30:26 <nicubunu> i think i saw something about the sausage... isn't that only for derivative distros, in order to encourage putting their own branding? i.e. not for spins?
14:30:47 <Kevin_Kofler> The Fedora KDE spin ships with the Fedora logo.
14:30:57 <nicubunu> +1 for remix, it sounds to me like a sane thing to do
14:31:12 <Kevin_Kofler> But derivatives will ship with our KDE themes with the generic logo.
14:31:19 <jreznik> but rdieter sometimes prepare unbranded snapshots and we use KDE logo as generic one
14:31:21 <Kevin_Kofler> So we need to make sure they work and look appropriate.
14:31:47 <jreznik> there are two packages - fedora-logos (gnome and kde spins are using it) and generic-logos (unbranded with ugly sausage)
14:32:15 <jreznik> for fedore-logos one logo is enough, we can do it even with different sizes
14:32:42 <jreznik> it was caused by changing fedora logo in fedora-logos too late I think... If I remember it
14:33:03 <jreznik> let's move it to fedora-kde and design team mailing list
14:34:00 <Kevin_Kofler> +1
14:34:05 <Kevin_Kofler> Let's move on here.
14:35:00 <rdieter> cool
14:35:15 <rdieter> #topic defining @critical-path-kde group (task delegated to the SIG for each spin by FESCo)
14:36:27 <Kevin_Kofler> So FESCo basically said: yes, there's no critical-path-kde defined yet because that's the SIG's job. :-)
14:36:32 <Kevin_Kofler> So here we are. :-)
14:37:00 <rdieter> seems critical-path-gnome so far is not much more than gdm + X server
14:37:27 <Kevin_Kofler> I'd put kdm and kdebase-workspace in the list.
14:37:37 <Kevin_Kofler> It gets depsolved automatically.
14:38:00 <Kevin_Kofler> And kdm and kdebase-workspace are built from the same SRPM, so for update purposes they're the same package.
14:38:11 <jreznik> we want whole kdebase-workspace or kdelibs are enough?
14:38:21 <Kevin_Kofler> It'd also pull in a lot of stuff as "critical" though.
14:38:30 <Kevin_Kofler> soprano, akonadi, the whole shebang.
14:38:49 <rdieter> let's take some baby-steps here, I'd propose we stick with only kdm for now
14:39:01 <Kevin_Kofler> rdieter: OK.
14:39:14 <rdieter> let's not overload the process, and learn from how things go.
14:39:15 <Kevin_Kofler> It'll also require checking updates of kdebase-workspace itself as a side effect.
14:39:21 <Kevin_Kofler> But not all the deps.
14:39:21 <SMParrish> I agree start small with just KDM
14:39:33 <Kevin_Kofler> That said, KDM itself already requires kdelibs and through it half of the world.
14:39:41 <rdieter> kdm already implicitly pulls in kdelibs/qt for example
14:39:45 <rdieter> yeah. :O
14:39:53 <jreznik> yes, qt/kdelibs are critical
14:40:23 <Kevin_Kofler> I'm still worried about the bureaucracy when updating the packages which happen to be dependencies of KDE (or GNOME or whatever, for that matter).
14:40:45 <Kevin_Kofler> But unfortunately I couldn't convince FESCo of the insanity of that process. :-(
14:41:00 <Kevin_Kofler> My -1 vote was the only one.
14:42:05 <jreznik> some updates should be done more carefully
14:42:27 <jreznik> it's the question if it applies only for lowlevel stuff or for desktop too
14:43:10 <rdieter> I think it's both
14:43:21 <rdieter> ie, kdm + all it's deps
14:43:26 <Kevin_Kofler> I think we need more common sense, not bureaucracy.
14:43:43 <SMParrish> I think its a good idea as long as its implemented well
14:43:44 <Kevin_Kofler> I.e. don't rush out a "tighten policies for the whole desktop" update as a "security update".
14:43:57 <Kevin_Kofler> (the D-Bus fiasco)
14:44:23 <rdieter> I consider it more codifying such common sense, best practices, additional testing ... if you consider that (useless) bureaucracy, ok
14:45:08 <jreznik> if we don't want critical path, we need our own test plan and do more testing for udpates-testing stuff... as I proposed last time...
14:45:32 <Kevin_Kofler> I also don't remember any recent updates breakage other than that D-Bus fiasco.
14:45:42 <Kevin_Kofler> At least not one critical enough to warrant that policy.
14:46:02 <Kevin_Kofler> But anyway, it's not to us to decide that policy, it's to FESCo and they outvoted me already.
14:46:07 <rdieter> ok, so what do you all think?  do a kde-crit-path of not?
14:46:28 <Kevin_Kofler> One open thing is also: who is responsible for QAing critical-path-kde?
14:46:36 <Kevin_Kofler> I don't think FESCo gave a definite answer on that.
14:46:55 <Kevin_Kofler> I.e. whether it will be covered by the same rules as the other critical-path stuff or whether it's our job to police it.
14:47:10 <SMParrish> +1 for critical path
14:48:36 <rdieter> Kevin_Kofler: I thought crit path is crit path, there's a common set of rules
14:48:55 <Kevin_Kofler> I think they want the critical path for "spins" treated separately.
14:49:07 <rdieter> so, if we opt to policy ourselves, then we opt out of crit path altogether, and do our own thing
14:49:15 <Kevin_Kofler> But they didn't decide whether that covers XFCE, LXDE etc. only or KDE too or maybe even GNOME too.
14:50:14 <Kevin_Kofler> The thing is that the policy is supposed to come with some sort of automated enforcement in Bodhi.
14:50:28 <Kevin_Kofler> I'm not sure how they plan to handle this for the various spins.
14:50:36 <Kevin_Kofler> Maybe we should seek clarification on that?
14:50:47 <rdieter> yes
14:51:17 <Kevin_Kofler> OK, I'll inquire in the FESCo ML about that.
14:51:17 <thomasj> +1 seeking clarification
14:51:51 <Kevin_Kofler> IMHO at least the KDE spin ought to be covered by the default enforcement as it's one of the primary ones.
14:52:33 <jreznik> Kevin_Kofler: +1
14:53:09 <Kevin_Kofler> If we define a set of critical path packages and nobody enforces it, we're just wasting our time.
14:54:11 <than> Kevin_Kofler, who will test  critical path packages?
14:54:37 <Kevin_Kofler> than: That's a good question, and something they'll also ask us when we ask for centralized enforcement.
14:54:49 <Kevin_Kofler> Our big problem there is that we have no dedicated QA tester.
14:55:00 <jwb> Kevin_Kofler, ask on the fedora-devel list, not fesco list.  there's no reason for it to be private
14:55:12 <Kevin_Kofler> jwb: OK, will do.
14:55:42 <rdieter> we're about out of time, anything else to discuss today?
14:55:46 <jwb> though i'm pretty sure we already said it's up to the spins SIGs
14:55:46 <rdieter> #topic Open Discussion
14:56:16 <Kevin_Kofler> jwb: If we don't have enforcement in Bodhi, how is this supposed to work?
14:56:24 <than> it doesn't make sense to  define a set of critical path packages if we don't have Qa testers
14:56:39 <Kevin_Kofler> Any comaintainer or provenpackager can push updates without QA.
14:59:56 <Kevin_Kofler> We could define a purely informative critical-path-kde, but I'm not sure what that'll bring us.
15:00:08 <tk009> you are to start it adamw?
15:00:18 <adamw> kde guys are still going...
15:00:20 <tk009> err want to atart it
15:00:36 <rdieter> we're out of time anyway, let's wrap it up
15:00:39 <rdieter> #endmeeting