On 07/12/12 17:48, Matthew Miller wrote:
On Fri, Dec 07, 2012 at 03:11:31PM +0000, Andrew Price wrote:
Ah the ol' Fedora stability improvement thread. It must be Friday.
Ok, I'll bite.
This sort of conversation often comes and goes without much being
done. Usually it consists of debates between three camps:
1. Those who see Fedora as an intrinsically unstable distro which
showcases and attracts testing for the latest upstream work
2. Those who want Fedora to be stable enough to become a realistic
alternative to Windows and Ubuntu for the general masses
3. Those who want Fedora to be stable enough and supported for long
enough to be used as a server OS
Hmmm. I don't think I'm in any of those camps. I want Fedora to thrive and
be used, not as an "alternative" but on its own merits.
Each OS is an alternative to the others. "Alternative" here shouldn't
imply anything negative, simply that users could happily switch from one
to the other.
That includes being
a general-purpose OS, both on desktops, on traditional servers, and in the
cloud.
Well that's my hope, too. The items on your list are compatible with
each other but the problem arises when you add the requirement for
Fedora to additionally be an unstable mixing pot of the latest upstream
packages. And that's really what rawhide should be, but since rawhide
requires so much effort to install and keep running, that's what Fedora
proper has become.
While I *do* think we would benefit from a slightly longer cycle (with an
"security updates only" phase), I don't think that's the only way to tackle
the problem.
I'm not against extending the cycle in essence. I just don't think the
*first* step should be to extend cycles and/or support. I think we need
the ability to tackle as many stability problems as we can, pre-release,
before we can start thinking about extending life cycles, and that means
getting people using rawhide day-to-day again. The more bugs we allow
into our releases by neglecting to test rawhide, the more development
time we have to spend/waste on fixing packages in the three supported
releases.
I would link to http://lwn.net/Articles/506831/ but you were quoted in
that article so I'm guessing you've already seen it :)
For example, making it so key applications and development stacks could
easily float from one base OS to the next would make it less of an issue
when the base OS needs to be upgraded.
Not sure I catch your drift here, but it sounds like it could cause API
mismatch headaches.
Making upgrades incredibly painless is another good but different approach,
making us closer to a rolling release. (I think we're headed that way with
'fedup', but it's going to be a little longer for that to shake out.)
Yep, I upgraded my netbook to f18 beta with fedup yesterday without too
much hassle. Looks promising.
Andy
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
