PROPOSAL: Core size reduction "bug day"

[Havoc Pennington]

On Sat, 2004-07-24 at 21:57, Toshio wrote:
> * Fedora Extras
>   - We need to have Extras officially "in place" (so we can see how it
> interacts with Core.)
>   - Define Red Hat's relationship:
>     + Oversight.  Red Hat pretty much controls Core.  What about Extras?
>     + Resources.  Red Hat is committing hardware to Core (and I believe
> Extras) but what about personnel?  Does movement of packages from Core
> to Extras mean the packaging burden shifts to community support or will
> RH pay employees to maintain packages in Extras?

Note that there are already some half-answers here:
http://fedora.redhat.com/participate/terminology.html

Addressing some of your questions:

What we will pay people to work on - roughly speaking, I would say we
need an internal maintainer for any package found in Red Hat Enterprise
Linux. We don't have to be the primary/only maintainer on all packages
included in RHEL, but we have to pay relatively close attention to any
package included in RHEL so someone at Red Hat will be assigned to watch
each package.

If we defined Core as "stuff that's in RHEL" then it would map closely
to what Red Hat people will be looking at. Although people who happen to
work at Red Hat will probably be touching a lot of other things just
because of personal interest.

However, I'm not convinced this "Core = RHEL" idea makes any sense.
There's stuff in RHEL that could do well with a primary maintainer
that's external. Also, the "what's in RHEL" discussions will always be
internal-only and so Core boundaries would move around mysteriously.

What we'll provide hosting resources for - all of Core, Extras,
Alternatives. These three are really intended to be in the same
infrastructure. Extras is not on the main ISOs, and Alternatives
conflict with stuff in Core/Extras. An example of Alternatives type
packages would be Ximian GNOME. An example of Extras would be any random
package we don't include in Core.

> * Distribution of add-on releases
>   - Since using FC, I've realized the time-saving benefits of
> bittorrent.  If I have to download 500MB-1GB of packages to replace what
> was left out of Core, will I be able to get it as fast?
>   - How are we going to choose what should be on Extras CDs?  If we
> think it's hard choosing what should be in and what should be out of
> Core right now, how are we going to feel about choosing what should be
> in an Extra Server CD?  An Extra Desktop CD?  A KDE CD?  Can there be
> overlap? 
>   - What type of schedule are we going to propose for Extras CDs?
>   - Will Extras be rebuilt along with Core _before_ a FC release (so
> Extras software can be updated simultaneously.)
>   - When installing Core, will loading of Extras/3rd party CDs be
> supported?
>   - What technical hurdles can stop packages from being upgraded without
> help from anaconda (and therefore need to remain in Core)?

I would say the goal here should be to make Extras as close to Core as
possible in the user-visible ways. The Core/Extras split has more to do
with who is doing the organization. The Fedora Project core team
(whatever that is - steering committee or whatever) manages the Core
release, tracks showstoppers, sets schedules, etc. etc.

The Extras releases on the other hand are done by other teams, the
example on http://fedora.redhat.com/participate/terminology.html
is a "Fedora Extras HPC" release, presumably there's a group of people
into HPC providing that.

I guess you could say that Core is supposed to be the base Linux
distribution open source project, and Extras is supposed to be a
collection of add-on projects. By "project" I mean a group of people
maintaining a group of packages.

Some people seem to feel Core should be the most-stripped-down-possible
set of packages, I think that's more of a technical split that belongs
in the comps file, I would define Core more by the organization.

> * Packages already in Core and those in RHEL:
>   - How will we deal with dependencies that are unmet by a smaller Core?
>   - Red Hat "justifies" Core as a testing ground for RHEL.  How does
> this requirement affect what can be moved out of Core into Extras?

It's a bit inconvenient for us if stuff in RHEL isn't in Core, for sure.
I don't know if it's impossible.

Havoc