On 2/14/06, D Canfield <canfield@xxxxxxxxx> 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 -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list