User:Mitr/Revamp

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 features implemented in Fedora don't unintentionally regress, and provide a clear way to change or replace earlier implementations
  
  

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 significant discussion.
  • 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 rules
  • 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:

• Stephen Gallagher
• Jon Stanley
• Miloslav Trmač
• Adam Williamson
• Bill Nottingham
• Jaroslav Reznik
• Jesse Keating
• Paul Frields
• Emily Dirsh
• Justin M. Forbes
• Peter Jones
• Toshio Kuratomi
  
  

Additionally, further discussion took place at the Brno Developer Conference between:

• Bill Nottingham
• Marcela Mašláňová
• Miloslav Trmač
• Stephen Gallagher
• Tomáš Mráz