Stabe vs. Release vs Devel Was: KDE update - no testing period?

[Jeff Spaleta]

On 2/14/06, D Canfield <canfield at uindy.edu> wrote:
> So again I ask what the point is of a release?  What makes FC3 and FC4
> different?

"time based release model".. predictability of behavior...even broken
behavior at install time of the "releases".

> Why not just have a development tree where things are
> developed and tested, and a stable tree where packages are then merged
> once people are happy with them?

What is the incentive to make sure ALL the peices integrate together
nicely at any given point in time.. unless there are set release dates
to shoot for? A release schedule drives integration efforts to make
sure all the pieces work together. You can't just throw chunks of the
development tree over the fence into stable, you have to deal with
integration issues across subcomponents by having freeze points.

Do you really want to see a full rebuild of ALL packages in your
"stable" tree because a new compiler landed in the stable tree forcing
everyone in the userbase to download and install the ENTIRE installed
packageset as updates? Do you really want to see users who have been
relying on how the fc4 styled automounting worked via hal policy files
and fstab-sync.. suddenly find the automounting working in a
completely different way regardless of desktop because the new hal
stuff moved into your "stable" tree? Do you want to see systems break
because selinux was turned on in an update but the filesystems were
not properlly labeled at install time? Do you really want to see a
reorganization of the metadata in stable tree repository that is
incompatible with previous "stable" incarnations and forcing users to
deal with that change as part of updates.   Do you comprehend how much
has changed in this fc5 test cycle inside the installer itself? Inside
how comps groupings are defined?  Did you really want to see the jump
from an 2.4 kernel to a 2.6 kernel as an update in your non-release
tree world? Your single "stable" tree would force DEEP
incompatibilities during updates onto all users regardless of when
they did their install.
The fc3 to fc4 release transition might not have introduced signficant
technology differences...but other releases have. The jump from 2.4 to
2.6 kernel was significant. Turning on selinux by default was
significant. Replacing static dev with udev was significant.

In the large scale view of Fedora Core.. KDE is NOT a critical
subcomponent of the fedora software stack. It is OPTIONAL and how it
is treated in terms of updates compared to other much more integrated
components can not be fairly compared.  The reality you need to come
to terms with is that individual Core packagers have some freedom to
do what they think is best in terms of updating components and there
is discussion among Core developers and the release team with regard
to update policy highly integrated components.  You are NOT going to
get a black and white policy with regard to how updates are done. Much
of the development is done by consensous among the developers..because
there are competing demands over how updates are handled.

My understanding as to how things get updated or held back is based on
a perception of impact to other subsystems. Highly integrated
technologies are much less likely to see a disruptive update... but it
could still happen based on other factors like critically needed
security fixes. You simply cannot compare the update of KDE to
something like the introduction of udev as replacement of static dev
as an update to a release.  There are technologies that are only
introduced in new releases based on perception of impact due to the
level of integration in the software stack of Fedora Core. KDE is not
regarded as a critically integrated technology and the package
maintainer as much more leeway to respond to user demand for an update
asap.

-jef