Re: Rolling release model philosophy (was Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID)))

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux