RFC: Fedora revamp proposal
mitr at volny.cz
Mon Mar 4 18:18:04 UTC 2013
This is a proposal of changes to the way future Fedora cycles should
work and integrate changes.
Some of the things we want to achieve:
* Make rawhide to be reliably installable and usable by developers by
coherently introducing changes.
* Define the interfaces that applications can rely on (and by
inference, the ones that they can't).
* Ensure that functionality implemented in Fedora doesn't
unintentionally regress, and provide a clear way to change or replace
To do this, we propose to specify three levels of stability we
attempt. These are defined at the level of interfaces (e.g. specific
library/command/file), not at the level of packages:
1: Long-term ABI for applications that we don't want to break without
For now, this will include the stable kernel and libc ABIs
2: "Base design": A set of functionality that was implemented and
needs to be kept working in any composed tree, including rawhide; may
include specific commands.
Behavior that other parts of the distribution depends on.
Functionality accepted for this tier by FESCo using the planning
process, and some interfaces this functionality relies on.
3: "Internal API": we'll do our best not to change it within a release
lifetime; basically the existing Fedora compatibility and update
e.g. Python/Perl/Ruby X.Y version, most library interfaces, and
major aspects of UI.
We also propose to build up automated tests to verify the tier 1 and
tier 2 functionality, and use those tests on newly-built packages to
gate inclusion in rawhide.
Finally, the planning process will recognize the existence of these
tiers by classifying each proposed change:
* Changes to tiers 1 and 2:
Strong recommendation that new stable APIs have new tests
delivered at approximately the same time, if possible. This benefits
change owners by diminishing the risk of accidental breakage of the
functionality. Existing tests for the functionality must be updated at
the same time as well.
Waivers may be requested of FESCo.
* Complex changes not affecting tiers 1/2 (e.g., new core library version):
Strong recommendation that landing of these be coordinated, via
the use of side tags or similar features.
* Self-contained changes (mostly announcement-only) (e.g. user-visible
changes to applications)
The original idea for this proposal was discussed at length during
FUDCon Lawrence by the following individuals:
Justin M. Forbes
Additionally, further discussion took place at the Brno Developer
More information about the devel