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

Re: What Fedora makes sucking for me - or why I am NOT Fedora



Arthur Pemberton wrote:
We would be using Ubuntu
or CentOS or any of the other bazillion conservative distros otherwise.
A distro with a 6-month release cycle, but conservative updates, already
exists, it's called Ubuntu, why do we need to copy it? If you want Ubuntu,
go use Ubuntu.
CentOS is not only "conservative", as a copy of RHEL and completely
different release cycle it doesn't offer any release that is close to
Fedora 8/9/10. Colin has mentioned (essential) differences between Ubuntu
and Fedora. There are more. Ubuntu won't become equal to Fedora if it
increased its updates frequency.


We will have to agree to disagree on this as I found none of the
reasons he gave substantive.

Does that mean 'your' reasons for not waiting a week longer are substantive, but other people's reasons for wanting something between that and the two year's delay you get with Centos are not? I'd consider both not wanting your machine to break regularly and not wanting to wait two years for a new feature to be substantive.

> I'll wait to see what looks like may be a
new pace of releases play out. I will say that I find the tone of the
proposed changes to be overly conservative and overall unfortunate.
But if that's what the majority wishes, so be it.

I still believe that with some minor changes you could please everyone, including people who want a different pace on different machines. You just need a fast-track, slow-track scheme for installing updates and some cutoff (say 3 months in) for feature-change updates to a release.

It doesn't matter if the fast/slow update tracking is done by manipulating different repos (perhaps some changes to updates-testing or adding another similar layer) or some clever tricks in yum, as long as there is a way to push emergency fixes ahead to bypass any breakage noticed at the fast-track level. That way, testing/development machines and people who want to live on the edge still proceed as normal, and for machines when you need to control the risk you would upgrade 3 months after release and configure the slow-track updates (exact time to be determined by observing your test machine). With such a scheme in place, the only extra human work would be deciding when and how to do the emergency fixes, but that only comes into play when something breaks. Worst-case, you just stop updates on the conservative machines until the test machine shows the fix is done and time has elapsed to move it to the slow-track.

--
   Les Mikesell
    lesmikesell gmail com




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