FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 03-04-2010, 02:06 PM
Juha Tuomala
 
Default Harmless KDE feature upgrades - yeah right

On Thu, 4 Mar 2010, Jaroslav Reznik wrote:
>> Go ahead, make that to your kde-hardcore-followers-repo. In my
>> understanding, that's what it has been for past years already
>> anyway.
>
> Third party repos are highway to hell unfortunately.

Quite interesting statement from the KDE SIG who runs that third
party repo.

> Fedora is not for companies -

Even accepting the release cycle and official release policies?

I'd concentrate defining *what* the Fedora is, and sticking on it.
Let the consumers decide does it suit them or not.


Tuju

--
You want to throw out the baby with the bathwater! - K. Kofler
Your baby is my bathwater. I don't want the OS you're building. - J. Keating
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-04-2010, 02:15 PM
Kevin Kofler
 
Default Harmless KDE feature upgrades - yeah right

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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-04-2010, 02:21 PM
Juha Tuomala
 
Default Harmless KDE feature upgrades - yeah right

On Thu, 4 Mar 2010, Jaroslav Reznik wrote:
>>>>> will pick up that role (for KDE, kde-redhat stable would probably be
>>>>> revived, currently it's mostly empty for Fedora as the kind of stuff
>>>>> which would be in there is usually just pushed as official Fedora
>>>>> updates).
>>>>
>>>> Go ahead, make that to your kde-hardcore-followers-repo. In my
>>>> understanding, that's what it has been for past years already
>>>> anyway.
>>>
>>> Third party repos are highway to hell unfortunately. Ask former OpenSuse
>>> users
>
> These repos are not intended for beginners/i-dont-care users but it's hell
> even for advanced users - it just screw system... Even I try not to mess with
> RPM fussion but it's still needed

You're being overdramatic here. It's the same repo that is being
used to test latest KDE stuff right now before it goes to rawhide
and to the releases. It's built by same people who make actual
releases. It's KDE team's repo, it's Rex's old repo/project before
KDE got proper status in Fedora.

How you could use its problems (that apparently don't even exist) as
an argument and reason to cause problems for people who just want to
use those kde bugfix releases in old, stable Fedora release?


Tuju

--
You want to throw out the baby with the bathwater! - K. Kofler
Your baby is my bathwater. I don't want the OS you're building. - J. Keating
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-04-2010, 02:36 PM
Juha Tuomala
 
Default Harmless KDE feature upgrades - yeah right

On Thu, 4 Mar 2010, Kevin Kofler wrote:
> Upstream has no policy about what kind of releases are to be provided as
> updates, this is a distribution decision.

They add features to own releases just for that reason, so
downstreams and users could avoid such mess that has just happened.

If you don't understand that, you're part of the problem.


On Thu, 4 Mar 2010, Kevin Kofler wrote:
> Nobody intentionally BREAKS things. Upstream KDE releases are
> supposed to be backwards compatible,

See, you used word 'supposed'. You've been around enough to know
that reality is something else what you keep so passionately talking
about.


Tuju

--
You want to throw out the baby with the bathwater! - K. Kofler
Your baby is my bathwater. I don't want the OS you're building. - J. Keating
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-04-2010, 02:46 PM
Rex Dieter
 
Default Harmless KDE feature upgrades - yeah right

Juha Tuomala wrote:

>
>
>
> On Thu, 4 Mar 2010, Kevin Kofler wrote:
>> You mean the KDE stability proposal? As this is F11, i.e. "previous
>> stable", KDE 4.4 would actually not have been pushed to F11 under that
>> proposal.
>
> How i read it, you would still push *one* feature release in the
> middle of stable release lifespan, right?

clarification: at *most* one. that means zero is an option too.

-- Rex


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-04-2010, 02:51 PM
Juha Tuomala
 
Default Harmless KDE feature upgrades - yeah right

On Thu, 4 Mar 2010, Kevin Kofler wrote:
>> 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!

a) how users are supposed to consume those bugfix releases only,
when you push feature release in the middle of working week?

b) why those different releases exist in the first place, if there is no
intention to differentiate them?

That is, there wouldn't be need for third release number,
we coul just have kde-4.28 now.

Speaking of distro decision, you mean that when FESCO decides this
to stop, KDE SIG will stop it too. That's good.


Tuju

--
You want to throw out the baby with the bathwater! - K. Kofler
Your baby is my bathwater. I don't want the OS you're building. - J. Keating
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-04-2010, 03:33 PM
Orion Poplawski
 
Default Harmless KDE feature upgrades - yeah right

On 03/04/2010 07:18 AM, Rahul Sundaram wrote:
> On 03/04/2010 07:27 PM, Kevin Kofler wrote:
>>
>> 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.
>>
>
> The whole point is that you will invariably find such breakage when
> pushing updates like this *after* the release and this is precisely why
> there are huge discussions on this topic and sooner you realize that no
> matter how careful you are you only increase the risks by doing such
> updates mid-release the better off we are towards a reasonable level of
> compromise
>
> Rahul

