On Mon, Mar 4, 2013 at 7:50 PM, Josh Boyer <jwboyer@xxxxxxxxx> wrote: >> 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. This means "whatever the Linux kernel project says is their stable ABI". It was not at all intended to expand the ABI boundary. >> 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? * Critical path is a set of packages; this is a set of functionality/interfaces. * Tier 2 may include both both user-visible aspects and programming interfaces. * Tiers 1 and 2 are expected to be kept working (as primarily verified by the tests) even in rawhide. * Changes to tiers 1 and 2 are required to go through the planning process. A few possible examples of how this could work (without necessarily claiming that all of these things should be in tier 2, that's up to maintainers and FESCo): * /bin/bash is an important part of the CLI, and any package build that breaks it would not be accepted into rawhide (modulo possible temporary waivers for merging a change). OTOH broken /usr/bin/bashbug, missing info documentation, or other less important aspects of the package would not prevent rawhide inclusion. * The polkit D-Bus API is an important cross-package interface, and any package build that breaks applications using it would not be accepted into rawhide. * Since F18 we have https://fedoraproject.org/wiki/Features/AvahiDefaultOnDesktop , and any update that reverts that would not be accepted into rawhide. NOTE: In all of these cases, the situation is NOT set in stone - incompatible changes to the functionality in tier 2 can happen, can even happen in every Fedora release. The only hard requirements are that the change must go through the Planning process and be acked by FESCo, and that existing tests must be updated. >> 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? "Basically the existing Fedora compatibility and update rules": http://fedoraproject.org/wiki/Updates_Policy >> 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? Yes. My personal opinion: * For UI and APIs, we want the things included in tier 2 to be sufficiently stable/tested, which probably means they should already have an upstream test suite; if they don't, and Fedora decides that they are important, Fedora should contribute an upstream test suite. * I expect that many "change" owners will find it worth their time to write a test - e.g. in the above example of Avahi it's one-time cost of writing a fairly simple test that will save manual checking and worry for the future. >> * 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. Yes, this has even been accepted by FESCo (last sentence of https://fedoraproject.org/wiki/User:Mmaslano/Feature_process , in https://fedorahosted.org/fesco/ticket/896). So this is just a matter of making it possible/easy, and making it actually happen. Mirek -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
