On Sun, 2012-11-04 at 19:47 +0200, Alek Paunov wrote: > On 04.11.2012 19:25, Simo Sorce wrote: > > > note that this is "also" our strength in some respect because it allows > > the system to evolve a lot more quickly, but it also means upgrades are > > Indeed. > > > simply going to break stuff, and that's not so great for desktop > > environments and scare the hell off of 3rd party vendors. > > You may notice we do not have many 3rd party vendors, I think ABI > > instability is reason number, 1, 2 and 3 of why we can't have reliable > > third parties with a community built OS. > > > > I agree completely with all your points. > > A possibly viable alternative for the ABIs freezing (which we can not > ensure anyway) is the C/C++/etc tooling - If we arm upstreams, packagers > and 3rd parties with powerful source tools (API migration/checking), > just like Google does internally, unsing the Clang tooling, witch was > developed exactly for this purpose. > > The GCC/OpenJDK tooling development is not something appropriate as > effort for the manpower of almost any upstream, but IMHO should be seen > as important goal for relatively big player like Fedora. Unfortunately it won't work, unless you are ready to also go and mark reliable and unreliable upstreams, which is ... difficult. The reason I say so is that I know for sure not all upstreams are willing to maintain ABI compatibility. There are various degrees but some go for absolute ABI compatibility at all costs (glibc) to "I'll break the ABI on purpose (or because I don't care) at every upgrade (won't try to name names). Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
