Stability and Release Cycles - An Idea

Les Mikesell lesmikesell at gmail.com
Mon Dec 22 14:03:10 UTC 2008


Emmanuel Seyman wrote:
> * Les Mikesell [22/12/2008 09:52] :
>> Better said as "any reduction in the fragmentation into incompatible  
>> flavors is a win for everyone involved with unix-like operating  
>> systems".  Or, "any effort to separately maintain fragmented  
>> distributions is a wasted effort".
> 
> The cure for fragmentation is to keep as close to upstream as possible
> and encourage other distributions to do the same.

No it isn't.  Upstream projects make wild and crazy changes every day 
that I want no part of until they've stabilized and are suitable to use 
for years unchanged.  The cure for fragmentation is to pick some 
standard interfaces and stick to them so the code on each side can be 
optimized separately without breaking the other.

> I fail to see how
> planning "a smooth transition into the next Centos" has anything to do
> with it.

The 'smooth transition' is to avoid breaking the user's machine or 
forcing a re-install. Maybe that's a foreign concept to fedora, but for 
me, the point of running any new code is to get it to the point where it 
will continue to serve you for years.  That is, the system should work 
for you instead of you working to continually change it to something 
that isn't quite reliable yet.

If you don't introduce any incompatibilities between the RHEL cut and 
that fedora version's EOL, it should be feasible to do a final 'yum 
update' that slides the stable code into place along with switching the 
update repositories.  The machine then continues to work with stable 
code and update support for the next 7 years with no additional burden 
on fedora resources and the user continues to be happy with his choice 
to start with fedora.  Historically this would have been feasible with 
minor changes from FC1->Centos3, FC3->Centos4, FC6->Centos5.  If planned 
ahead of time it should be even easier.

If you don't like the Centos 'brand' switch - or don't understand why 
the code follows a natural path this way, fedora could do it's own RHEL 
rebranding.  Or maybe Red Hat could wake up and realize that a free 
distro of their own would be a return to what made their name in the 
first place.  In any case there should be no need to duplicate the work 
of backporting security and bug fixes into otherwise stable code that is 
free for anyone to use.

-- 
   Les Mikesell
    lesmikesell at gmail.com




More information about the fedora-devel-list mailing list