On 05.11.2012 15:57, Simo Sorce wrote:
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).
My point was about the second group (dependency providers with evolving
ABIs) and more specifically about the affected packages (their users -
dependency consumers). When the consumers are short on resources or just
don't really care so much about the current Fedora consistency, the
problem naturally lands at the responsibility of the respective Fedora
maintainers.
The whole dance would be sufficiently different if we provide the
cooperative upstreams with powerful tools for aligning their projects
with the current/prepared release "compound" ABI.
IMO, this means Fedora VMs (not necessarily sponsored by the project, I
am sure that the Cloud SIG has enough magic at hand to orchestrate
community/upstreams provided instances) and preinstalled compiler
plugins based tooling - easy to use instruments for checking and fixing
their sources according the release environment state.
The above applies also for the third parties (propriety software vendors
and these with open source licenses but not so open style of
development) - they probably will spent few dozens of hours to "lint",
once we provide them with ready to use "login and type 'make'" environment.
Of course, not any upstream would be willing to cooperate - in this case
we will have to handle the issue with our own resources, but again the
tooling can reduce the time spent by the packagers with an order of
magnitude.
Fedora is almost always the First, once we start doing this proactive
"Upstreams alignment" technology and effort, maybe other Linux OS
vendors would join too.
Kind Regards,
Alek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
