Five basic principles for Fedora, from a server perspective.

[Jon Masters]

On Tue, 2010-08-31 at 16:33 -0400, seth vidal wrote:

> > 2. Avoid Churn at the Core
> > 
> >    It may be that in order to best provide for the typical Fedora user,
> >    frequent updates are a necessity. But Fedora should place extra emphasis
> >    on keeping the base of the operating system from changing within a stable
> >    release.
> >
> >    This makes system changes more auditable, and keeps security and
> >    important bugfix updates from being lost in the noise. It reduces risk
> >    from accidental new bugs or from incompatible version changes.
> 
> 
> Should the churn be avoided BETWEEN releases, too? Ie: f13->f14 should
> we avoid core churn?

I was talking with mizmo about core stability earlier. I think it's very
important that we (Fedora) define a core Platform. Not a set of packages
(though it can start with crit-path+perhaps a few other comps) but
rather a specific set of use cases and a general description that
encompasses that we expect the following to be stable:

1). Bootup.
2). Basic Libraries
3). Core system utilities
<etc>

That means that you could replace desktop apps, or provide a new
feature, but you would have a harder time touching a core system
library, replacing a whole subsystem, or impacting upon boot. We could
collectively work on defining what is a basic platform and take that as
a proposal back to the main body.

I would advocate for an extremely vigorous process to getting any of
these components needed for the core platform updated, never after a
release, and place the bar very high on re-implementing them outright.
Make it so you have to prove a case before you go impacting upon stuff
that should be working well (enough) after two decades. And if you do
decide to touch it, it should work just as well immediately after you
touched it as it did before you started. Yes, that might mean we don't
get yet another re-write of something that just about works now, but
that isn't necessarily bad either. Plenty of new problems out there.

> > 3. Fedora is Unix-like
> > 
> >    The operating environment in Fedora builds on over 40 years of
> >    experience. Some of that is quirky and strange, but it's a strangeness
> >    that has become familiar. Changes from that legacy should only be made
> >    with the recognition that simply making things different has a cost, and
> >    that cost must be justified.
> > 
> >    This means knowledge transfers to and from Fedora. It means certain
> >    basic tools are always there.
> 
> Except when they are obsoleted and ignored and the only way to get them
> back in place is to have a long thread vociferously arguing for them.
> Good times, that. It doesn't take a lot of those to stop wanting to be
> involved at all, does it?

People coming into Linux now might not have been involved ten, fifteen
or twenty years ago, and might not have touched a proprietary UNIX. Plus
screwing with stuff is fun, re-inventing it even better. But users get
rather accustomed to certain things working, to the value of standards,
to the import of that crufty ten-second-old book on the shelf entitled
"Fedora 13 for beginners" (or whatever). There should be a very high bar
to making changes that render large amounts of experience and
documentation obsolete. Not that it can't be done if *needed*.

> So gconf and dconf are..... what?

Nice for the desktop but slowly infecting other areas. It is a very
valid point that it's time to reclaim text config files.

Jon.