15:01:07 <rdieter_work> #startmeeting kde-sig -- https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2011-03-08
15:01:07 <zodbot> Meeting started Tue Mar  8 15:01:07 2011 UTC.  The chair is rdieter_work. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:07 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:01:13 <rdieter_work> #topic roll call
15:01:16 <rdieter_work> who's present today?
15:01:20 * jreznik is here
15:01:29 * thomasj present
15:01:30 * rnovacek is here
15:01:31 <Kevin_Kofler> Present.
15:02:04 * than_ present
15:02:35 <rdieter_work> #info rdieter_work jreznik thomasj rnovacek Kevin_Kofler than present
15:02:43 <rdieter_work> #chair jreznik thomasj rnovacek Kevin_Kofler than
15:02:43 <zodbot> Current chairs: Kevin_Kofler jreznik rdieter_work rnovacek than thomasj
15:02:54 <rdieter_work> #topic agenda
15:03:10 <rdieter_work> threw out a couple of items already, added to https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2011-03-08#Agenda
15:03:21 <rdieter_work> (theming, large kickstart), anything else?
15:04:17 <thomasj> I added two topics
15:05:01 <rdieter_work> ok, let's get started
15:05:06 <rdieter_work> #topic theming status
15:05:32 <rdieter_work> yesterday, I touched kde-settings/kdebase-workspace to use lovelock-kde-theme , and will submit updates soonish
15:05:32 <jreznik> I try to catch todays design team meeting to see the current state of wallpaper
15:05:40 <jreznik> but I'm not sure I'll make it today
15:05:58 <rdieter_work> our current kde-4.6.1/f15 update in bodhi is close to being ready to go stable, so I was hesitant to edit it.
15:06:00 <Kevin_Kofler> The problem is that 4.5.1 is still not stable for F15 (is it?), also due to another theming-related issue: the KPK problem.
15:06:04 <Kevin_Kofler> *4.6.1
15:06:45 <Kevin_Kofler> There's also an upstream kdelibs fix for a Dolphin regression.
15:06:46 <rdieter_work> it doesn't *break*, it's just a cosmetic, I don't consider that a blocker
15:06:58 <Kevin_Kofler> (Not built yet.)
15:07:01 * rdieter_work added the dolphin fix a bit ago
15:07:04 <Kevin_Kofler> (It got committed upstream today.)
15:07:05 <thomasj> I have the patch ready
15:07:07 <rdieter_work> it's building now
15:07:09 <Kevin_Kofler> rdieter_work: Which one?
15:07:11 <thomasj> oh
15:07:17 <Kevin_Kofler> The kdebase fix fixes some other, less visible regression.
15:07:24 <Kevin_Kofler> The kdelibs fix from today is needed.
15:07:32 <rdieter_work> oh, I just did the kdelibs one
15:07:53 <Kevin_Kofler> I committed the kdebase one, but didn't build it because it ended up not fixing the reported regression anyway.
15:08:04 <Kevin_Kofler> I also wanted to wait for a consensus on Konsole.
15:08:08 <rdieter_work> oh, ok.
15:08:21 <Kevin_Kofler> i.e. do we want to revert the "disable close tabs" hack?
15:08:32 <rdieter_work> let's stick with the theming topic for now, and we'll cover that later
15:08:55 <Kevin_Kofler> So KDE and cursor theming should be sorted out with those updates.
15:09:03 <Kevin_Kofler> GTK+ theming is a sore point.
15:09:18 <rdieter_work> yeah, that's fail
15:09:50 <rdieter_work> there was some discussion about it at yesterday's -spins meeting
15:10:05 <rdieter_work> no consensus yet though
15:10:19 <Kevin_Kofler> For GTK+ 2, we'll want some quick hack to make root apps default to qtcurve or oxygen-gtk (which one do we want to default to now, BTW? IMHO oxygen-gtk…) using a /root config file, unless the Spins folks come up with a better solution.
15:10:31 <rdieter_work> oxygen-gtk +1
15:11:04 <than> yes,  oxygen-gtk
15:11:05 <thomasj> Yeah, seems oxygen-gtk is the better alternative soonish
15:11:24 <jreznik> how many apps running under root are gtk3?
15:11:36 <Kevin_Kofler> jreznik: We're only talking about GTK+ 2 here!
15:11:37 <rdieter_work> jreznik: very little or none
15:11:42 <Kevin_Kofler> GTK+ 3 is a big can of worms altogether.
15:11:48 <Kevin_Kofler> For GTK+ 3, I think adwaita-gtk3-theme is our only option at this time.
15:11:53 <rdieter_work> yup
15:12:10 <rdieter_work> it shouldn't be too big to add
15:12:12 <Kevin_Kofler> But the problem is that there's nothing making it default if we don't install the gnome-themes-standard main package with all its (many) deps.
15:12:28 <Kevin_Kofler> I think we need to have the GTK+ 3 ini file moved to the gtk3-theme subpackage.
15:12:31 <rdieter_work> oh, yeah, that's part of the fail
15:12:38 <Kevin_Kofler> gnome-themes-standard pulls it in anyway, so it shouldn't regress anything.
15:12:46 <Kevin_Kofler> Though it's not very clean either.
15:13:05 <Kevin_Kofler> IMHO the default config file should go back to gtk[23], not gnome-themes-standard.
15:13:05 <rdieter_work> ok, I'd bet there's no bug open tracking that yet, we should open one
15:14:14 <Kevin_Kofler> But if they insist on shipping those files in gnome-themes-standard, they should at least be in the theme subpackages.
15:14:26 <rdieter_work> #action rdieter will file bug tracking gtk3 config/theme issue
15:14:46 <rdieter_work> it's the libXcursor thing all over again, but worse
15:15:07 <Kevin_Kofler> GTK+ 2 has the same issue BTW.
15:15:14 <rdieter_work> true
15:15:20 <Kevin_Kofler> The only thing saving us there is that the GTK+ 2 theme is set within KDE sessions.
15:15:26 <Kevin_Kofler> (but not for root)
15:15:48 <Kevin_Kofler> BTW, this is another GTK+ 3 issue, kcm-gtk, krdb etc. are not ready for it.
15:16:18 <Kevin_Kofler> (xsettings-kde SHOULD just work, I think, but I don't think anybody has tested that, either.)
15:16:22 <rdieter_work> yeah, much of our existing integration tools need to be gtk3-ized
15:16:35 <Kevin_Kofler> kcm-gtk and kdebase-workspace/kcontrol/krdb definitely need GTK+ 3 support.
15:16:56 <Kevin_Kofler> oxygen-gtk too, but that's another BIG can of worms.
15:16:57 <rdieter_work> Kevin_Kofler: mind opening bugs to track those 2?
15:17:09 <jreznik> ok, do we have list/wiki of what is needed for correct gtk3 support?
15:17:28 <Kevin_Kofler> 1. Port kcm-gtk.
15:17:30 <jreznik> we should push - ask upstreams to work on it
15:17:34 <jreznik> or we can step into
15:17:35 <Kevin_Kofler> 2. Port krdb (in kdebase-workspace).
15:17:41 <Kevin_Kofler> 3. Port xsettings-kde.
15:17:45 <jreznik> as usually when something is happening in Fedora
15:17:46 <Kevin_Kofler> Uh, test it.
15:17:54 <Kevin_Kofler> No porting should be needed for xsettings-kde.
15:18:16 <Kevin_Kofler> 4. Port oxygen-gtk. Upstream is now finally looking at it, but there are problems.
15:19:17 <Kevin_Kofler> Basically, the GTK+ developers (at least Tomáš) think oxygen-gtk's code is ugly, the oxygen-gtk developer thinks GTK+ 3's theming API is crippled, that doesn't look like a plan for friendship. ;-)
15:20:21 <jreznik> "D
15:20:22 <jreznik> :D
15:20:49 <jreznik> (all gtk code is obviously ugly)
15:21:05 <rdieter_work> <rimshot>
15:21:35 <rdieter_work> Kevin_Kofler: you ok with opening bugs to track each of those items you listed?
15:21:35 <jreznik> it probably means - if we don't step into the upstream development, nobody will do it
15:21:40 <than> Kevin_Kofler: we should file bugs by kde bugzilla
15:22:03 <jreznik> so yes, please - tracking bugs and report it upstream
15:22:32 <rdieter_work> I see value in doing both downstream/upstream here, but upstream is most important
15:22:42 <Kevin_Kofler> I'll do it.
15:22:48 <rdieter_work> (it's easier for us tracking-wise to use downstream bugs)
15:22:51 <Kevin_Kofler> Uhm, well, for kcm-gtk, what is upstream?
15:22:54 <than> Kevin_Kofler: thanks
15:23:04 <rdieter_work> Kevin_Kofler: I think ubuntu/launchpad
15:23:06 <Kevin_Kofler> Probably Launchpad, I don't have an account there yet.
15:23:27 <rdieter_work> I could do that one perhaps, we can discuss after meeting
15:23:31 <Kevin_Kofler> I guess I can register for one if it doesn't require signing my soul to the devil^W^WCanonical. ^^
15:23:48 <rdieter_work> #action Kevin_Kofler to file bugs tracking gtk3-related integration issues
15:24:04 <rdieter_work> can we move on?
15:24:30 <Kevin_Kofler> So do we agree on a plan?
15:24:53 <Kevin_Kofler> (other than filing the bugs, which is more F16 material, I'm afraid)
15:24:59 <Kevin_Kofler> IIUC, the plan is:
15:25:03 <rdieter_work> well step 0 was to track all the issues at hand
15:25:09 <jreznik> I have launchpad account, I can report it
15:25:19 <jreznik> Kevin_Kofler: agree
15:25:26 <Kevin_Kofler> * We file a bug to get the gtkrc/ini files moved to the adwaita-gtk[23]-theme subpackages.
15:25:28 <rdieter_work> then find or contribute interested parties to help implement them
15:25:43 <Kevin_Kofler> * We pull in at least adwaita-gtk3-theme. (I guess we can get away without the gtk2 one if we do the next thing.)
15:25:59 <rdieter_work> Kevin_Kofler: I'm going to leave the solution open when filing the bug, but that's what I'm going to suggest anyway
15:26:12 <Kevin_Kofler> * We set the GTK+ theme for root to oxygen-gtk using the live kickstart (write to /root).
15:26:36 <Kevin_Kofler> * We set the default GTK+ theme in KDE to oxygen-gtk if it's still qtcurve-gtk.
15:26:53 <Kevin_Kofler> * We can also kick out qtcurve-gtk2 from the live image if it's still there.
15:27:07 <Kevin_Kofler> (once we changed the default theme)
15:27:13 <Kevin_Kofler> Any objections there?
15:27:20 <rdieter_work> nope, sounds good
15:27:24 <thomasj> +1
15:27:54 <nucleo> and qtcurve-kde4?
15:27:58 <Kevin_Kofler> Who will do the work?
15:28:06 <Kevin_Kofler> nucleo: qtcurve-kde4 can also get out.
15:28:10 <rdieter_work> I'll do it
15:28:21 <Kevin_Kofler> The only reason we ship it is really for users who want to match qtcurve-gtk2 exactly.
15:28:26 * thomasj waves his baby goodbye
15:28:36 <Kevin_Kofler> thomasj: It'll still be in the repo.
15:28:44 <thomasj> I know :)
15:28:48 <rdieter_work> #action rdieter will work to incorporate oxygen-gtk (replacing qtcurve)
15:28:49 <Kevin_Kofler> We're not installing my Quarticurve theme by default either. ;-)
15:29:11 <thomasj> heh
15:29:16 <Kevin_Kofler> (BTW, I should also look into porting Bluecurve to GTK+ 3… ^^)
15:29:27 <rdieter_work> lol
15:29:32 <thomasj> omg lol
15:29:42 <rdieter_work> ok, let's move on for real this time... :)
15:29:52 <rdieter_work> #topic Large kickstart again (new proposal: target 2G)
15:30:06 <rdieter_work> Kevin_Kofler: this was your idea, go ahead.
15:30:15 <thomasj> Yes, keep the large kickstart but target 2G
15:30:25 <Kevin_Kofler> So the status is that it LOOKS like we're able to fit both Digikam and Amarok, along with the other small items we removed lately, on the 700 MiB image.
15:30:34 * rdieter_work yays
15:30:41 <Kevin_Kofler> (Right now it fits, hopefully there won't be last-minute bloat this time.)
15:31:06 <Kevin_Kofler> So having a "1G" image (which is actually 800 MiB right now) next to it doesn't look all that useful.
15:31:08 <nucleo> 691M now with digikam and ktorrent added
15:31:31 <Kevin_Kofler> Using the remaining 200 MiB, we could add some more stuff, but it'd be a big fight over what to add, and it wouldn't really help all that much.
15:31:34 <rdieter_work> our space should get a little better with our latest kdebase-workspace-ksplash-themes split out
15:31:45 <Kevin_Kofler> Oh, that too. :-)
15:31:59 <Kevin_Kofler> So I think we should target 2 GiB for the large kickstart.
15:32:28 <thomasj> +1
15:32:38 <Kevin_Kofler> AFAICT, that should allow us to ship full l10n support (kde-l10n-*, input methods, default CJK fonts) along with a large selection of apps (hopefully all of kdeedu*).
15:32:42 <Kevin_Kofler> (and more)
15:33:06 <Kevin_Kofler> (maybe even R and Maxima for Cantor, but that's the Mathematician in me talking ;-) )
15:33:49 <Kevin_Kofler> It wouldn't be the default spin of course, but it'd be the alternate kickstart.
15:33:56 <Kevin_Kofler> (instead of 1G or 800 MiB)
15:33:58 <rdieter_work> maybe even step back a little, something like ~1.6gb ish, so 2gb usb sticks can have some overlay
15:34:07 <thomasj> Since USB-sticks (even cheap ones) have at least 4G space, that makes sense to enlarge the large kickstart.
15:34:07 <rdieter_work> but that's not a big deal
15:34:08 <jreznik_> it really does not make sense to have two different ks with 100 MB betwwen
15:34:25 <Kevin_Kofler> rdieter_work: I think we should see how much we really need.
15:34:30 <jreznik_> thomasj: we have fedora branded 1 gb
15:34:32 <rdieter_work> sure
15:34:39 <Kevin_Kofler> I'd put the hard limit at 2 GiB and see how far we go.
15:34:47 <rdieter_work> ok, I'm +1
15:35:01 <thomasj> jreznik_, re-brand it :)
15:35:01 <jreznik_> +
15:35:04 <jreznik_> +1
15:35:18 <thomasj> +1 from me obviously
15:35:22 <Kevin_Kofler> For the app selection, any objection to me starting with l10n support?
15:35:28 <rnovacek> sure, +1
15:35:38 <thomasj> Kevin_Kofler, start with it
15:35:45 <Kevin_Kofler> I know some of us have other priorities, but 2G should allow fitting both l10n and the other stuff.
15:35:56 <rdieter_work> Kevin_Kofler: experiment away
15:36:24 <jreznik_> l10n makes sense for installation but we still need some language selection for live
15:36:27 <Kevin_Kofler> My next target would be kdeedu, especially the Math stuff. :-)
15:36:32 <rdieter_work> #action Kevin_Kofler to tweak fedora-live-kde.ks aiming for 2gb now
15:36:38 <thomasj> Kevin_Kofler, i would like to assist you there
15:36:58 <thomasj> If possible
15:37:01 <Kevin_Kofler> thomasj: You're welcome, please apply for gitspin-kickstarts group membership in FAS.
15:37:28 <Kevin_Kofler> Otherwise you'll have to send all your commits to me or rdieter to get them pushed, which is a PITA.
15:37:49 <nucleo> Kevin_Kofler: with R and maxima?
15:37:55 <Kevin_Kofler> jreznik_: System Settings… AFAIK, the GNOME spin currently also requires you to fire up (their version of) System Settings to change the language (and people are complaining about it).
15:38:01 <thomasj> Kevin_Kofler, on it, thanks
15:38:07 <Kevin_Kofler> nucleo: We can see what fits.
15:38:28 <Kevin_Kofler> We can't use ALL the space for Math stuff. ;-)
15:38:36 <Kevin_Kofler> It's a KDE spin, not a Math spin. ;-)
15:39:03 <Kevin_Kofler> (It's sad that the Math spin was abandoned.)
15:39:11 <rdieter_work> ok, sounds like we have a plan, anything else? I'll move on shortly if not.
15:40:33 <rdieter_work> #topic Backup solution for @kde-desktop/live-image
15:41:02 <rdieter_work> thomasj suggested we add a default backup solution, like luckybackup
15:41:08 <thomasj> Yes
15:41:23 <thomasj> It's one of the basic usecases with a livecd
15:41:35 <thomasj> Try it out, backup your data, install on HDD
15:41:52 <jreznik_> it's possible usecase
15:41:56 <thomasj> Currently there's only the CLI way possible, not very new-user-friendly
15:42:07 * Kevin_Kofler has concerns about the usefulness of the concrete implementation.
15:42:09 <jreznik_> especially with all anaconda warnings when playing with partitions to backup
15:42:12 <rdieter_work> I think I agree it's a good usecase to cover, I'm not all that familiar with backup gui options though
15:42:40 <Kevin_Kofler> Luckybackup is rsync-based. Most users will want to use some USB device, not a networked server, for their backups, and rsync is not very effective there.
15:42:51 <Kevin_Kofler> Well, I guess it's OK for the initial backup when the target is empty.
15:42:51 <thomasj> I use it with my USB-disk
15:43:18 <Kevin_Kofler> But after that, each time you want to sync, it reads both versions, computes checksums, then syncs.
15:43:19 <thomasj> Backup internal laptop HDD to USB-Hdd for example
15:43:35 <Kevin_Kofler> It's usually faster to just rm -rf everything and cp from scratch.
15:43:40 <rdieter_work> Kevin_Kofler: bascially the pros/cons of using rsync
15:43:54 <Kevin_Kofler> (though less safe because you have no backup for that period, unless you use at least 2 alternating backups)
15:44:25 <jreznik_> it's more about instant backup - not about syncing later
15:44:30 <Kevin_Kofler> rsync is fast if reading is way faster than writing, or if you're using a server with the rsync server running, saving bandwidth.
15:44:40 <Kevin_Kofler> Or I guess if the target is empty anyway.
15:44:50 <thomasj> I brought that up to have a backup solution on our livecd. It works *very* well and even new users understand the gui.
15:44:53 <rdieter_work> luckybackup looks like a simple qt app, though I'm surprised in comes in at a 10mb disk footprint (according to rpm)
15:45:16 <rdieter_work> has a dep on beesu, heh
15:45:24 <thomasj> Yeah, for gnome
15:45:36 <thomasj> Sadly i had to add it.
15:45:39 <rdieter_work> I might need to work harder on xdg-su
15:45:53 <Kevin_Kofler> We won't ship beesu on the KDE spin.
15:46:01 <Kevin_Kofler> If you want us to ship the package, you'll have to drop the dep.
15:46:03 <Kevin_Kofler> It should use kdesu.
15:46:10 <thomasj> For gnome?
15:46:14 <Kevin_Kofler> Always.
15:46:19 <thomasj> That doesn't work
15:46:32 <Kevin_Kofler> kdesu should work fine under GNOME.
15:46:42 <rdieter_work> and so does beesu work under KDE
15:46:43 <thomasj> It doesn't.
15:46:50 <Kevin_Kofler> Yes, but we don't want to ship beesu.
15:47:03 <rdieter_work> thomasj: if it doesn't, that's a bug we should fix
15:47:06 <Kevin_Kofler> Also, we don't want more GUI apps running as root, thank you very much.
15:47:22 <Kevin_Kofler> This stuff needs fixing to use PolicyKit before we'll even CONSIDER adding it.
15:47:26 <thomasj> Kevin_Kofler, you should at least try it before you tell some BS about it.
15:47:36 <thomasj> Kevin_Kofler, you dont have to run it as root, but you can.
15:47:37 <Kevin_Kofler> This is not BS.
15:47:44 <rdieter_work> Kevin_Kofler has a point, but I don't consider it a blocker
15:47:47 <Kevin_Kofler> Well, if it's optional, then it shouldn't be a dep at all.
15:48:20 <thomasj> Fine. Keep it off the livecd. Why help new users.
15:48:31 <rdieter_work> thomasj: mind posting a call for testing/feedback wrt luckybackup on kde@lists.fpo, and we'll go from there.
15:48:32 <thomasj> I will not drop beesu for that.
15:49:10 <thomasj> I got enough flamed by upstream for having it dropped in the first place.
15:49:10 <rdieter_work> and I'd be very curious how/why kdesu isn't working
15:49:27 <Kevin_Kofler> As for rsync usage, my concern is that users (especially NEW users) will not understand that local incremental backups will be MUCH slower than initial ones.
15:49:42 <Kevin_Kofler> Because rsync reads all the destination files rather than just overwriting them.
15:49:54 <thomasj> I bet the new user who just want a backup of his system dont care about that.
15:49:57 <Kevin_Kofler> I tried rsync locally once, I wasn't impressed.
15:49:59 <rdieter_work> meh, let's not bikeshed on the implementation details
15:50:08 <thomasj> A backup before he installs Fedora on his HDD.
15:50:09 <rdieter_work> thomasj: +1
15:50:13 <jreznik_> but we want solution for initial backup here
15:50:19 <Kevin_Kofler> Uh, the implementation details are quite important when evaluating the usefulness of an application.
15:50:23 <rdieter_work> Kevin_Kofler: OK, we get it.  you don't like rsync.
15:50:45 <rdieter_work> is there a better alternative?  you'd rather ship *no* backup solution, than luckybackup?
15:50:48 <Kevin_Kofler> AFAIK, rsync also relies on hashes being collision-free, which is also not a good idea.
15:51:04 <jreznik_> for installation I'd prefer the whole partition backup - to be easily restored to state before-anaconda
15:51:06 <Kevin_Kofler> I'd rather use the space for something useful, like Krusader.
15:51:15 <Kevin_Kofler> (which can also be used for backups, FWIW)
15:51:18 <rdieter_work> I thought krusader was alrady added
15:51:27 <Kevin_Kofler> We added it only to the large kickstart.
15:51:39 <thomasj> krusader for backups for new users .....
15:51:43 <Kevin_Kofler> But given that we apparently have space left, I think we should add it to the small one too.
15:51:54 <Kevin_Kofler> thomasj: Krusader is essential for power users.
15:51:59 <thomasj> New user == possibly windows user
15:52:02 <Kevin_Kofler> Do we want to target serious users or the GNOME camp?
15:52:09 <rdieter_work> I still don't like adding duplicated apps, esp on a space-constrained spin, -1
15:52:13 <thomasj> Kevin_Kofler, yeah but you wouldn't use the livecd with krusader
15:52:24 <Kevin_Kofler> And many Window$ users are using Total Commander.
15:52:50 <Kevin_Kofler> Krusader is the ideal migration path for those.
15:52:55 <rdieter_work> we're running short on time, I proposed gathering feedback onlist wrt luckybackup.
15:52:59 * thomasj is done with that discussion.
15:53:00 <rdieter_work> Kevin_Kofler: ^^ I suggest you do the same
15:53:08 <rdieter_work> wrt krusader
15:53:25 <Kevin_Kofler> Oh BTW, http://luckybackup.sourceforge.net/screenshots.html looks fugly.
15:53:35 <jreznik_> krusader is ok on 2G spin
15:53:36 <Kevin_Kofler> It's a Qt-only app with custom icons, eww!
15:53:41 <thomasj> Put krusader on the livecd and keep luckybackup off. I'm not going to have the same discussion on the ML.
15:53:46 <Kevin_Kofler> jreznik_: I want it on the CD.
15:53:54 <Kevin_Kofler> It's only 4 MiB (xz-compressed).
15:54:02 <Kevin_Kofler> And we have the space.
15:54:17 <Kevin_Kofler> (If we end up not having it due to changes, it'll the first thing I'll remove.)
15:54:25 <rdieter_work> thomasj: ml is only for feedback wrt each app, I really want to avoid any debate or comparisions about the merits of each right now
15:54:36 <jreznik_> rdieter_work: +1
15:55:30 <Kevin_Kofler> And how is the kind of new user you want to target going to understand THIS dialog? http://luckybackup.sourceforge.net/data/OperationPropertiesAdvancedOptions1.png
15:55:39 <Kevin_Kofler> (to thomasj)
15:55:54 <thomasj> Kevin_Kofler, i'm done with it. Keep it. Do it your way.
15:56:01 <Kevin_Kofler> I'm not arguing that Krusader doesn't have such dialogs, but that's its target userbase. ;-)
15:56:19 <Kevin_Kofler> thomasj: Look, I want to discuss the merits of the application.
15:56:24 <thomasj> No
15:56:25 <Kevin_Kofler> You're the "my way or the highway" one.
15:56:33 <thomasj> You just don't want it on the livecd.
15:56:35 <rdieter_work> Kevin_Kofler: you are too. :(
15:56:48 <thomasj> I think about new users.
15:56:55 <jreznik_> hey, guys :) psss
15:56:55 <thomasj> You think about power users.
15:57:02 <Kevin_Kofler> That's exactly the problem: You claim that we don't think about new users at all.
15:57:04 <thomasj> So be it. kde livecd is for power users.
15:57:06 <rdieter_work> let's move on, ml => further discussion
15:57:08 <rdieter_work> please
15:57:20 <Kevin_Kofler> When there are precise TECHNICAL reasons why luckybackup just sucks as an implementation.
15:57:21 <thomasj> I'm done anyways.
15:57:28 <thomasj> Kevin_Kofler, keep it.
15:57:28 <rdieter_work> #topic Usecases on wiki page or spins-homepage -> download section
15:58:07 <rdieter_work> I'm tempted, but putting this on spins feels a little dangerous, esp if we change apps per release
15:58:35 <rdieter_work> though mentioning the use-cases => good.  mentioning specific apps => potentially bad
15:58:53 <Kevin_Kofler> Put a wiki link on the spins page?
15:59:11 <rdieter_work> *some* apps we can be rest-assured won't be changing soon...
15:59:24 <rdieter_work> Kevin_Kofler: that might be a good compromised here
16:01:10 <rdieter_work> thomasj: what do you think of that idea?
16:01:26 <rdieter_work> ok, proposal:
16:02:01 <rdieter_work> list use-cases on spins page , with some sort of "for more details..." link which goes to a wiki with ... the gory details.
16:02:19 <rdieter_work> it's more work though, splitting it into 2 like that.
16:02:33 <rdieter_work> maybe first pass simple would be getting it all on the wiki first.
16:03:08 <rdieter_work> then, if we all like that, ... then can invest more time into polishing it for the spins page
16:03:38 <thomasj> +1
16:03:54 <rdieter_work> thomasj: and, you still able/willing to work on that? :)
16:08:09 <rdieter_work> thomasj: ?
16:08:10 <thomasj> Sure
16:08:13 <rdieter_work> ok, :)
16:08:15 <rdieter_work> #action thomasj to work on documenting kde spin use-cases and default apps (on wiki), eventual goal of moving some or all of it to spins page.
16:08:28 <rdieter_work> alright, -EOUT_OF_TIME, thanks everyone!
16:08:31 <rdieter_work> #endmeeting