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-06-2010, 09:59 PM
Till Maas
 
Default Another great update

On Sun, Mar 07, 2010 at 12:48:23AM +0200, Kalev Lember wrote:

> deal with the problems that might arise with the new version. But if the
> new version is dumped upon me in the middle of a week, I'm left without
> a choice. I have to immediately deal with whatever problems arise from
> the upgrade. Now think how someone who administers more than one

You do not have to update immediately and for security updates you can
use "yum --security update" or PackageKit.

Regards
Till
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-06-2010, 10:01 PM
Rahul Sundaram
 
Default Another great update

On 03/07/2010 04:14 AM, Michał Piotrowski wrote:
> I'm just a guest here
>
> I'm not a Fedora developer so my vote doesn't really matter.
>

Getting involved does not require a vote and any user position if
expressed in a constructive fashion does matter and is part of how we
can form a decision

Rahul

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-06-2010, 10:05 PM
Michał Piotrowski
 
Default Another great update

2010/3/6 Orcan Ogetbil <oget.fedora@gmail.com>:
> The numbers 11, 12 should only indicate the core
> components revision number .

I'm not convinced to this philosophy. I have used a few Linux distros
in past 11 years, and this is something new to me...

I hope that RHEL 6 will be released soon, Fedora 11 is going to be too
bleeding edge for me

Regards,
Michal
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-06-2010, 10:14 PM
Orcan Ogetbil
 
Default Another great update

2010/3/6 Michał Piotrowski:
> 2010/3/6 Orcan Ogetbil:
>> The numbers 11, 12 should only indicate the core
>> components revision number .
>
> I'm not convinced to this philosophy. I have used a few Linux distros
> in past 11 years, and this is something new to me...
>

I understand that. However there are philosophies that don't convince
me either. If you consider gtk2-2.18 to be stable enough to support in
Fedora 12, then why can't you support it in F-11? Laziness? Lack of
manpower? Is it because F-11 is supposed to be "more stable" than
F-12? Then why do we stop supporting F-11 (such a stable release by
this logic) after only a couple months?

Orcan
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-06-2010, 10:16 PM
Jussi Lehtola
 
Default Another great update

On Sat, 2010-03-06 at 17:48 -0500, Orcan Ogetbil wrote:
> 2010/3/6 Michał Piotrowski :
> > But you are updating to latest KDE in f11. So what is the deal with
> > full system update?
> >
>
> Time. A simple "yum update" or make a selective update takes a few
> minutes. A whole system update takes more.

I've been upgrading my systems for a few years now with a simple yum
upgrade, i.e. install the new fedora-release package and run "yum
update".
--
Jussi Lehtola
Fedora Project Contributor
jussilehtola@fedoraproject.org

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-06-2010, 10:28 PM
Kalev Lember
 
Default Another great update

On 03/07/2010 12:52 AM, Orcan Ogetbil wrote:
> Yet moreover you also have the option of updating bugfixes in
> addition, leaving the enhancement updates out.

I really don't think I have that option. It might work in some cases,
but generally it's bound to fail.

A security update in an application which uses KDE or Qt libs (both of
which were upgraded to a new feature release recently in F-11 and F-12)
will be built against those new libs. It's a common practice that new
versions of libraries continue working with programs that were compiled
against an older version of said library. But it doesn't work the other
way around: something built against Qt 4.5 is supposed to continue
working with Qt 4.6, but an application built against Qt 4.6 will have
no guarantees that it also runs with Qt 4.5. This is the reason why only
applying security updates doesn't work if underlying libraries get
upgraded to new feature releases meanwhile.


Let me quote mail titled "Read this if your package BuildRequires
qt(4)-devel!!!" here.

On 02/22/2010 05:40 AM, Kevin Kofler wrote:
> for all maintainers of packages which BuildRequire qt4-devel (or qt-devel, but
> the versioned virtual Provides is preferred): please, when you plan to push
> updates for your packages, ALWAYS CHECK what version of Qt your package got
> built against and DO NOT PUSH your update to stable before that version of Qt
> goes stable! A package built against Qt 4.6 WILL NOT WORK AT ALL with Qt
> 4.5!!! (This is always the case, Qt is backwards- but not forwards-
> compatible.)


--
Kalev
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-06-2010, 10:29 PM
Orcan Ogetbil
 
Default Another great update

