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

["Jóhann B. Guðmundsson"]

On 11/05/2012 05:28 PM, Przemek Klosowski wrote:
> On 11/02/2012 07:04 PM, Adam Williamson wrote:
>
>> Sure, like I said in another mail, we've got better at that than before.
>> But as I also said in the same mail, you still have to do a version
>> upgrade every twelve months. That alone is ridiculous for a 'stable'
>> operating system.
>>
>
> This is an important point---it makes it difficult to deploy Fedora 
> for other people. When the end-of-support comes, it usually means 
> having to reinstall, because upgrade can take unbounded time, if 
> problems pop up. Additionally, in my experience, a reinstall often 
> results in a better configuration, free of grandfathered suboptimal 
> settings.
>
> I keep thinking about a scheme to roll over an EOL Fedora into a 
> closest possible CENTOS. It's not trivial because I can't just look 
> for the CENTOS that matches the original Fedora release, because of 
> the subsequent updates. It would have to look at the as-is system and 
> try to figure out the best matching CENTOS release. I am thinking 
> about a sum-of-squared-differences-like distance metric: calculate sum 
> over all packages of (installed_version - CENTOS_X_version)^2, for 
> several CENTOS_X versions, and chose the one giving the smallest 
> value. Of course some packages (glibc, kernel) would have a higher 
> weight, but that could be incorporated (\sum_i((v1_i-v2_i)^2/wght_i)).

Well I personally would rather have centos and other rhel clones unite 
to support a lts release of Fedora instead since it does not take more 
then a missing sysadmin or rhel business decision to more or less render 
those community incapacitated....

JBG