Kevin/KDE SIG -

I would also like you to consider that simply changing the behavior of a
system, while not technically a bug or regression, can be frustrating to
a lot of users (I have reports of different looking panels, different
task bar graphics behavior). Especially to sysadmins like myself who
manage multiple users' systems and have to deal with and explain to the
users all of the changes that happen. It is much easier for me to say -
when is a good time to upgrade to Fn? and the user can prepare for
changes and time it to not coincide with other deadlines, etc.

And please, just assume like Rahul says that there *will* be
bugs/regressions that aren't found in testing for major updates like
this, and take that into consideration.

I'm sure some (most?) of my frustration needs to be directed with KDE
upstream and their cavalier attitude towards preserving settings and
data during updates, but I also really don't want to have to deal with
this any more than I have to.

(Off to track down changes in XRANDR behavior with 4.4.0 ....)

--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion@cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-04-2010, 03:38 PM
Jaroslav Reznik
 
Default Harmless KDE feature upgrades - yeah right

On Thursday 04 March 2010 17:33:20 Orion Poplawski wrote:
> On 03/04/2010 07:18 AM, Rahul Sundaram wrote:
> > On 03/04/2010 07:27 PM, Kevin Kofler wrote:
> >> 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.
> >
> > The whole point is that you will invariably find such breakage when
> > pushing updates like this *after* the release and this is precisely why
> > there are huge discussions on this topic and sooner you realize that no
> > matter how careful you are you only increase the risks by doing such
> > updates mid-release the better off we are towards a reasonable level of
> > compromise
> >
> > Rahul
>
> Kevin/KDE SIG -
>
> I would also like you to consider that simply changing the behavior of a
> system, while not technically a bug or regression, can be frustrating to
> a lot of users (I have reports of different looking panels, different
> task bar graphics behavior). Especially to sysadmins like myself who
> manage multiple users' systems and have to deal with and explain to the
> users all of the changes that happen. It is much easier for me to say -
> when is a good time to upgrade to Fn? and the user can prepare for
> changes and time it to not coincide with other deadlines, etc.
>
> And please, just assume like Rahul says that there *will* be
> bugs/regressions that aren't found in testing for major updates like
> this, and take that into consideration.
>
> I'm sure some (most?) of my frustration needs to be directed with KDE
> upstream and their cavalier attitude towards preserving settings and
> data during updates, but I also really don't want to have to deal with
> this any more than I have to.

That's the problem - it's just postponed to upgrade from update - you can
choose one hell from 1. break update, 2. break upgrade. None of this should
happen.

> (Off to track down changes in XRANDR behavior with 4.4.0 ....)

--
Jaroslav Řezn*k <jreznik@redhat.com>
Software Engineer - Base Operating Systems Brno

Office: +420 532 294 275
Mobile: +420 731 455 332
Red Hat, Inc. http://cz.redhat.com/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-04-2010, 03:42 PM
Kevin Kofler
 
Default Harmless KDE feature upgrades - yeah right

Mike McGrath wrote:
> Alternatively, the KDE SIG could stop ignoring the problems that were
> caused this week by the updates they released. Even an "I'm sorry I broke
> your desktop" would go a long way. The update the busted my desktop
> happened on a pretty vanilla install, I suspect lots of users experienced
> issues.

Of course we're sorry for the issues caused by our update, and we're doing
what we can to resolve them as quickly as possible. (For example, we will be
pushing a kde-settings update to enable Nepomuk by default so that scary
Akonadi warning goes away. Hopefully that won't cause more chaos, crossing
fingers. The resource-eating Strigi file indexing will stay disabled by
default in F11 and F12, of course.)

It's just that it's a more productive use of everyone's time to help fixing
the issues instead of complaining about what's already done.

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-04-2010, 03:49 PM
Kevin Kofler
 
Default Harmless KDE feature upgrades - yeah right

Juha Tuomala wrote:
> a) how users are supposed to consume those bugfix releases only,
> when you push feature release in the middle of working week?

What bugfix releases would we be supposed to push? There are no further
4.3.x releases.

> b) why those different releases exist in the first place, if there is no
> intention to differentiate them?

Because they are needed due to KDE's own development method and schedule?
That doesn't imply any assumption about what distros package.

And in fact I'd even argue KDE upstream expects users to be using 4.4.x now,
not 4.3.x, or they'd continue supporting 4.3.x with bugfix releases.

> Speaking of distro decision, you mean that when FESCO decides this
> to stop, KDE SIG will stop it too. That's good.

If FESCo forces us to stop, what else could we do? We're part of Fedora and
as such we do, and have to, follow Fedora policies. But I'm strongly opposed
to such a distrowide policy.

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 04:10 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org