Core BrainStorm

[Bill Nottingham]

seth vidal (skvidal at phy.duke.edu) said: 
> So if you have any ideas discuss them here and post criteria to the
> brainstorm page.

OK, time for a brain dump.

Stephen mentioned wondering who the Core architects were. Historically,
it's been a loose confederation that involved mainly myself, Elliot Lee,
and Jeremy Katz, with other people as necessary.

New packages would be proposed, generally by those who would be
maintaining them. They'd be asked to provide:

- package name (example recently: libosp)
- what it does (blah)
- why it's needed (it was split off from openjade. Required by various
  things)
- whether or not it needed to be in the comps file (and if so, where)

A decision would then be made; sometimes it would be 'please put this
in Extras instead'. If it was decided to be fine for Core, it would be
added to some internal machinery, and the maintainer would check it
into CVS and build it.

A similar process would be followed for package removals. However,
general reviews of the package universe looking for likely candidates
for movement were only done when there was a space crunch, or as
occasional projects when bored (such as looking for libraries no longer
used by any apps.)

That's the general mechanics of it, anyway.

Now, as to criteria. I'm sure some of the interaction designers will
tell me we're going about it the wrong way, but we've historically
looked at the following usage cases:

- Internet-attached server

  This means a server for the main internet protocols. This would
  include a web server, a database server, name server, DHCP server,
  etc. More esoteric things like gopher servers, IRC servers, or
  game servers wouldn't really fall into this category, though.

- Knowledge worker desktop

  This would include the base desktop shell and applications that
  a typical knowledge worker would use - web browser, office suite,
  e-mail client, chat/IM client.

- Technical workstation/desktop

  This is a superset of the knowledge worker desktop; it would include
  some basic development tools, and possibly things such as graphics
  editors.

There are various usage cases we *haven't* focused on:

- Game machine, with all the various open source games

- Educational desktop for kids

On top of these various usage cases, we have technical constraints
that drive decisions:

1) Core must be self-hosting.
2) Extras must be self-hosting in conjunction with Core.
3) Subpackages cannot be split between Core and Extras, at least not
   without building them in each instance separately.

Now, the question is, within Core, how do we apply these usage cases
and criteria to packages to determine what is and isn't appropriate?

Generally, we want to ship best-of-breed apps for any particular
functionality. While we release that multiple implementations of
various things exist and will need to be shipped (barring something
very unforseen, we'll always have both Perl and Python), we
want to limit the number of redundant apps - in nearly all cases,
Extras is the perfect place for them.

When determining what we'd consider best-of-breed, we have
the following criteria (not all of these would apply to every
package):

- should be localized, or at least localizeable
- should support internationalized input
- should function properly in UTF-8
- should be in a modern graphical toolkit, such as GTK+ or QT
- should not drag in an excess number of dependencies

Historically, we've erred on the side of adding software; there
has been a more-is-better approach, as the amount of things
people expect a distribution to do increases.

Now, how should this change in the future?

What needs to happen, in my opinion, is that the idea of functionality
being in packages in Extras shouldn't be seen as a bad thing, or
as a barrier to entry.

There are various ways to accomplish this:

- brand the universe of Core + Extras as Fedora, and generally refer
  to that, as opposed to Fedora Core and Fedora Extras
  
  This could have ramifications on other projects, though - as
  how does this relate to things such as Fedora Directory Server,
  or other future Fedora Projects?
  
- seamlessly allow Extras to be everywhere that Core is from an
  installation path - anaconda, yum, pup, system-config-packages, etc.
  
  This is done for yum and pup, but not yet for the others.

- allow functionality grouping of packages for download and ISO
  creation, and potentially do this for Extras
  
  I've posted about this before - I think it simplifies the user
  experience if you have things like Fedora Office, Fedora Java -
  plus, it allows people to easily see what they would need to
  download for what they want.
  
  Alternatively, we could push DVD isos everywhere. But then
  we'd probably overflow those. (Fedora Blu-Ray!)

Once we accomplish these things, we can then reexamine the
package contents of Fedora Core as it stands now, and potentially
rearrange things significantly.

However, this does bring up issues:

- Extras and Core have differing release models, generally. Core
  has a Release, plus Updates. Extras has a more rolling release
  model.
  
  It could be possible to move Extras to be released more like Core,
  complete with Updates and advisorys. However, I don't know if
  that's practical or wanted - it requires more discussion.

- With the more rolling release model of Extras, how does that fit
  in with building CD images, or grouping of packages? Do we
  offer services that build Extras CDs on-the-fly? Do we have
  generated Extras isos at Core release time, and never afterwards?
  Do we allow third-parties to make their own Extras isos with
  scripts (or infrastructure) that we provide? (Cue the Trademark
  policy!)

There are probably other issues I'm missing in this 20000 foot view.

While we're here, we could think of new criteria that we'd use,
and new polcies we could implement as part of this. Examples
would be:

- Compatibility libraries - All compatiblity libraries exist
  solely in Extras (unless they are required by Core
  packages - this should be minimized, of course.) Compatiblity
  libraries could exist in Extras for a period of time that is
  at the discretion of the maintainer, or we could have specific
  policy (one release? two releases?)
  
  This is something we could start implementing today.
  
- Support for languages not deemed as being fully supported (whether
  by average translation percentage, or some other metric) would
  exist solely in Extras.
  
  Frankly, I think this is a bad idea, but I know that others
  disagree with me.

I suspect we could come up with some significant reducutions in
Core if we tried hard. Looking over a report of all the leaf nodes
in the distribution would produce lists of smaller packages that
could be removed, while reexaming the entirety of Core based on
these criteria could remove various larger things. Examples
of the former could include things like privoxy or dtach; examples
of the latter could include larger things ranging from Jonas
to KDE to Ruby.

However, it's my opinion that a lot of implementation of the latter
category should wait until we have install-time support for multiple
repostiories, and potentially support for CD grouping of the same.
Perhaps we should go down this road and start listing such things
that we would move in the release notes, in preparation for FC6/FE6.

Or should that just be F6: And You Thought Twister Was Bad!

Comments? Flames? Not at all what you were looking for?

Bill