Juha Tuomala wrote:
> On Thu, 4 Mar 2010, Kevin Kofler wrote:
>> I would argue having this within Fedora infrastructure would be better as
>> it would prevent proliferation of third-party repos replacing Fedora
>> packages and the resulting compatibility issues (see e.g. the chaos we're
>> having for RHEL with third-party repositories replacing official packages
>> with newer versions and the resulting dependency hell) and as it would
>> also provide a place for new versions of less commonly-used applications.
>
> So the thing is that KDE SIG wants to prevent any other activity and
> keep the strings in own hands.
Huh? What I was saying is that it's not a good idea if you have:
* kde-redhat replacing Fedora's Qt and KDE packages with newer stable
versions
* repo X replacing Fedora's kernel packages with newer stable versions
* repo Y replacing Fedora's some-library packages with newer stable versions
* repo Z replacing Fedora's some-application packages with newer stable
versions
etc., and users who want to be up to date having all these repos enabled,
when the repository maintainers didn't test them together (or they did, in
which case the people who're trying to enable only, say, repo Y, are the
ones getting screwed).
Having one central backports (or just updates as now) repository prevents
those compatibility issues.
> That's why nobody can't enjoy the upstream's intended stability in bugfix
> releases and plan major upgrades.
You keep saying that, yet you have provided no evidence of such a stance
from upstream. KDE upstream actually has no policy on what versions should
be pushed as updates in what distros, it's a distro decision!
> If someone wants to fork, whatever, let them do it. That's why Fedora
> moves to the git, to make it easier.
The issue is not forking the specfiles, it's mixing the repos and the
resulting dependency hell.
>> That said, IMHO the best solution is still to have this stuff in the
>> official updates. But it's true that the kind of issues some users are
>> having with KDE 4.4 are unfortunate. This particular Akonadi issue hasn't
>> shown up during testing or it would have been considered a blocker.
>
> What you've just proved could have been enough for some companies
> trying to run Fedora on their employees desktops and they probably
> think that they've seen enough. TCO is rising too high when you
> cannot do sane stable release updates.
Who says they would have seen that issue at all? You're the first one to
report this particular issue.
> In other words, SIG's current policy is doing more harm than good
> for Fedora.
Not necessarily. There has also been some very positive feedback for the KDE
4.4 updates, and some people are using Fedora BECAUSE such updates get
pushed.
>> But I think having yet another thread about update policies will be
>> frowned upon by the moderators. Instead, let's please think about
>> repairing this breakage now that it happened, i.e. get bug reports filed
>> etc.
>
> Yes, let's fix the bug instead the policy that caused it in the
> first place, sigh.
It's too late to undo the update now, it already got pushed (reverting would
break a lot more things, KDE does not support downgrades).
So the only productive thing to do now is to fix the bug. Complaining about
it serves nobody.
So please provide the details required to actually FIX the bug! I.e. file a
bug report and provide the output of "akonadictl start" Rex asked for.
Kevin Kofler
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
