| NEWS: (updated 2008-09-30) Infrastructure status | New SSH fingerprints | New package signing key |
UpdatesPolicy
From FedoraProject
Dumb question - why isn't this a joint core/fesco thing? -- BillNottingham
That isnt a dumb question. We are just trying to get the board position on this clear and then get it vetted through the other stake holders. Specifically we wont include a policy on extras packages without involving FESco - RahulSundaram
Updates Policy
- With the exception of criticial security fixes, all the updates MUST use the proposed updates (updates-testing) repository. Package maintainers are recommended to additionally use the development branch for any significant updates. (Evaluate the best way to have extras use updates-testing repository and the guidelines must be uniform for both) [I think this is overkill. What specific examples do we have of where things have broken? -- BillNottingham] [I too think this is overkill, and possibly even detrimental. A counter example however is the Firefox FC5 security update that shipped without working SSL. I think, in most cases updates have been unproblematic bypassing updates-testing, but perhaps we could strike the right balance with larger updates going into updates-testing first? kernel, glibc, firefox, etc. -- WarrenTogami]
There are innummerous regressions in updates that major updates have caused. Kernel updates invariably result in regressions. Many updates require SELinux policy changes that are delivered out of sync. KDE 3.x update in FC4 caused many regressions.
https://www.redhat.com/archives/fedora-test-list/2006-March/msg00455.html
Just a sample of more issues from fedora-list.
https://www.redhat.com/archives/fedora-list/2006-July/msg01557.html https://www.redhat.com/archives/fedora-list/2006-July/msg01915.html https://www.redhat.com/archives/fedora-list/2006-July/msg00000.html https://www.redhat.com/archives/fedora-list/2006-June/msg04323.html https://www.redhat.com/archives/fedora-list/2006-June/msg04085.html https://www.redhat.com/archives/fedora-list/2006-June/msg02884.html https://www.redhat.com/archives/fedora-list/2006-June/msg04085.html
If you need many more examples, I could provide them. The regular and consistent use of updates-testing repository instead of the current ad-hoc approach would only delay updates by a week in exchange of potentially catching many regressions and give users a good feedback period. I am wondering what do we really lose? - RahulSundaram
- We should ensure that the proposed updates pass the testsuite checks for regressions. Manual testing and feedback should be encouraged.
- Proposed updates MUST be retained in the updates-testing repository for a minimum duration of a week. In cases where a extended duration for feeedback is required the package maintainer may on his own discretion extend the test window. Updates system MUST automatically send personal reminders to the package maintainers who have not pushed their updates into the regular updates repository after the test window duration is completed. [ See above -- BillNottingham]
- Major new versions of system libraries, frameworks and desktop environments MUST not be provided as updates and only in the subsequent releases. Package maintainers MUST consider robustness of updates as a high priority even for minor updates. [Explain how this would allow a "so-close-to-ready-we-decided-it-was-worth-pushing-after-test3" beta to become final in an update. That allows us to stay a fresh, vital, technology-preview-loving distro. -- PWF] [I agree with the direction of this statement, but there IMHO *need* to be exceptions for things that contain drivers. We can't leave people out in the cold for months until the next distribution gets released with new drivers. So new versions from stuff like X.org, sane, hplip, gimp-print/gutenprint should be allowed for the latest stable distribution if they contain new drivers or are required by new drivers (see also this example ; that's a real life example now (200608) -- the driver for Intels latest G965/Q963/Q965 chipset require Xorg 7.1 and FC6 is still two months away) -- ThorstenLeemhuis
I believe the last minute rush is bound to introduce regressions and we should not do this at all - RahulSundaram We did it for gnome in fc5, we'll probably do it again in fc6. It didn't blow up the world. I guess the policy is as stated, except that the release engineering team (with Board approval or something like that) can choose to make exceptions in certain cases for the benefit of a release, providing that wwoods can feel good about the QA. --MaxSpevack
FC5 last minute push in GNOME after the test3 was not really a good idea. We shouldnt be considering this the norm atleast. The last point in this policy does leave room for exceptions - RahulSundaram
[ So, we *always* rev the kernel. This invariably has some regressions along with fixes. C'est la vie. -- BillNottingham ]
- Exceptions to any of this should be approved by the release engineering team and an explanation MUST be announced and discussed in fedora-maintainers list for transparency. The role of the release engineering team might be replaced by a technical steering committee which combines members from Fedora Core release engineering team, FESCo and the packaging committee in the future. [See above... saying MUST in that paragraph and then saying "...well, not really" in this paragraph is a little confusing from a policy standpoint. -- PWF]
Any suggestions on rewording the policy better or does the exceptions not make sense in any case?- RahulSundaram [ I'm not sure this rigid of a policy makes ]sense, and I don't think a rigid-policy-with-regular-exceptions helps to clarify things over a less strict policy. -- BillNottingham
[ Exceptions would have to be explained publicly which adds more transparency into the process. If you believe the current ad-hoc approach doesnt result in severe regressions, that's easily refutable - RahulSundaram]
[ Perhaps the answer is a policy of SHOULD/SHOULD NOT where applicable, with reference to the Core release team for final calls. - PaulWFrields
ABI Stability
Three levels of ABI stability. Packages should be categorized into these slots.
- Stable - libc, libX11, gtk etc
- Volatile - device-mapper, firefox, Mozilla suite etc
- Unstable or Non Existent - Kernel internal module API etc
Package maintainers should preserve ABI compatibility as much as possible with the exception of critical security fixes. Any major ABI breakage MUST be announced and discussed in fedora-maintainers list
