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)))

[Alek Paunov]

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