On Sat, Mar 6, 2010 at 6:16 PM, Jussi Lehtola wrote:
> On Sat, 2010-03-06 at 17:48 -0500, Orcan Ogetbil wrote:
>> 2010/3/6 Michał Piotrowski :
>> > But you are updating to latest KDE in f11. So what is the deal with
>> > full system update?
>> >
>>
>> Time. A simple "yum update" or make a selective update takes a few
>> minutes. A whole system update takes more.
>
> I've been upgrading my systems for a few years now with a simple yum
> upgrade, i.e. install the new fedora-release package and run "yum
> update".

That broke stuff for me in the past. It might have changed since. Yet
I feel the need to clone the root partition to somewhere before
attempting again, which, with limited hardware supplies, takes time.

Orcan
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-06-2010, 10:45 PM
Till Maas
 
Default Another great update

On Sun, Mar 07, 2010 at 01:28:32AM +0200, Kalev Lember wrote:
> On 03/07/2010 12:52 AM, Orcan Ogetbil wrote:
> > Yet moreover you also have the option of updating bugfixes in
> > addition, leaving the enhancement updates out.
>
> I really don't think I have that option. It might work in some cases,
> but generally it's bound to fail.

But you have nothing to loose if you try it. You won't get more updates
than without trying to reduce them to the security updates. Even if it
might in theory not work that good, maybe it does in practice.

Regards
Till
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-06-2010, 10:50 PM
Henrique Junior
 
Default Another great update

Em Sb, 2010-03-06 s 18:00 +0100, Christoph Wickert escreveu:
> While we are at it, here is another great update:
> https://admin.fedoraproject.org/updates/F11/FEDORA-2010-3326
>
> * New version introduced in F11.
> * Doesn't fix any bugs but it's an enhancement only.
> * Useless update description "update to 4.7.1".
> * And *of course* it was pushed directly to stable, even in F-13.
>
> Dear maintainers, please stop this!
>
> Regards,
> Christoph
>

A few days ago the discussion on policy updates are maturing and that it
is beneficial to Fedora, but it's useless to start threads with the
attitude of "pointing fingers and accusing" using an ironic tone.
--
Henrique Junior <henriquecsj@gmail.com>
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-06-2010, 11:05 PM
Toshio Kuratomi
 
Default Another great update

On Sat, Mar 06, 2010 at 11:07:13PM +0100, Christoph Wickert wrote:
> Most of our packagers follow the guidelines from the wiki:
> http://fedoraproject.org/wiki/Package_update_guidelines
> This means, they apply at least three criteria:
> * An update should not break something
> * An update should be backwards compatible, e.g. it should not
> change the syntax or location of a config file so that old
> settings can no longer be applied.
> * An update should not change the behavior of an basic
> application, e.g. think of when Thunderbird started indexing
> automatically after an update.
>
> Summing it all up I think I don't think it is pretty obvious that the
> KDE SIG uses different criteria then most other maintainers. This is
> just a statement and no criticism.
>
Since I just re-read that page when it came up in a different thread, I have
to say that your bullet points don't seem to quite match what I read on that
page.

* An update should not break something
On the wiki page it's not so black and white -- instead it's a decision that
the package maintainers must make to balance: "The benefit of the bugfixes
and new features should be weighed up against the risk of regressions."

* An update should be backwards compatible
This is not really on there. Your example is a subset of backwards
compatibility which can find justification here:
"an update doesn't cause a users' applications or system to stop working
suddenly."

But other examples of backwards incompatibility (for instance updated
libraries with new SONAMES to address critical bugs if rebuilds of apps in
fedora are performed, changes to config files if an automatic conversion
is available) would be allowed.

* An update should not change the behavior
This is actually not mentioned at all.

As for whether the KDE SIG is currently following the guidelines on
http://fedoraproject.org/wiki/Package_update_guidelines I would argue that
they are. Their upstream is providing releases that have both bugfixes and
enhancements in one release. They've evaluated the risk of regression and
figure that backporting of requested features and bugfixes is more likely to
cause regresions than upgrading to upstreams supported release. They push
the updates to multiple repos for testing before it gets to the normal
updates repository in order to mitigate the risk of regression. They did
not push KDE4 to a release that only had KDE3 because the update was
considerd to break working systems. All this seems to indicate that the KDE
SIG is working hard to evaluate the stuff they're pushing with the guidance
on the Package_update_guidelines page rather than blindly pushing new
upstream releases which have no benefit to Fedora users.

-Toshio "Wondering how your post about a midnight commander update not
following good update practices turned into claiming the same for KDE"
Kuratomi
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 05:09 PM.

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