13:58:09 <rdieter> #startmeeting kde-sig -- http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2010-09-07
13:58:09 <zodbot> Meeting started Tue Sep  7 13:58:09 2010 UTC.  The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:58:09 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:58:14 <rdieter> #meetingname kde-sig
13:58:14 <zodbot> The meeting name has been set to 'kde-sig'
13:58:26 <rdieter> #topic roll call
13:58:30 <rdieter> who's present today?
13:58:47 * thomasj is here
13:58:51 <rnovacek> I'm here
13:59:01 <rdieter> ping: than jreznik Kevin_Kofler kde*foo*
13:59:09 * than is present
13:59:10 * jreznik is here
13:59:21 * SMParrish here
13:59:37 * ltinkl is here
13:59:55 <rdieter> #chair than jreznik ltinkl SMParrish Kevin_Kofler
13:59:55 <zodbot> Current chairs: Kevin_Kofler SMParrish jreznik ltinkl rdieter than
14:00:01 <Kevin_Kofler> Present.
14:00:18 <rdieter> #info rdieter thomasj rnovacek than jreznik SMParrish ltinkl Kevin_Kofler present
14:01:03 <rdieter> let's get the easy bit(s) out of the way first
14:01:13 <rdieter> #topic nominate thomasj ACLs for KDE core packages
14:01:56 * rdieter supports adding thomasj commit access for core packages, comments, discussion?
14:02:02 * rdieter runs for a quick coffee
14:02:16 <Kevin_Kofler> No objections here.
14:02:31 <Kevin_Kofler> I'll be there to yell at him if he screws up. ^^
14:02:38 <jreznik> +1
14:02:38 <thomasj> :)
14:02:54 <SMParrish> +1
14:02:55 <thomasj> I tend to ask before i screw up :)
14:03:02 <jreznik> Kevin_Kofler is great fail-bot :)
14:03:02 <Kevin_Kofler> Any helping hands are always welcome.
14:03:07 <than> +1
14:04:08 <Kevin_Kofler> So that's 5 people in favor and no objections, I'd say it's accepted. :-) We can move on.
14:04:20 <rdieter> sounds good to me
14:04:22 <thomasj> Thanks guys :)
14:04:42 <ltinkl> +1 for posterity :)
14:04:43 <jreznik> thomasj: thanks for you interested in helping us!
14:04:50 <rdieter> #agreed thomasj core kde acl's approved
14:04:55 <thomasj> anytime jreznik
14:05:06 <rdieter> thomasj: apply away in pkgdb
14:05:19 <rdieter> #topic Fedora's Stability Policy Implementation - What do we need?
14:05:34 <rdieter> SMParrish: ? , can you give a little background here?
14:05:47 <thomasj> rdieter, will do, thanks
14:07:05 <SMParrish> We are working on the exceptions to the Stability guidelines and need to know what KDE anticipates needing
14:07:30 <SMParrish> I was thinking we would need 1 exception per Fedora release for the major bump of KDE
14:07:41 <rdieter> SMParrish: I assume this is mostly about pushing kde-4.(x+1) updates?  ok
14:08:21 <rdieter> that should be sufficient
14:08:32 <Kevin_Kofler> We need that whole shitty policy overturned.
14:08:37 <SMParrish> Yes it is.  And the exception would be to allow it to get pushed to the current Fedora release not F(n-1)
14:08:59 <Kevin_Kofler> That's clearly insufficient.
14:09:12 <rdieter> Kevin_Kofler: :)  that's a bit outside the scope of this discussion though
14:09:13 <jreznik> why exceptions? it should be more on assuring updates are not breaking things than just making strict policies with bunch of exceptions
14:09:15 <jreznik> I
14:09:16 <thomasj> That's helpful to get the exception
14:09:32 <ltinkl> so what about Fn-1? do we need an extra exception for each maintained release?
14:09:43 <jreznik> I'm not sure there's another team who cares so much about updates as we...
14:09:46 <SMParrish> jreznik: anything that changes the users experience mid release will need an exception
14:10:09 <thomasj> ltinkl, as far as i understand, there will be no exception for F(n-1).
14:10:16 <SMParrish> bug fixes and security fixes are fine but no feature updates or changes
14:10:35 <ltinkl> so we won't be able to push KDE 4.x.y+1?
14:10:41 <jreznik> SMParrish: but why? why not to work on best updates and best user experience at first? I still don't understand this policy... even more strict than all other OS out there...
14:10:51 <SMParrish> thomasj: That's right because F(n-1) would have had its one exception when it was F(n)
14:10:56 <thomasj> Only bug and security fixes, yes.
14:10:59 <rdieter> fwiw, I'm currently asking the board to re-evaulate the wording on their updates statement to remove (or amend) the phrase "bug and security fixes only"
14:11:15 <SMParrish> ltinkl: we can push those since they are bug releases
14:11:16 <jreznik> no updates != stability!!!
14:11:26 <Kevin_Kofler> jreznik: +1
14:11:38 <thomasj> jreznik, updates, yes, just not major updates to F(n-1)
14:11:40 <Kevin_Kofler> This whole policy is a bunch of bovine manure.
14:11:50 <ltinkl> so no 4.5 for eg. F12?
14:11:55 <thomasj> right
14:11:58 <ltinkl> sux
14:11:58 <Kevin_Kofler> We should just declare all our updates as bugfix and be done with it.
14:12:00 <SMParrish> ltinkl: right
14:12:00 <jreznik> ltinkl: no... it's too late
14:12:22 <rdieter> personally, I'm ok with fesco reviewing things on a case-by-case basis, if they're interested in that too.
14:12:27 <ltinkl> they are bugfixes in fact, they just add some new features as well
14:12:32 <Kevin_Kofler> Right.
14:12:36 <Kevin_Kofler> And we should push them as such.
14:12:36 <jreznik> the first problem is in our releases - read adaw's blogpost
14:12:45 <Kevin_Kofler> And FESCo should leave their hands off our work.
14:12:45 <rdieter> but having an exception for at least on semi-planned update works too
14:12:49 <jreznik> rdieter: indeed it's better than nothing
14:12:53 <Kevin_Kofler> I'm really fed up of the increasing bureaucracy.
14:12:58 <rdieter> s/on/one/
14:13:05 <jreznik> I think we can assure quality of our updates
14:13:17 * thomasj is fine with having just bugfix updates for F(n-1) as long as we can push one major update to Fn
14:13:21 <SMParrish> FESCo is only doing what they are instructed to do by the board, thats where this came from
14:13:23 <jreznik> our update process is even much more better than any bodhi karmas thing
14:13:58 <thomasj> The whole idea is to not break the workflow for F(n-1) users.
14:13:58 <jreznik> SMParrish: I understand - but if board says you have to kill bunny, would you kill the bunny? :D
14:14:19 <SMParrish> Nothing will prevent us from having the kde-redhat repo where people can download these updates.  Just cant go in the official repos
14:14:22 <jreznik> thomasj: I understand but I don't understand why on both Fn and Fn-1
14:14:23 <ltinkl> kill the bunny!
14:14:26 <Kevin_Kofler> jreznik: +1, that karma stuff is useless.
14:14:31 <rdieter> so, any objections to asking for a single exception for a kde-4.(x+1) update ?
14:14:37 <SMParrish> jreznik: no bunny killer here, but the board would just find someone else to do it
14:14:40 <thomasj> jreznik, Fn gets 4.5 for example, just Fn-1 not
14:14:42 <Kevin_Kofler> rdieter: Yes, it's not enough.
14:14:48 <SMParrish> jreznik: so either way you have a dead bunny
14:14:50 <jreznik> thomasj: yes
14:14:54 <Kevin_Kofler> We need a blanket exception to upgrade any and all KDE packages on any and all releases.
14:15:11 <Kevin_Kofler> Just KDE core won't help for all the extragear apps, either.
14:15:13 <rdieter> Kevin_Kofler: let's take baby-steps
14:15:17 <jreznik> Kevin_Kofler: not all releases... but to have one fresh and one so called semi-stable
14:15:44 <Kevin_Kofler> jreznik: I know about that idea (you and SMParrish have been suggesting it for a while), but I still don't see how it makes any kind of sense.
14:15:45 <ltinkl> I'm with Kevin here, we should be the ones to decide what to push out
14:15:52 <rdieter> our goal of providing the latest kde release is still achievable here
14:15:57 <jreznik> Kevin_Kofler: at least - it's compromise
14:16:01 <Kevin_Kofler> As long as a release is supported, it should be fully supported.
14:16:08 <ltinkl> agreed
14:16:11 <jreznik> and now it's one or nothing
14:16:16 <Kevin_Kofler> No second-class support.
14:16:20 <jreznik> and still better than nothing
14:16:25 <rdieter> Kevin_Kofler: yes and no
14:16:33 <ltinkl> 4.5 is declared as a stable release, no reason to be banned from pushing it into F12
14:16:35 <rdieter> serious question: who here at the meeting is still running f12?
14:16:38 <thomasj> Kevin_Kofler, We have people who don't want their workflow broken. And a major update does that. Many things changes.
14:17:01 <thomasj> Kevin_Kofler, that might get better in the future, since the big changes are almost over.
14:17:03 <rdieter> because, we need core packagers/developers to be using/testing this too.
14:17:05 <Kevin_Kofler> 4.n+1 is not major, 5.0 would be.
14:17:09 <ltinkl> thomasj: you don't have to install the update, nobody forces you to
14:17:18 <thomasj> ltinkl, i know
14:17:19 <jreznik> thomasj: even OS X users live with that and they are just BFUs...
14:17:19 <ltinkl> and yes, 4.x is not a major release
14:17:21 <SMParrish> support = fix bugs and security issues, not introduce new features.  Thats what the new release is for.  Will encourage people who want the latest and greatest to upgrade
14:17:28 <thomasj> Or better to say *I* know
14:17:42 <jreznik> SMParrish: problem is - we can't decouple it!!!
14:17:57 <jreznik> it's new kde or no bugfixes
14:18:10 <rdieter> yeah, the implication is that we're suggesting folks have to live with bugs (or upgrade f+1)
14:18:12 <jreznik> maybe some work on security fixes...
14:18:13 * thomasj feels kind of lonely when it comes to updates policy :D
14:18:15 <Kevin_Kofler> Right, we basically cannot fix anything in 4.n after 4.n+1 is out, because KDE upstream stops supporting 4.n at that point.
14:18:29 <Kevin_Kofler> We can backport a bunch of fixes, but that's nothing against the hundreds of bugs that get fixed by 4.n+1.
14:18:41 <than> Kevin_Kofler: +1
14:18:41 <SMParrish> jreznik: I know and I explained that to FESCo, but no go.  We have to backport the fixes ourselves
14:18:52 <jreznik> SMParrish: but we can't!!!
14:18:55 <thomasj> How long will F(n-1) be supported once the next major version is out, in the worst case?
14:18:57 <rdieter> back to f12 though, if no one here is even using f12 anymore, I can't recommend we push any major updates there anymore.
14:18:58 <jreznik> it's usually impossible...
14:18:58 <thomasj> 5 month?
14:19:09 <ltinkl> that's nonsense, we just have to follow upstream releases (KDE)
14:19:19 <than> SMParrish: it doesn't make sense
14:19:23 <Kevin_Kofler> At this point I just say, fuck it, we just push the updates and watch them scream and whine.
14:19:25 <jreznik> rdieter: F12 is now dead from our pov - too late for 4.5
14:19:38 <ltinkl> with the current state, we wouldn't be able to push updates into F12 for months
14:19:40 <Kevin_Kofler> We call them bugfix, maybe we even call them 4.4.5-10 and it's really 4.5.1, I don't care.
14:19:45 <ltinkl> coz there is no newer KDE 4.x release
14:19:53 <rdieter> jreznik: we can't even argue for it, if no one here is using it... hardly supportable
14:19:54 * skvidal decides to take a log of this conversation
14:20:02 <Kevin_Kofler> I can easily "backport" a patch which just updates 4.4.5 to 4.5.1.
14:20:16 <jreznik> Kevin_Kofler: ;-)
14:20:19 <thomasj> Kevin_Kofler, then we could as well backport the bugfixes ;)
14:20:44 <ltinkl> Kevin_Kofler: haha, SUSE way, one huge patch tracking the branch :)
14:20:45 <Kevin_Kofler> thomasj: Uh, no.
14:20:47 <Kevin_Kofler> You can't easily pick them out of the huge diff.
14:20:48 <ltinkl> pls we have to avoid this
14:20:56 <SMParrish> Our biggest issue is that Fedora is based around gnomes release cycle and not KDE's.  That isn't going to change so unless KDE wants to change their release cycle we have to work within the guidelines
14:20:57 <thomasj> Kevin_Kofler, i know
14:21:11 <jreznik> SMParrish: yes, that's the problem
14:21:23 <rdieter> SMParrish: pros and cons to that, yeah
14:21:39 <jreznik> it's much easier for gnome guys - just change release dates and first who would scream would be gnome guys
14:21:41 <Kevin_Kofler> SMParrish: The biggest problem is that we can't sync to all upstream schedules in the first place.
14:22:03 <Kevin_Kofler> So that stupid "stability" idea will always mean lagging behind upstream.
14:22:20 <ltinkl> and would in fact mean no stability fixes at all
14:22:24 <Kevin_Kofler> The big problem here is FESCo, and it's sad that the remainder of FESCo isn't listening to you.
14:22:26 <SMParrish> there is nothing stopping us from supporting every release with our own repo
14:22:28 <Kevin_Kofler> ltinkl: +1, that too.
14:22:30 <rdieter> I can poke kde release team if support for 4.(x-1) can be extended for another 1-3 months, see how that goes
14:22:39 <thomasj> There was nirik, asking if they could move the gnome release. Though i doubt he was serious :)
14:22:39 <Kevin_Kofler> SMParrish: That's exactly what's going to happen indeed.
14:22:39 <jreznik> what I think we should do - we should have a meeting with a few board and fesco people and explain them our problems... I know - they are not going to listen us but at least, we should try
14:22:44 <Kevin_Kofler> PPA chaos FTW… not. :-/
14:22:56 <Kevin_Kofler> The policy is broken.
14:23:10 <ltinkl> indeed, no separate repo will solve that
14:23:12 <SMParrish> Kevin_Kofler: And FESCo has no issue with that, in fact they support that
14:23:28 <Kevin_Kofler> SMParrish: If they don't see the problem, that's really sad.
14:23:31 <jreznik> SMParrish: it's unofficial repo, it's out of our infrastructure... and it's going to cause a lot of problems for us, users...
14:23:43 <Kevin_Kofler> An explosion of 3rd party repos == an explosion of compatibility concerns.
14:23:44 <rdieter> can I mark for the record that we ask for 1 update exception per release ?
14:23:59 <thomasj> +1
14:24:00 <Kevin_Kofler> Remember all the "ATrpms replaces Fedora packages" whines back in the day when they did that?
14:24:19 <rdieter> well, atrpms not only did that, but did it in an incompatible way
14:24:19 <Kevin_Kofler> Now imagine dozens of repos working like ATrpms used to (they don't do this so aggressively these days).
14:24:32 <Kevin_Kofler> rdieter: Well, you can't always be compatible. Sonames change.
14:24:33 <rdieter> so apples vs oranges
14:24:35 <jreznik> Kevin_Kofler: this policy would lead to explosion of 3rd party repos... it's sad once we have rpmfusion
14:24:41 <Kevin_Kofler> And repos don't normally build against each other.
14:24:44 <thomasj> We would have the latest and greatest in Fn, *just* F(n-1) stays with minor updates.
14:24:50 <Kevin_Kofler> So compatibility issues WILL arise.
14:25:16 <rdieter> #agreed kde-sig agrees to ask fesco for 1 update exception per fedora release
14:25:19 <jreznik> thomasj: at least Fn - we need that exception
14:25:21 <ltinkl> another argument, this will mean more work for us, packagers
14:25:21 * thomasj can't see the problem. If people want the latest and greatest, they upfgrade to Fn, if not, they stay with their working installation.
14:25:26 <Kevin_Kofler> Just imagine: we bump kdegraphics to a version with new sonames for the kipi stuff (like 4.5), some other repo bumps some other lib used by Digikam.
14:25:27 <thomasj> jreznik, we will get it
14:25:28 <ltinkl> currently we sync all the branches
14:25:32 <Kevin_Kofler> rdieter: Uh, did we agree on that?
14:25:43 <rdieter> Kevin_Kofler: I asked twice for objections, and heard none
14:25:50 <Kevin_Kofler> rdieter: There was mine.
14:25:57 <Kevin_Kofler> The exception is clearly insufficient.
14:25:57 <jreznik> thomasj: at first - it's nonsense to have two releases out together!
14:26:01 <rdieter> you didn't object, just that it's not enough.
14:26:03 <rdieter> :)
14:26:09 <Kevin_Kofler> The result: the rebuilds of Digikam by the 2 repos will clash.
14:26:18 <Kevin_Kofler> That's the problem with the 3rd-party repo approach.
14:26:27 <nucleo> If dbus can not be updated to 1.3.x in F12,F13 then would be problems with dolphin hangup in KDE 4.5.1 https://bugs.kde.org/show_bug.cgi?id=232054 Is this can be fixed somehow with KDE 4.5.1 update for F13?
14:26:35 <thomasj> jreznik, i understand your point. But we dont have to do any extra work. just not building 4.x+1 for Fn-1
14:26:42 <rdieter> nucleo: that's only fixable in dbus
14:26:58 <jreznik> thomasj: ok, let's say - kde sig does not support Fn-1 and it's done...
14:27:18 <ltinkl> we cannot declare that
14:27:19 <jreznik> if someone asks why - we can answer fesco/board asked us to not support it anymore
14:27:23 <thomasj> jreznik, why, we support it. We just can't fix any late bugs.
14:27:32 <Kevin_Kofler> We can't really desupport a supported release.
14:27:32 <nucleo> so, if no dbus update then KDE 4.5.1 update for F13 wil be with this bug
14:27:33 <rdieter> jreznik: yep
14:27:33 <jreznik> thomasj: yes => no support
14:27:34 <Kevin_Kofler> This is not an option.
14:27:35 <thomasj> jreznik, but people are able to upgrade to Fn to have the new builds.
14:27:50 <jreznik> Kevin_Kofler: we have to, we don't have manpower to support it
14:27:54 <rdieter> nucleo: yes, f12/f13 has had that bug for a very long time
14:28:02 <than> it seems we force users to update to new fedore release
14:28:20 <thomasj> The ones who wants the latest and greatest. Yes
14:28:40 <thomasj> that's better than to force them to use rawhide, as some want.
14:28:45 <jreznik> we don't have any other choice...
14:29:03 <nucleo> rdieter: you mean in KDE 4.4 too?
14:29:05 <rdieter> in our particular case for 4.5.x, I'm starting to have doubts that our blocker list will be cleared before f12 goes eol anyway, so perhaps the point is moot
14:29:13 <rdieter> nucleo: yes
14:29:16 <Kevin_Kofler> jreznik: There's just no alternative to updating.
14:29:26 <Kevin_Kofler> Desupporting a supported release is impossible.
14:29:33 * thomasj just got one bug fixed from the blocker
14:29:37 <than> it's bad for users who wants to stay by fn-1!
14:29:39 <rdieter> nucleo: it's just recently nepomuk is becoming more useful, so the bug is more visible
14:29:44 <nucleo> for me it only happens in 4.5.1 and in 4.4.5 no
14:29:55 <than> but itfor use
14:30:06 <SMParrish> than: but those users want the stability f(n-1) offers thats why they are still running it
14:30:16 <thomasj> +1
14:30:26 <rdieter> SMParrish:  +1 , at least users will have a choice
14:30:31 <ltinkl> stabilty doesn't mean no updates at all
14:30:33 <jreznik> rdieter: f12 and 4.5 is out of issue right now - it's too late...
14:30:43 <Kevin_Kofler> rdieter: I'm starting to think we should just push out 4.5 with the remaining blockers…
14:30:57 <Kevin_Kofler> I'll have another look at them over the week, then we can decide at the next meeting what to do.
14:30:59 <rdieter> Kevin_Kofler: why?  out of spite?
14:30:59 <SMParrish> ltinkl: no but stability does mean everything works today like it did yesterday.  No new features
14:31:01 <than> SMParrish: it causes a lot of works for us to backport fixes from kde 4.x+1
14:31:17 <Kevin_Kofler> rdieter: Out of "users keep asking us for it and we already skipped 4.5.0".
14:31:19 <jreznik> Kevin_Kofler, than: I don't understand why we have to support two releases at all and now with stability policies - two conserved and dead releases
14:31:32 <thomasj> than, there shouldn't be the need to do so. Except for security fixes.
14:31:38 <Kevin_Kofler> jreznik: Because it's Fedora policy.
14:31:41 <Kevin_Kofler> And that's the whole problem.
14:31:42 <rdieter> Kevin_Kofler: users aren't asking for breakage, they just want shiny.
14:32:04 <Kevin_Kofler> They're asking us to support an old KDE for ages.
14:32:13 <jreznik> SMParrish: it's not always true - if we can't fix things...
14:32:15 <thomasj> ages?
14:32:25 <rdieter> ages = ~6 months ish
14:32:30 <thomasj> Kevin_Kofler, with ages you mean in the worst case 5 month.
14:32:47 <Kevin_Kofler> ltinkl: +1, stability means FIXING bugs, not leaving them sit forever.
14:33:32 <rdieter> look, with 1 kde update per fedora cycle, we'll still have very good coverage
14:33:38 <ltinkl> it's solvable if KDE upstream agrees to maintain the n-1 branch for a longer time than now
14:33:43 <rdieter> 'release' coverage that is.
14:33:57 <SMParrish> Just keep in mind we are only talking about support for a release that will usually go EOL within 3 months anyway.  They dont need the latest and greatest
14:34:03 <jreznik> Kevin_Kofler: +1, I agree some changes between two KDE releases from the desktop view are quite a big - but not so big as even other OSes
14:34:08 <rdieter> ltinkl: +1, and that remaining time could be mitigated with 1-3 months of support upstream
14:34:15 <jreznik> SMParrish: agree
14:34:27 <rdieter> with 1-3 *additional) months... that is
14:34:56 <ltinkl> exactly, so F13 version would get KDE 4.5.x, olders ferdoa releases would stay with KDE 4.4.x+updates
14:35:17 <Kevin_Kofler> SMParrish: But WHY should we give them second-class support?
14:35:29 <thomasj> Yes, f14 4.6 and f13 then with 4.5.x+1
14:35:35 <Kevin_Kofler> And I don't think upstream will want to support the old branch for longer, they're already swamped.
14:35:38 <ltinkl> but that means there have to be some more releases in KDE 4.4 after KDE 4.5 gets released
14:35:45 <jreznik> Kevin_Kofler: why to have two nearly same Fedora releases?
14:35:48 <Kevin_Kofler> And by their logic, there's no reason to use the old branch when there's a newer, better one out there.
14:35:53 <SMParrish> Kevin_Kofler: Becasue that what upstream is giving us by not supporting previous releases.  Its the same thing
14:36:37 <Kevin_Kofler> jreznik: The major changes are not done. But KDE releases should NOT be a major change. If they are, something is wrong in upstream's release process.
14:36:50 <Kevin_Kofler> We've seen the regression rate go up indeed, this is quite sad.
14:36:59 <thomasj> Kevin_Kofler, there's a reason, no breakage of the workflow, GUI behavior, (insert here)..
14:37:23 <Kevin_Kofler> KDE x.n+1 releases used to be about incremental improvements.
14:37:39 <ltinkl> not so much lately...
14:37:40 <jreznik> Kevin_Kofler: some changes are really big - but that's open source way
14:37:49 <jreznik> even Apple works that way
14:38:21 <Kevin_Kofler> That said, some of the regressions on the 4.5 tracker turned out to be Qt 4.7 issues, so they wouldn't affect our updates.
14:38:34 <Kevin_Kofler> The K3b one might be such, too (and it's worked around in K3b 2.0.1 anyway).
14:38:58 <Kevin_Kofler> Qt regression rates have also gone up a lot since the Nokia acquisition. :-(
14:39:18 <Kevin_Kofler> The releases were much more reliable and compatible in the old Trolltech times.
14:39:25 <ltinkl> because the codebase got significantly bigger
14:39:55 <ltinkl> so how to conclude this topic? :) we could talk about this for ages
14:40:00 <jreznik> Kevin_Kofler: problem is - Qt is under heavy development by Nokia right now - gazillions of changes - I think it's going to slow down once they finish what they need
14:40:14 <jreznik> ltinkl: ask for exception
14:41:06 <jreznik> we should prepare some list with our arguments for fesco why we need it
14:41:43 * thomasj would agree, that we need/good to have, one major update per release due to KDE not aligned with out releases. He wouldn't even try to force upstream to align their release more to ours.
14:41:53 <thomasj> s/out/our/
14:42:24 <rdieter> jreznik: good idea, anyone interested in leading such an effort?
14:42:29 <thomasj> If every distro try to force them to align to their releases, might be fun :)
14:43:08 <jreznik> rdieter: wiki page, so everyone could cooperate?
14:43:12 <jreznik> I'll set up one
14:43:14 * ltinkl already sees all the big fedora projects (mozilla, OOo) asking for such exception
14:43:16 <rdieter> personally, 1 exception per release is enough for me, but I won't object to others working and fighting for more.
14:43:18 <rdieter> jreznik: cool
14:43:18 <ltinkl> this wiil be fun :)
14:43:43 <thomasj> ltinkl, :D
14:44:10 <SMParrish> And I will go to bat for exceptions but I need documentation I can present that supports it
14:44:13 <rdieter> ltinkl: I think it'll highlight why the existing mandate is a bit too restrictive.  hopefully we'll find a better balance over time
14:44:17 <jreznik> rdieter: it's what we wanted (fudcon toronto)... question is - will be exception granted? what will be plan B if not?
14:44:31 <rdieter> jreznik: riots in the streets :)
14:44:36 <Kevin_Kofler> ltinkl: Actually, Firefox and OO.o are following a passive update policy even now.
14:44:43 <rdieter> though good question, plan b sounds not fun
14:44:50 <Kevin_Kofler> They only push point releases, if at all.
14:45:09 <Kevin_Kofler> So I doubt they'll be asking for any exception at all, unfortunately.
14:45:17 * ltinkl gets his chromium updated at least once a week, np :)
14:45:27 <Kevin_Kofler> In fact they're the only ones who are following that silly policy at this time!
14:46:00 <ltinkl> the motto "release often" gets killed by this policy
14:46:13 * than is fine with 1 exception per release
14:46:14 <Kevin_Kofler> ltinkl: +1
14:46:18 <Kevin_Kofler> That policy is a disaster.
14:46:24 <Kevin_Kofler> It basically destroys what Fedora is all about.
14:46:29 <Kevin_Kofler> It turns us into yet another Ubuntu.
14:46:31 <ltinkl> yup
14:46:35 <skvidal> Kevin_Kofler: or it is what fedora is about and it is a good policy
14:46:43 <Kevin_Kofler> I really don't see what we have to offer over Ubuntu after that change.
14:46:47 <ltinkl> it is what distinguishes us from other distros
14:46:52 <Kevin_Kofler> skvidal: How so?
14:47:01 <Kevin_Kofler> And how will be be different from Ubuntu?
14:47:04 <skvidal> Kevin_Kofler: b/c not everyone's perspective is as skewed as yours?
14:47:07 <Kevin_Kofler> *will we
14:47:10 <jreznik> Kevin_Kofler: no, it makes it worst than Ubuntu :) Ubuntu is usually just broken, Fedora at least works :)
14:47:37 <thomasj> Kevin_Kofler, ubuntu has way fewer updates than we will have with the new policy. Just to be fair.
14:47:43 <Kevin_Kofler> My perspective is not skewed! Fedora is clearly NOT following a conservative policy at this time.
14:47:53 <Kevin_Kofler> Except for a selected bunch of packages with maintainers who do their own thing.
14:47:54 <jreznik> thomasj: and it's quite broken because of it
14:48:08 <Kevin_Kofler> Even yum isn't getting only bug and security fixes!
14:48:09 <thomasj> jreznik, nope, it's not broken.
14:48:18 <skvidal> Kevin_Kofler: I think it's sad that you can't see the forest for the trees
14:48:20 <Kevin_Kofler> skvidal: You've snuck in a bunch of features in your updates as well.
14:48:27 <skvidal> Kevin_Kofler: I've snuck nothing in.
14:48:27 <jreznik> thomasj: it's very broken, every time I tried it...
14:48:28 <thomasj> jreznik, my father in law uses it. He calls me when something's broken :)
14:48:30 <Kevin_Kofler> (And IMHO that's a good thing.)
14:48:54 <thomasj> But anyways. We don't need to compare to ubuntu.
14:48:54 <Kevin_Kofler> thomasj: Each time there's a bug, it stays there forever.
14:49:02 <Kevin_Kofler> Except if they judge it "critical" (which rarely happens).
14:49:05 <jreznik> let's stop this - a) ask for exception, b) prepare the list why we need it...
14:49:09 <ltinkl> comparison is good
14:49:10 <jreznik> and let's move on
14:49:11 <Kevin_Kofler> They don't fix bugs other than security issues.
14:49:26 <Kevin_Kofler> And really, they can't, because often you have to push an update which is not just bugfix to fix bugs.
14:49:39 <thomasj> Kevin_Kofler, and the people like it. As our Fn-1 users would like it, most likely :)
14:49:48 <Kevin_Kofler> The people who like it use Ubuntu!
14:49:53 <Kevin_Kofler> Those who don't use Fedora.
14:49:59 <Kevin_Kofler> So why do we give them something they don't like?
14:50:09 <Kevin_Kofler> They'd use Ubuntu if Ubuntu was what they want!
14:50:10 <than> Kevin_Kofler: we can discuss on fedore-kde later, please move on
14:50:26 <jreznik> thomasj: Ubuntu people are usually used to live with bugs, no one cares in Ubuntu :)
14:50:39 <thomasj> aaah, good point ;)
14:50:52 * thomasj chuckles..
14:51:12 <jreznik> we don't want to be Ubuntu, let's move on
14:51:18 <jreznik> we are running out of time
14:51:29 <than> Kevin_Kofler: you can add  yours arguments to the list
14:51:47 <jreznik> #topic F14 artwork
14:52:35 <rdieter> jreznik: (sorry, didn't see anything else on the agenda, else I would've cut that last topic shorter)
14:52:44 <ltinkl> he is typing :)
14:52:53 <jreznik> tmrw is deadline for beta artwork... I'd like to stick with current one as it looks quite good and if design team stay with current wallpaper... it looks ok and it's too much work with it
14:53:20 <jreznik> but of course I can try something different
14:53:26 <rdieter> there's an open bug about ksplash crashing, I guess that's not reproducible or not a problem anymore?
14:53:31 <than> jreznik: what is still missing in artwork=
14:53:48 <jreznik> rdieter: which one?
14:53:54 * rdieter is looking
14:54:02 <than> kdm theme works fine, i already tested
14:54:07 <jreznik> than: actually it's just goddard->laughlin, no new splash/kdm design
14:54:14 <Kevin_Kofler> jreznik: https://bugzilla.redhat.com/show_bug.cgi?id=627602
14:54:21 <rdieter> .bug 627602
14:54:23 <zodbot> rdieter: Bug 627602 [abrt] kdebase-workspace-4.5.0-2.fc14: updateSplashImage: Process /usr/bin/ksplashx was killed by signal 11 (SIGSEGV) - https://bugzilla.redhat.com/show_bug.cgi?id=627602
14:54:49 <rdieter> heh, ok, must be a bug elsewhere then
14:55:54 <Kevin_Kofler> Well, KSplashX just crashes when there's some problem with the theme.
14:56:47 <Kevin_Kofler> E.g. if the background picture for x×y is actually X×Y with X≥x || Y≥y, it'll crash.
14:56:51 <jreznik> sorry, I missed this bug
14:57:04 <Kevin_Kofler> But of course it could also be a bug in KSplashX itself.
14:57:33 <Kevin_Kofler> Actually, make that X>x || Y>y.
14:57:59 <Kevin_Kofler> It should be exactly x×y, smaller ones will not crash (but leave parts undrawn), only strictly larger ones will.
14:57:59 <than> changing inage size could be workaround
14:58:04 <jreznik> I'll take a look
14:58:50 <than> Kevin_Kofler: it seems a bug in KsplashX
14:58:54 <ltinkl> but it shouldn't crash at all :)
14:59:00 <jreznik> now the question - stick with current (Goddard like) design or design something new for Laughlin?
14:59:40 <rdieter> let's discuss on list after meeting.  I haven't had a chance to even look at it yet myself (sorry)
14:59:41 <than> jreznik: we could do new design if we have time
14:59:44 <Kevin_Kofler> You need to make sure that the name of the directory you're putting the background in matches the size of the background exactly.
14:59:44 <Kevin_Kofler> ltinkl: There's little error checking because KSplashX is supposed to be fast, not robust.
14:59:54 <jreznik> than: I'm quite busy... :(
15:00:20 <thomasj> Goddard like design sounds good to me
15:00:23 <Kevin_Kofler> I'd stick with the current design if it looks fine.
15:00:29 <ltinkl> I'd say stick with the current them (with updated wallpaper), it looks good enough
15:00:37 <ltinkl> s/them/theme
15:00:38 <jreznik> Kevin_Kofler: but it was issue few years ago...
15:00:45 <than> jreznik: it's no problem to keep Goddard design in F14
15:00:55 <rnovacek> current theme is good, I like it
15:01:03 <rnovacek> +1 for stay with it
15:01:18 <jreznik> than: I'll try tmrw to make it look a little more newish but I like it too :)
15:01:23 <jreznik> ok time is out
15:01:43 <than> jreznik: i can help you here
15:02:00 <jreznik> than: thanks
15:04:10 <thomasj> If you educate me in time, i can help next release.
15:04:17 <than> just let close our KDE SIG meeting, time is out!
15:04:24 <rdieter> we're a bit overtime, any last thoughts before we close?  yeah
15:04:45 <rdieter> 20
15:04:54 <rdieter> 10
15:05:06 <rdieter> #endmeeting