RFC: Fedora revamp proposal

[Josh Boyer]

On Mon, Mar 4, 2013 at 1:18 PM, Miloslav Trmač <mitr at volny.cz> wrote:
> 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
> 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

Please define what you mean by "stable kernel ABI".  Do you mean the
kernel <-> userspace syscall ABI?  If you mean anything other than that
I really don't think it's going to work.  There is no internal stable
kernel ABI and upstream is very against having one.

Put another way: There is no way Fedora is doing anything like kABI.

> 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.

Isn't this basically just critpath?  Why is it being called something
new?  Or if it isn't just critpath, can you explain how it is different?

> 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.

Just to be clear, when you stay "within a release" you mean after it
is actually released?  Or do you mean after it's branched?  Clearly not
rawhide or we'd never update anything, but at what point is this in
effect?

> 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.

Are you envisioning the package maintainers to have to write these tests
if they don't exist upstream?

> * 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.

We already encourage this today, correct?  So this is just a
formalization of that.

josh