On Mon, Mar 8, 2010 at 8:26 AM, Rex Dieter <rdieter(a)math.unl.edu> wrote:
One more call for discussion around another proposal that came out of
Toronto. Short version of this is that we'd consider slowing down updates a
step, esp for the second half of a fedora release's lifetime, and to limit
kde 4.x-type upgrades to at most 1 per release.
Just to go through the points
More time for developers to work on making the current release stable
and to work on the latest and greatest for Rawhide
Is there any middle ground between rawhide and updates?
Lets users know in advance what to expect during a release cycle.
I'm don't understand how this change would accomplish that
Will encourage users who want the latest and greatest to stay current
with the Fedora releases.
Maybe I'm failing to comprehend this goal, but wanting the latest and
greatest seems contrary to the RFC's goal
Will create some low hanging fruit in the way of backporting specific
fixes into the older releases. These will be some good junior jobs that can be showcased
to get new people onboard the KDE SIG, or to provide those already in the SIG but who are
maybe not packagers a way to help.
I guess I should have read properly before asking my previous
question. Is creating new work really a goal to actively pursue?
KDE updates often also need an updated Qt; for example updating to
KDE 4.4 means that Qt has to be updated to 4.6. As more and more applications are written
with Qt, pushing out Qt updates to older Fedora branches might destabilize a lot of
non-KDE apps (or at least create maintainer burden).
I understand the issue here. Though I don't agree that a Fedora-KDE
based RFC should concern itself with this. This is Fedora, software is
expected to be very up to date.