15:01:43 <rdieter> #startmeeting kde-sig -- http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2011-02-15
15:01:43 <zodbot> Meeting started Tue Feb 15 15:01:43 2011 UTC.  The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:43 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:01:50 <rdieter> #meetingname kde-sig
15:01:50 <zodbot> The meeting name has been set to 'kde-sig'
15:01:54 <rdieter> #topic roll call
15:02:01 <rdieter> who's present today?
15:02:07 <Kevin_Kofler> Present.
15:02:11 * rnovacek is here
15:02:20 <rdieter> ping: than, thomasj, SMParrish, ltinkl, jreznik, kde*foo
15:02:21 * thomasj present
15:02:29 * than is present
15:02:30 * ltinkl here tooo
15:02:35 * jreznik is here
15:02:57 <rdieter> #chair Kevin_Kofler rnovacek thomasj than ltinkl jreznik
15:02:57 <zodbot> Current chairs: Kevin_Kofler jreznik ltinkl rdieter rnovacek than thomasj
15:03:12 <rdieter> #info rdieter Kevin_Kofler rnovacek thomasj than ltinkl jreznik present today
15:03:28 <rdieter> #topic agenda
15:03:41 <rdieter> besides, what I just splatted up, https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2011-02-15#Agenda , anything else to discuss today?
15:04:25 <thomasj> Maybe, if there's time a bug
15:04:29 <Kevin_Kofler> 1G image: keep (yes/no)? If yes, what to add (there's room left).
15:05:13 <rdieter> thomasj: what bug?
15:05:25 <thomasj> .bug 676837
15:05:30 <zodbot> thomasj: Bug 676837 [abrt] evolution-2.32.1-1.fc14: qtSettingsInit: Process /usr/bin/evolution was killed by signal 11 (SIGSEGV) - https://bugzilla.redhat.com/show_bug.cgi?id=676837
15:05:42 <thomasj> I need a bit help eventually.
15:05:46 <rdieter> I was trying (and failing) to reproduce that this morning
15:05:51 <thomasj> Same here
15:06:14 <rdieter> did see a couple unreproducible crashes using oxygen-gtk though. :)
15:06:25 <thomasj> heh
15:06:45 <rdieter> thomasj: oh, and evolution hangs on quit for me when using qtcurve-gtk, but it seems to be a blocking call on something nfs'y (my work box has nfs homedirs)
15:07:02 <thomasj> Hmm.. not even that for me.. Strange
15:07:12 <rdieter> nvm, lets move on then
15:07:16 <thomasj> Yep
15:07:16 <rdieter> #topic F15 Alpha
15:07:21 <Kevin_Kofler> Speaking of oxygen-gtk, I had a GTK+ developer have a look at the code in Brno, he even tried to get it compile with GTK+ 3, but got only 1 or 2 files done. Let's just say he wasn't impressed by the code… ;-)
15:07:52 <rdieter> Kevin_Kofler: more help on that would be nice.
15:08:06 <rdieter> anyway, F15 alpha is upon us.
15:08:09 <Kevin_Kofler> He also said that even if I get it to compile changing stuff file by file as he demoed, it might still not work.
15:09:04 <Kevin_Kofler> I also need to forward the couple suggestions he had to improve readability to upstream.
15:09:43 <Kevin_Kofler> So re the Alpha, we have 2 pending updates that should get in: the kdepim revert and the kdebase-workspace "include upstream default wallpaper because that's what kde-settings currently defaults to" update.
15:09:45 <rdieter> jreznik submitted lovelock-kde-theme pkg review,
15:10:09 <Kevin_Kofler> Right, we want that in F15 ASAP, but it looks like it's missing the Alpha.
15:10:11 <jreznik> anyone to take that review?
15:10:30 <rdieter> Kevin_Kofler: both of those have f15alpha blockers now I think
15:11:00 <ltinkl> ad wallpapers, be aware the the future kde-workspace tarballs from git won't contain any wallpapers
15:11:04 <Kevin_Kofler> Yes, I hope they'll actually get in though.
15:11:10 <rdieter> .bug 677391
15:11:11 <jreznik> .bug 677391
15:11:12 <zodbot> rdieter: Bug 677391 Review Request: lovelock-kde-theme - Lovelock KDE Theme - https://bugzilla.redhat.com/show_bug.cgi?id=677391
15:11:14 <Kevin_Kofler> ltinkl: Oh?
15:11:16 <zodbot> jreznik: Bug 677391 Review Request: lovelock-kde-theme - Lovelock KDE Theme - https://bugzilla.redhat.com/show_bug.cgi?id=677391
15:11:18 <rdieter> hee
15:11:22 <Kevin_Kofler> What will contain them then?
15:11:36 <Kevin_Kofler> Not that it'll be a big issue, we'll be defaulting to lovelock really soon.
15:11:37 <ltinkl> Kevin_Kofler: there is currently a discussion where to place them, git doesn't like binary data
15:11:50 <ltinkl> so it might come in a separate tarball
15:12:11 <rdieter> ltinkl: separate is probably for the best.  they don't see much action after initial release anyway, so less churn
15:12:16 <ltinkl> just saying so that we won't omit them with 4.6.1 :)
15:13:07 <rdieter> ltinkl: the current packaging will ftbfs , and will require fixing anyway
15:13:21 <Kevin_Kofler> Right. We'll also want them on the 1G spin, where we have kdebase-workspace-wallpapers even now.
15:13:31 <rdieter> so, can cross that bridge when we get to it
15:14:27 <ltinkl> yup
15:15:02 <jreznik> ok, what's the status of kde tc2 image? deps solved?
15:15:09 <rdieter> jreznik: yes, fixed
15:15:26 <Kevin_Kofler> And will we get the 2 updates in?
15:15:27 <rdieter> I'll poke other rel-eng'ers about image status
15:15:37 <rdieter> (and the 2 updates)
15:15:41 <Kevin_Kofler> (for RC1/gold, not TC2)
15:15:41 <jreznik> ok
15:16:18 <Kevin_Kofler> OK
15:17:11 <jreznik> another thing - a few people reported changed default font... it happened to me today too
15:17:28 <jreznik> after rawhide update
15:18:09 <rdieter> oh fun.  someone must've played with fontconfig defaults
15:18:27 <Kevin_Kofler> GNOME folks?
15:18:39 <jsmith> Naw, that would never happen :-p
15:18:44 <rdieter> I suppose that's ok, as long as the new one is good (glyph coverage, isn't ugly, yada yada)
15:18:49 * jsmith trolls
15:18:50 <jreznik> looks like abbattis-cantarell
15:18:55 <thomasj> jsmith, lol
15:18:56 <Kevin_Kofler> GNOME 3 defaults to Cantarell, I'd suspect they infected some systemwide configs with that.
15:18:57 <jreznik> rdieter: it's not a good one
15:19:16 <jsmith> Yeah, abbattis-cantarell is the "Gnome 3 default font"
15:19:17 <ltinkl> does the font at least support utf8? :)
15:19:22 <jreznik> maybe with good coverage but not very well readable
15:19:34 <Kevin_Kofler> rdieter: Uh, no, I don't see it as being OK to default Fedora systemwide to the GNOME 3 font without any discussion with anybody else.
15:19:39 <jreznik> and in default settings, it's too small
15:19:51 <rdieter> Kevin_Kofler: sure, good point.
15:20:08 <Kevin_Kofler> It has been well-established that Sans is DejaVu Sans.
15:20:09 <rdieter> ok, file a bug somewhere then (fontconfig?)
15:20:14 <than> the default font should support utf8
15:20:15 <jreznik> it makes sense to have same font over the whole Fedora, but after discussion
15:20:22 <jsmith> jreznik: +1
15:20:22 <Kevin_Kofler> Changing this can also break word processor documents etc.
15:20:29 <jsmith> jreznik: Communication is the key there :-)
15:20:35 <Kevin_Kofler> They should change the GNOME settings, not the fontconfig alias.
15:20:44 <than> Kevin_Kofler: +1
15:21:21 <jreznik> -> report a bug?
15:21:26 <thomasj> +1
15:21:26 <rdieter> #action rdieter to poke rel-eng wrt kde image, and 2 blocker bugs
15:21:40 <than> Kevin_Kofler: but if we want same font for all deskstops we have to change in fontconfig
15:21:43 <rdieter> #info jreznik submitted lovelock-kde-theme pkg for review
15:21:46 <jsmith> ltinkl: From what I understand, it does support utf8... I'm not sure how wide the glyph coverage is, though
15:22:10 <Kevin_Kofler> Definitely smaller than DejaVu's.
15:22:30 <Kevin_Kofler> Really the ONLY property that font has is that it is GNOME 3's upstream default.
15:22:32 <rdieter> #info f15 default fonts, seem to be using abbattis-cantarell now on kde
15:22:36 * ltinkl already sees the number of bugreports from India, China, etc.
15:22:44 <rdieter> someone mind starting a thread on -devel list please?
15:22:59 <Kevin_Kofler> ltinkl: Bad example, Indic and CJK glyphs are covered by other fonts.
15:23:06 <than> the font should wotk at least for china/india/japan
15:23:09 <ltinkl> jsmith: are those fonts available somewhere to download
15:23:27 <ltinkl> Kevin_Kofler: ah ok
15:23:43 <thomasj> If it's not as good as DejaVu, why have it systemwide?
15:23:45 <ltinkl> Kevin_Kofler: but well at least latin scripts and cyrillic should be covered
15:23:48 <Kevin_Kofler> than: DejaVu Sans doesn't include CJK glyphs either. fontconfig fetches those from some other font.
15:24:16 <jsmith> ltinkl: http://abattis.org/cantarell/
15:24:24 <than> Kevin_Kofler: i know, it's still missing in this font
15:24:29 <rdieter> cause, discussing this here, amongst ourselves won't accomplish much.
15:24:46 <Kevin_Kofler> On the KDE spin, that's wqy-microhei, most other spins ship larger fonts (IIRC, wqy-zenhei for Chinese, vlgothic for Japanese and some un-core-* for Korean).
15:24:51 * jsmith also points out that Dave Crossland, the font designer, came to FUDCon Zurich and is trying to get more integrated into Fedora
15:25:11 <jreznik> Kevin_Kofler: probably another stuff for 1G
15:26:39 <rdieter> jsmith: nice
15:27:07 <jreznik> I can start thread at -devel but first - what's our position? make it gnome 3 only? accept it for KDE?
15:27:08 <Kevin_Kofler> Still, I think DejaVu is the much better default.
15:27:13 <Kevin_Kofler> Much larger glyph coverage.
15:27:42 * ltinkl tries out cantarell
15:27:51 <Kevin_Kofler> Plus, IMHO Cantarell looks like a clone of M$ Segoe UI…
15:27:52 <jreznik> Kevin_Kofler: it's subjective but the new one seems to be far less readable... I'll try it again...
15:28:03 <jreznik> Kevin_Kofler: everything has to unifie :)
15:28:07 <jreznik> unify
15:28:10 <thomasj> My personal position is, if they sneak it in, make it gnome 3 only first ;p
15:28:39 <Kevin_Kofler> Compare: http://en.wikipedia.org/wiki/File:Segoe_UI_sample.svg vs. http://abattis.org/cantarell/
15:28:40 <jreznik> I'm more for the same font over the whole Fedora but I'm not sure this is the right one
15:29:00 <ltinkl> so
15:29:06 <ltinkl> Cantarell has only latin sets
15:29:14 <ltinkl> no Cyrillic for example
15:29:36 <Kevin_Kofler> My position is: Sans should be DejaVu Sans. If they really want to default to Cantarell in GNOME, that should be a GNOME setting, not a fontconfig alias.
15:29:42 <ltinkl> unusable to use as a system wide font
15:29:51 <than> ltinkl: +1
15:30:01 <Kevin_Kofler> So, is my proposal OK?
15:30:08 <ltinkl> Kevin_Kofler: yup
15:30:15 <thomasj> yep
15:30:23 <than> Kevin_Kofler: revert to  DejaVu Sans.
15:30:32 <Kevin_Kofler> Let's record my proposal as a general KDE SIG position then.
15:30:43 <jreznik> Kevin_Kofler: +1, yep, even I prefer one font in Fedora, this looks really bad and the readibility is much more worst
15:30:45 <rnovacek> yes, revert
15:30:56 <Kevin_Kofler> than, rnovacek: You want DejaVu Sans even in GNOME? To be honest, I don't care what GNOME defaults to and I think this is not KDE SIG's business.
15:31:01 <rdieter> I'd rather start the discussion on where and how the change was made first, before making counter proposals or demands
15:31:05 <jreznik> too wide so a lot of stuff overflows
15:31:09 <Kevin_Kofler> But it should be reverted in fontconfig.
15:31:10 <ltinkl> it should be noted it's not only our decision, in fact it's a regression if a system wide font can't support what DejaVu does
15:31:23 <Kevin_Kofler> ltinkl: +1
15:31:29 <rnovacek> I don't care about gnome
15:31:32 <than> Kevin_Kofler: in my opinion it's better to have same font for all desktops by default
15:31:48 <ltinkl> yup, DejaVu does that fine
15:32:07 <jreznik> than: yep but I don't think desktop team would change their minds, but I agree with rdieter - we should at least try it
15:33:12 <than> yes, we should discuss with gnome folks before
15:33:19 <rdieter> I can try to start the discussion, but I don't think I'm very qualified to do so (being the monolingual american I am)
15:33:23 <Kevin_Kofler> So, next proposal: KDE SIG agrees that the systemwide fontconfig aliases must default to Sans. If the GNOME maintainers really want to default to Cantarell in GNOME, that should be a GNOME setting, not a fontconfig alias, however we urge them to reconsider even that decision due to concerns over glyph coverage and aesthetic issues.
15:34:04 <rdieter> -1 to any 'proposals' that occur prior to discussion on -devel
15:34:19 <rdieter> (imo)
15:34:19 <jreznik> the first question is - was it intentional? or just bug?
15:34:56 <than> i don't think it's intentional
15:34:59 <jreznik> I see only mass rebuild in fontconfig package
15:35:01 <thomasj> I'm for a discussion as well, but i would like to see the next one started by the GNOME folks before some changes.
15:35:16 <Kevin_Kofler> Hmmm, evil plan: aren't fontconfig settings overridable per user, with KDE offering some UI to edit aliases? If so, can't we just override the aliases in KDE? :-)
15:35:29 <rdieter> thomasj: if it was truly unintentional, then it's hard to discuss it beforehand.
15:35:34 <thomasj> Right
15:35:50 * thomasj is a bad boy and doubts that
15:35:51 <jreznik> rdieter: report bug before? ping some desktop folks?
15:35:53 <ltinkl> I DO think it's intentional
15:36:04 <thomasj> me too
15:36:07 <thomasj> sorry
15:36:07 <rdieter> jreznik: discuss on -devel list
15:36:24 <jsmith> I don't think we should ascribe to malice that which can be explained by lack of communication, without having any further evidence
15:36:26 <jreznik> maybe it was set before and now it drags the new font, so it's used system wide
15:36:32 <rdieter> jsmith: +++++++
15:36:36 <ltinkl> well it hasn't been discussed but I'm sure I saw some blog post from mizmo about it
15:36:41 <than> yes, report the bug, ask them if it's really intentional
15:37:03 <jreznik> ltinkl: but not system wide
15:37:08 <jreznik> let's discuss it first
15:37:13 <ltinkl> of course
15:37:17 <jreznik> not a good to make assumptions here
15:37:32 * ltinkl already sees the outcome :)
15:37:35 <rdieter> so, I ask again, anyone want to lead this topic on -devel (besides me)?
15:37:36 <ltinkl> nvm
15:37:43 <jreznik> rdieter: could you start the thread? we can join...
15:37:49 <rdieter> ok, me it is
15:37:58 <rdieter> #action rdieter to start -devel thread on default font topic
15:37:59 <jsmith> rdieter: I could do it if you don't want to
15:38:04 <jreznik> I can do it - but I really lack fontconfig skills
15:38:11 * Kevin_Kofler is so fed up of systemwide theming being changed to match GNOME 3 defaults.
15:38:15 <rdieter> jsmith: oooh, please do if you have the time/energy
15:38:16 <Kevin_Kofler> See also the cursor mess.
15:38:22 * jsmith can play the "I'm just a simple caveman, and don't understand fonts" card
15:38:23 <Kevin_Kofler> (which is still not fixed)
15:38:31 <thomasj> jsmith, awesome, thanks!
15:38:35 <jsmith> rdieter: I don't have time, but can do it anyway
15:38:36 <rdieter> suh weet, I like that card
15:38:37 <jreznik> jsmith: :)
15:38:46 <jreznik> thanks jsmith
15:38:58 <rdieter> let's move on then
15:39:08 <Kevin_Kofler> Hmmm, WTF, libreoffice-langpack-* requires Cantarell in Rawhide? Why?
15:39:16 <ltinkl> there you go :)
15:39:31 <ltinkl> unintentional? no way
15:39:39 <thomasj> hehe
15:39:48 <rdieter> #topic akonadi: switch to sqlite default backend?
15:39:50 <thomasj> It's the experience.. ;p
15:39:50 <Kevin_Kofler> The other package requiring it is gnome-themes-standard.
15:40:05 <jreznik> I can understand choosing a new default font, even a little bit forcing it but please - announce it to the right people :)
15:40:24 <Kevin_Kofler> I really don't think this is acceptable.
15:40:27 <rdieter> played with this a bit, found some other distros doing the same (gentoo, in particular)
15:40:33 <ltinkl> they are the right people, the don't have to announce it to themselves :)
15:40:34 <Kevin_Kofler> The default font should be chosen by the Fonts SIG.
15:40:39 <Kevin_Kofler> Not the GNOME team.
15:40:49 <rdieter> (save discussion for the upcoming -devel thread please)
15:40:49 <jreznik> ok, let's move to Akonadi
15:40:50 <rdieter> :)
15:41:35 <jreznik> my question is - migration from mysql to sqlite, is it possible?
15:41:42 <rdieter> now that we've flipped back to kdepim-4.4.x, using the simpler (but slower) sqlite akonadi backend is possible
15:41:44 <thomasj> sqlite is faster IIRC so sounds like a good plan.
15:41:46 <rdieter> jreznik: no migration
15:41:56 <Kevin_Kofler> thomasj: SQLite is supposedly much slower.
15:42:04 <rdieter> but switching the default won't disable mysql support
15:42:04 <thomasj> args, really?
15:42:21 <rdieter> existing users will continue to use mysql, I believe.
15:42:23 <jreznik> rdieter: but what when we switch again to new kdepim?
15:42:57 <rdieter> jreznik: for f16?  sure, we'll likely want to switch back then
15:43:06 <rdieter> but maybe its not worth the hassle
15:43:09 <Kevin_Kofler> Then why switch to SQLite now and back in F16?
15:43:09 <jreznik> rdieter: so old users will stick with mysql, new with sqlite
15:43:15 <rdieter> jreznik: I think so
15:43:27 <Kevin_Kofler> Plus, what about people installing from F15 and then upgrading, they'll be stuck with SQLite.
15:43:43 <jreznik> rdieter: but then I don't see a reason why to change it for F15, we should stick with mysql and make sure it's ready for new kdepim by f16
15:44:17 * jreznik is not a big fan of mysql as backend but I don't see any advantage here
15:44:22 <than> there're some issue with deadlocks and failing transactions by using sqlite
15:44:36 <rdieter> than: those bugs were fixed, iirc
15:44:41 <than> ah ok
15:44:45 <rdieter> akonadi ships a patched sqlite qt connector
15:44:47 <Kevin_Kofler> My vote is to stick with MySQL.
15:45:07 <thomasj> If we switch back anyways, yeah
15:45:22 <rdieter> ok, migration sounds like a possible pain-point.
15:45:57 <rdieter> are we agreed to stick with mysql then?
15:46:08 <ltinkl> yup
15:46:21 <rdieter> #agreed stick with akonadi mysql backend default
15:46:48 <rdieter> #topic qt-devel should require qt-sqlite, bug #677418
15:46:52 <rdieter> .bug 677418
15:46:54 <zodbot> rdieter: Bug 677418 qt-devel should require qt-sqlite - https://bugzilla.redhat.com/show_bug.cgi?id=677418
15:47:27 <rdieter> anyone opposed to getting rid of qt-sqlite subpkg, and fold it into main qt ?
15:47:54 <Kevin_Kofler> Well, most stuff doesn't actually need it…
15:48:22 <rdieter> it's a whopping 50k subpkg, what's the point of keeping it?
15:48:24 <Kevin_Kofler> qt-devel does, qt-assistant too (which is why it got dragged in by qt-x11 until now), I guess some other stuff does (but hopefully has a Requires on it…).
15:48:51 <rdieter> and I'd rather avoid the whack-a-mole game of adding deps everywhere
15:49:40 <rdieter> but I'm ok with either approach, even if I do biasedly prefer the simpler one
15:50:01 <rnovacek> it's only 50k, so I'm for merging
15:50:16 <Kevin_Kofler> For the size, there's also sqlite itself, but then again, a lot of stuff including yum-metadata-parser requires it, so chances are it's always there anyway.
15:50:35 <Kevin_Kofler> I guess it's OK to fold it into the main qt package.
15:50:39 <than> i'm not fan for subpackes
15:51:39 <rdieter> to maintain balance of the force, we recently added qt-assistant, qt-config, so we have to remove some. :)
15:51:44 <jreznik> it makes sense to have qt-dbsupport subpackages
15:52:13 <jreznik> but sqlite is little bit different - more like the default of defaults so I'm ok with it
15:53:27 <rdieter> #agreed will fold qt-sqlite into main qt pkg to fix bug #677418 (and hopefully all future variants)
15:53:40 <rdieter> #topic 1G image: keep (yes/no)? If yes, what to add (there's room left).
15:54:05 <rdieter> a few minutes left to discuss fate of the daily 1GB kde image being produced
15:54:45 <rdieter> my own opinion:  as long as resources required to produce it aren't a problem, I'd say keep the .ks's around and daily builds
15:55:26 <jreznik> +1
15:55:31 <Kevin_Kofler> So to be honest, I'm of the mindset to drop the 1G image… It just causes confusion (in fact, we've had a few issues with the nightlies due to the wrong kickstart, the wrong logfile etc. being used), it's extra work to maintain (just see how its size isn't anywhere near 1G, still) and we were able to readd the stuff dropped on the way to F14 to the CD-sized image now.
15:55:58 <Kevin_Kofler> I really don't see the benefit of maintaining 2 kickstarts instead of 1 given the above.
15:56:08 <thomasj> If there's room left, i would really like to see luckybackup on it. In case there's no GUI backup solution on it yet.
15:56:15 <Kevin_Kofler> We had a size issue, xz solved it.
15:57:03 <Kevin_Kofler> thomasj: The problem is, we're going to get tons of suggestions of this kind, who decides what gets added and based on what criteria?
15:57:07 <rdieter> we already committed to keeping the split .ks's now, for other reasons, like making it easier to do derivative spins
15:57:11 <Kevin_Kofler> There isn't going to be room for ALL suggestions.
15:57:17 <rdieter> so, "dropping it" isn't really an option
15:57:35 <Kevin_Kofler> rdieter: WE didn't commit to anything.
15:57:48 <rdieter> ok, *I*. :)
15:57:58 <thomasj> The criteria here is that a GUI backup solution isn't a bad idea for a live image.
15:58:05 <rdieter> I did mention it as one of the reasons for doing this, when it was discussed
15:58:20 <Kevin_Kofler> And having the Base part split doesn't imply that we need to have 2 derived kickstarts, either. :-p
15:58:45 <Kevin_Kofler> (but FWIW, I'm for undoing the split, I see it as being only extra work for no benefit)
15:58:47 <rdieter> true, but it keeps us honest, exposes bugs we'd otherwise miss
15:59:25 <rdieter> I see the bigger spin .ks, as not being touched much, obviously now that we're focussing on a cd image again, most of our attention and work will go there
15:59:36 <rdieter> I fail to see the harm, honestly
15:59:41 <thomasj> +1
15:59:46 <Kevin_Kofler> Another issue with the split is: whom do we split for? To make OUR work easier or to make derivative spin work easier…
15:59:50 <Kevin_Kofler> Currently, we're doing the latter.
16:00:04 <Kevin_Kofler> To do the former, all the common stuff from the 2 derived kickstarts should be in Base.
16:00:21 <Kevin_Kofler> But that would imply doing a lot of customization in Base which derivative spins won't necessarily like.
16:00:43 <rdieter> there's different levels of customization
16:00:46 <Kevin_Kofler> OTOH, what we do know just sucks, there's a lot of copypasta between the 2 derived kickstarts.
16:00:52 <Kevin_Kofler> s/know/now/
16:01:08 <rdieter> sure, it still should be cleaned up a bunch, what's there was a very simple first pass at it
16:01:30 <Kevin_Kofler> And you don't see the harm of having an unmaintained kickstart sit there?
16:01:48 <rdieter> it's not unmaintained, just not our primary focus
16:02:01 <Kevin_Kofler> One which claims to be 1G, but is actually 800-something MiB, just enough not to fit on a CD-R90, but wasting a lot of size on 1G media?
16:02:22 <Kevin_Kofler> We should only keep what we're actually actively maintaining.
16:02:23 <rdieter> it doesn't claim to be 1G, it's just not called livecd
16:02:34 <Kevin_Kofler> The nightlies call it 1G.
16:02:50 <rdieter> nirik must've just picked that to differentiate it
16:02:57 <Kevin_Kofler> And anyway, having a 700 MiB spin and a 850 MiB spin strikes me as utterly useless.
16:03:18 <rdieter> times up, anyway
16:03:40 <Kevin_Kofler> If we aren't prepared to do the work to select more stuff to put on it, we should be honest and not claim we support that kickstart.
16:03:53 <Kevin_Kofler> And the best way to do that is to stop generating nightlies and removing it from spin-kickstarts.
16:04:04 <thomasj> So lets put more stuff on it.
16:04:14 <rdieter> let's continue on in #fedora-kde
16:04:17 <Kevin_Kofler> If somebody wants to maintain it, they can have it in their own repo or apply for spin-kickstarts push access and readd it there.
16:04:22 <rdieter> thanks everyone
16:04:25 <rdieter> #endmeeting