On Mon, Mar 04, 2013 at 07:18:04PM +0100, Miloslav Trmač 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 > > 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. If this gate will avoid the frequent broken deps in rawhide, then I'm all for it. The current situation where any package can be pushed to rawhide at any time which breaks any deps, is what makes rawhide pretty much useless to me. Of course there are many other things that can go wrong besides, but if we could at least reliably install rawhide packages without needing to be an expert in fixing broken RPM deps, then we'd be heading in the right direction. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
